Modern infrastructure runs on non-human identities (NHIs). CI/CD jobs, automation bots, AI agents, service accounts, microservices, ephemeral workloads. And they’re not just growing in number. They’ve overtaken systems in your infrastructure.
The current NHI-to-human ratio sits at 45:1 and is accelerating. This shift brings velocity and scale, but it also introduces a massive new attack surface: secrets sprawl.
Tokens, API keys, certificates, and other ephemeral credentials are embedded in pipelines, hardcoded in configs, and passed between systems without meaningful oversight. The systems that issue and store secrets are not the same ones that enforce access control. And that’s the root of the problem
NHIs Are Now the Primary Source of Leaked Secrets
GitGuardian’s 2025 State of Secrets Sprawl report found that 23.77 million new secrets were leaked on GitHub last year—most of them tied to NHIs. More alarming? Over 5% of those repositories were already using a secrets manager. Even when secrets are “managed,” they still leak.
These credentials are:
- Embedded in CI/CD pipelines
- Passed through environment variables
- Shared over Slack or Jira
- Copy-pasted into YAML, Terraform, or Helm charts
- Auto-suggested into code by AI pair programming tools like Copilot
Private repositories are actually 8x more likely to contain leaked secrets than public ones, largely because developers let their guard down and cut corners in “safe” internal spaces.
And most of those leaked secrets offer powerful access:
- 96% of GitHub tokens had write access
- 95% could access the entire repository
- GitLab tokens commonly had full or read-only access to production systems
Secrets aren’t just secrets anymore. They’re lateral movement vectors.
Secret Stores Solve Part of the Problem
Rethinking Non-Human Identity (NHI) Management
There’s no question: vaults and secrets managers are critical infrastructure. They’ve been the backbone of how enterprises safeguard credentials for years. Tools like CyberArk’s Enterprise Vault were designed for human-centric workflows, helping users check out privileged credentials to log into servers and databases. Meanwhile, tools like HashiCorp Vault, CyberArk Conjur, GCP Secrets Manager, AWS Secrets Manager, and Azure Key Vault extend those protections to non-human identities, centralizing sensitive secrets, rotating credentials, and reducing reliance on hardcoded values in code or config files.
But these tools are limited by their pull-based architecture. By definition, they wait for an app, script, or user to ask for a secret, and then they hand it over. That approach solves part of the problem, but not the whole picture. They can’t:
- Govern who can request secrets based on dynamic, real-time context
- Control how credentials are used after retrieval
- Intercept and monitor access live
- Enforce just-in-time (JIT) or time-based approvals
- Deliver end-to-end audit trails of post-access activity
And perhaps most importantly, they don’t eliminate credential visibility—the secret is still exposed to the machine or person consuming it. That visibility is where the risk lives.
The Perimeter Problem
To really understand the limits of these systems, you need to think about “identity perimeters.” Each cloud provider (AWS, Azure, GCP) has excellent native capabilities for NHIs that are often passwordless. Inside that perimeter, identities can be federated and managed securely. But the moment you move outside that perimeter or cross the cloud’s shared responsibility boundary, things change.
Take AWS as an example: your IAM Role may allow you to spin up an EC2 instance, but that doesn’t automatically grant you access to the operating system on that machine. The OS layer sits outside AWS’s identity perimeter, so traditionally, credentials have to be brokered. That’s why secret stores exist in the first place: they bridge the gaps between perimeters.
The Next Step
Federation and secret stores are necessary, but they aren’t sufficient. What’s missing is a layer that not only brokers credentials but also governs how, when, and if they’re used—with Zero Trust principles applied end-to-end. That means moving beyond “here’s your secret, good luck” to continuous control, contextual policy enforcement, and the elimination of credential visibility altogether.
StrongDM Doesn’t Store Secrets—It Governs Access
StrongDM takes a different approach. It’s important to recognize that the platform doesn’t replace vaults. Rather, it sits between identities and the infrastructure they’re trying to access. It’s a real-time access broker built on Zero Trust principles, designed to remove credentials from the equation entirely.
Here’s a breakdown of how it works:
Dynamic Credential Injection
When a user, or NHI, requests access to a database, server, Kubernetes cluster, or cloud service:
- StrongDM authenticates the identity (human or machine)
- It evaluates a policy based on role, session metadata, time-of-day, device posture, etc.
- If access is permitted, it injects the credentials into the live session behind the scenes
- The requesting entity never sees the credentials
- The session is fully logged and auditable
Pluggable Secrets Sources
StrongDM integrates natively with your existing secrets managers:
- HashiCorp Vault
- CyberArk Conjur
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
StrongDM does not require credential duplication or new storage locations. The system fetches credentials on demand using short-lived, ephemeral tokens with zero credential persistence on disk.
If a secret is rotated in your secrets manager, StrongDM picks it up immediately—no restart, no user involvement, no downtime.
Policy-Based Access Control (PBAC)
Access is governed by declarative policies, which can be configured using:
- User identity and group membership
- Resource metadata (e.g., “prod,” “PCI,” “read-only”)
- Time windows (e.g., business hours only)
- Session duration caps
- Approval workflows (manual or automated)
- Dynamic session attributes (IP range, device type, etc.)
This means an NHI can be granted temporary, just-in-time access to a specific PostgreSQL instance in a sandbox environment only during a deployment window, only via CI, only if an approver signs off, and all without ever exposing a credential.
Auditing, Observability, and Compliance
Every session brokered by StrongDM is:
- Logged in real time with full session metadata
- Replayable for interactive systems like SSH or RDP
- Searchable via API, CLI, or the web UI
- Exportable to SIEMs and compliance systems
This creates a complete audit trail of:
- Who accessed what
- When and for how long
- What they did during the session
- Which credentials were used, and how they were injected
This level of observability is critical for satisfying compliance frameworks like PCI-DSS, HIPAA, SOC 2, and NIST 800-53.
The Future of Secrets Is No Secrets
Secrets management will always have a place in infrastructure. But visibility to secrets? That’s optional.
When credentials are never exposed—never on disk, never in memory, never on screen—then they can’t be:
- Leaked in logs or crashes
- Stolen via memory scraping
- Reused across services
- Passed around Slack or pasted into Jira
This is beyond vaults. Beyond rotation. Beyond cleanup scripts. This is eliminating the root cause of secrets sprawl: human and machine access to the secret itself.
Access Governance Is the Missing Layer
Secrets managers help store secrets. But modern infrastructure needs a way to govern access to them—especially in an NHI-dominated world.
StrongDM doesn’t replace your vault. It makes your vault invisible. It transforms access from a risky point-to-point credential exchange into a policy-driven, ephemeral connection—governed, observed, and logged.
In a machine-speed, AI-enabled environment where credentials leak at the speed of automation, that level of control is not just useful—it’s essential.
Take control of non-human identities before secrets sprawl takes over. StrongDM eliminates credential exposure and governs access in real time. See how it works for your environment, book a demo today.
