Secret Management for Agents Running in Private Infrastructure

Secret Management for Agents Running in Private Infrastructure.

Why AI agents running in private infrastructure break traditional secrets assumptions

Traditional secrets management was built for a world where software behaves like software: predictable, patient, and mostly asleep. A secret gets loaded at startup, used the way the code says to use it, and rotated on a schedule some human sets and remembers to run. AI agents blow through all three of those assumptions at once. They pick their own tools at runtime instead of following a fixed script, they run continuously with nobody watching the console, and they spin up across dozens or hundreds of concurrent instances without waiting for a human to say go.

The scale of that shift is already outpacing the governance built to handle it. Palo Alto Networks' 2026 Identity Security Landscape report found enterprises now manage 109 machine identities for every human employee, up from 82-to-1 just a year before, and 79 of those 109 machine identities are AI agents. That's a hockey stick with a security team standing at the bottom of it holding a clipboard.

Running everything on private infrastructure doesn't fix this. It feels safer, the way a locked office feels safer than a coffee shop, but the data says otherwise. GitGuardian's State of Secrets Sprawl 2026 found internal repositories are 6x more likely than public ones to contain hardcoded secrets nhimg.org. Internal usually just means unaudited.

Autonomous tool selection breaks the assumption that a credential's use is predictable, continuous runtime breaks the assumption that rotation happens on a human's schedule, and concurrent scale breaks the assumption that request volume stays low enough for a vault to keep up. Everything that follows in this piece is really just an answer to those three gaps, one at a time.

Three failure modes agents introduce that existing vaults were never designed for

Failure mode one: the agent can be instructed. Traditional software does what its code says, full stop. An agent does what its code says and also, partially, what its inputs say, which means anyone who can shape those inputs has a lever on its behavior. This isn't hypothetical. Check Point Research published CVE-2026-21852 alongside CVE-2025-59536, documenting API key exfiltration and remote code execution through malicious project configuration files. OWASP didn't bury this finding either: prompt injection is at the very top of its Top 10 for LLM Applications 2025 7 Best Secret Management Tools for AI Agents in 2026 | Fastio. That ranking matters because it means the attack surface is the agent's actual job description, not some side door someone forgot to lock. Every vault built before this era assumes the process holding a credential can be trusted to behave. Agents can't make that promise about themselves, because their behavior is, by design, steerable by whatever text lands in front of them.

Failure mode two: the agent's context window is observable. Anything that enters that window, through an environment variable, a config file, or a vault lookup, sits in a space that can be logged, inspected, or lifted. Coding agents read project files as a matter of course, and project files often contain.env files sitting right there in plain text, so the credential ends up parked in the session's context simply because the agent did exactly what it was supposed to do. GitGuardian found roughly 24,000 secrets sitting in MCP configuration files on public GitHub, and a good chunk of them were following official setup documentation to the letter. The tooling told people to do the thing that leaks the secret. And then there's CVE-2025-68664 in LangChain Core, rated 9.3 on CVSS, where attacker-injected prompts triggered a serialization routine that dumped all environment variables 7 Best Secret Management Tools for AI Agents in 2026 | Fastio. That's not a bug hiding in a corner. That's the front door.

Failure mode three: the agent can be compromised through its own extension ecosystem. TrendMicro found 335 malicious skills on a single AI agent platform, built specifically to harvest credentials 7 Best Secret Management Tools for AI Agents in 2026 | Fastio. A malicious plugin doesn't need to break in from outside; it runs in the same process, reads the same environment variables, and touches the same filesystem as the legitimate code around it, because agent skills don't get the trust boundary a normal third-party library gets. OWASP's Top 10 for Agentic Applications 2026 backs this up structurally, ranking Agentic Supply Chain Vulnerabilities fourth, right alongside Tool Misuse and Exploitation and Unexpected Code Execution.

A fourth vector gets less airtime: self-hosted model files themselves. The GGUF format embeds Jinja2 chat templates that execute at inference startup in frameworks that don't sandbox the template engine, and separately, Python's pickle deserialization at model load time opens its own high-severity code-execution path, according to the Cloud Security Alliance's AI Safety Initiative. Load the wrong model file, get more than you asked for.

That's not a config setting waiting to be flipped. It's a structural mismatch between the tool and the job.

Which leads to the real diagnosis. The issue isn't that teams are using vaults wrong. It's that vaults built for this earlier model treat possession of a secret as proof you're allowed to have it, and that assumption collapses the moment the thing holding the credential is a process an attacker can talk into misbehaving.

What a production credential incident looks like when these assumptions fail

In April 2026, an AI coding agent deleted a production database at Railway after stumbling on a long-lived API token sitting in an unrelated file. The token wasn't scoped to a task or a directory. It was scoped to an account, with no boundary separating staging from production, so an agent operating in what it thought was a safe sandbox reached straight into live infrastructure. The deletion took 9 seconds How to manage API keys, tokens, and secrets for AI agents — WorkOS. That's the entire window between "everything's fine" and "everything's gone."

Strip the incident down and four root causes fall out cleanly: a static token that never expired, permissions scoped far wider than the task needed, no wall between environments, and no approval gate standing in front of a destructive action. None of those four is exotic. Each one, individually, is the kind of thing a security review would flag on sight. Stacked together, they built a nine-second path from a staging task to a wiped production database.

This wasn't a one-off fluke, either. Some implementations hand the agent every permission the delegating user holds, including entire categories of resources the actual task never touches, whenever agents inherit a human's full session instead of getting their own narrow one. Overprivileged sessions turn into overprivileged agents, which is a bit like giving the delivery driver a key to the whole apartment building because it was easier than cutting a key for just one unit.

The persistence problem is what turns a bad incident into a chronic one. GitGuardian's State of Secrets Sprawl 2026 found that 64% of secrets that leaked back in 2022 are still valid and exploitable today. Detection without automated revocation isn't a security posture, it's a filing cabinet full of confessions nobody acted on.

And the pace of new leaks keeps climbing past whatever teams can review by hand. GitGuardian logged 28.65 million hardcoded secrets added to public GitHub in 2025 alone, a 34% jump over the year before and the largest single-year increase on record, with AI-assisted commits leaking at roughly double the base rate GitGuardian State of Secrets Sprawl 2026. The tools meant to help write code faster are, on the side, leaking the keys to that code faster too.

More than 16% of organizations don't track the creation of AI-related identities at all, according to a 2026 CSA token sprawl analysis, meaning those identities are unmanaged from the second they're born, and that governance gap sits behind all of it. A separate 2024 CSA survey found only 15% of organizations feel highly confident in their ability to prevent attacks based on non-human identities. Confidence, it turns out, is not the same thing as control. AI-related credential leaks specifically surged 81.5% year-over-year in 2025, with surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026 report.

The four architectural principles that replace static credential patterns

Principle one is scoped agent identities. Each agent needs to be its own distinct service account rather than a borrowed slice of a human's session. An agent whose whole job is uploading files to one workspace directory should get read and write access to that directory, full stop, not a master key that happens to open every door in the building. This isn't just good hygiene, either; it's now written into official guidance. Scoped identity is the foundation everything else in this list stands on. You can't hand out short-lived, task-specific credentials to an agent that doesn't have its own identity to attach them to.

Principle two is dynamic, short-lived credentials. No static secret should outlive the session that needed it. HashiCorp Vault's dynamic secrets engine mints a unique credential on request, hands it over, and revokes it once a configurable time-to-live expires, with a one-hour TTL as a commonly documented example. The credential simply doesn't exist past its lease. Generating credentials on demand through OIDC or a dynamic secrets engine shrinks the blast radius of any single theft down to whatever that lease window happens to be. Certificate-based approaches follow the same logic on a longer clock: a certificate with a 30-day expiry gets automatically rotated in before it lapses, the old one gets revoked, and there's no downtime and no manual steps Secure Enterprise AI: Unified Secrets & Non-Human Identity Management. Run the Railway incident back through this lens and it falls apart differently: a task-scoped credential with a short TTL and a wall between staging and production simply never reaches the production database in the first place, because its lease and its scope both run out before it can.

Principle three is runtime injection. The goal here isn't a policy that says "please don't log the credential." It's an architecture where the credential's actual value is structurally absent from the agent's context window in the first place, so there's nothing to accidentally log even if someone tried. The MCP server pattern has the agent ask for access to a tool, the server authenticates on the agent's behalf, and the raw API key never crosses into the agent's view at all. That single design choice cuts the prompt-injection-to-exfiltration chain off at the root, since there's nothing sitting in context for an injected prompt to go fetch. Environment variables fail this test specifically and repeatedly. They appear in crash logs, they're visible to sibling processes, and CVE-2025-68664 already proved they can be dumped wholesale through an injected prompt.

Principle four is automated revocation and audit, where the agent takes part in its own credential lifecycle rather than just consuming whatever it's handed. That means an agent checking its own credential state, noticing drift, pulling a refreshed credential, and moving on, without paging a human every time a rotation happens. Audit trails need to grow up too. OWASP's guidance here is specific: evidence for agentic systems needs provenance, meaning what inputs, policies, retrieval sources, and tool calls actually shaped a given decision, so a team can prove an action stayed inside policy rather than just prove it happened. None of this replaces human judgment on the actions that matter most. OWASP still recommends human approval gates on sensitive or destructive tool calls, and the architecture should make adding one of those gates trivial rather than a special project. Automation handles the routine; a human still gets the final word on anything that can delete a database. And the audit net has to stretch past the vault's own walls: 28% of secrets incidents now start outside code repositories entirely, in tools like Slack, Jira, and Confluence, and those incidents run 13% more likely to be critical than the code-based kind.

Workload identity as the cryptographic foundation: SPIFFE/SPIRE in agent deployments

Before any of the four principles above can work, something has to answer a much older question: how does a vault know the process asking for a credential is actually the agent it claims to be, without handing out a pre-shared secret that just becomes one more thing to steal? That's the gap SPIFFE and SPIRE were built to close.

SPIFFE is the specification, the standard for handing workloads globally unique, cryptographically verifiable identities. SPIRE is the open-source runtime that puts the spec into practice: a Server component acts as the certificate authority, and an Agent component runs on each node handling local attestation and rotating credentials as needed. The property that makes this whole approach worth the setup cost is that identity comes from attestation, from proving facts about the machine and the workload, rather than from distributing a secret that has to be kept secret forever.

Attestation happens in two layers, and neither one requires a pre-shared secret. Node attestation checks the host itself, using cloud provider metadata APIs, a TPM chip, or a Kubernetes platform service account token. Workload attestation goes narrower, checking the specific process using its Linux UID, Kubernetes pod labels, the hash of its container image, or its systemd unit. Both layers rest on cryptographic evidence and operating-system facts that an unauthorized process simply cannot fake its way into, which is a sturdier foundation than "this process happens to know a password."

SPIFFE and SPIRE are not what they might seem. They establish and verify a workload's identity; a secrets management system then uses that verified identity to decide what the workload gets to access. SPIFFE and SPIRE don't store, distribute, or manage the sensitive data itself, no API keys, no passwords. Production deployments already run at real scale, with Uber, Square, and Netflix among the companies running it in practice.

None of this should get oversold as a complete answer for agents specifically, and it runs thin in places. It needs dedicated infrastructure, including attestation nodes, a registration server, and a certificate authority, all of which is real operational weight that not every private deployment wants to carry. Certificate issuance also runs on a timescale that doesn't match agents spinning up and disappearing at high frequency; waiting on a certificate to mint when your agent's whole lifespan is measured in seconds is a poor trade. And SPIFFE solves identity within one infrastructure boundary but doesn't hand you a cross-protocol identity flow. A SPIFFE identity document has no defined mapping to something like an agent card in multi-agent, cross-protocol setups.

SPIFFE and SPIRE fit persistent or semi-persistent agent workloads running inside infrastructure a team controls end to end. Ephemeral, high-frequency agents are better served by the OIDC-based dynamic credential path covered earlier, with SPIFFE layered on top as extra hardening for the host underneath, not as the whole solution.

Evaluating the tooling landscape: what each category of secrets manager offers agents

Judging a secrets manager for agent workloads means asking a narrower set of questions than the ones that mattered five years ago. Can it generate short-lived, scoped credentials on demand instead of just storing static ones. Can secrets get injected at runtime without the raw value ever touching the agent's own process memory. Does it support automatic rotation with configurable time-to-live windows. And can it show, per agent, exactly what that agent touched and when.

HashiCorp Vault is the name most teams already have half-installed somewhere. Its defining trick is the dynamic secrets engine: generate a fresh credential per request, set a TTL (a one-hour window shows up as a documented example), and let it auto-revoke on expiry. Backend support spans AWS, databases, SSH, PKI certificates, and a long tail of others, and its AppRole and Kubernetes auth methods line up well with automated, human-free agent deployments. The tradeoff appears in setup: policy configuration takes real time to get right, and self-hosting means owning unsealing procedures, high availability, and a storage backend yourself; the HCP free tier caps out at 25 secrets, which is fine for a pilot and nowhere near enough for a fleet. Vault fits teams already running agents in production at meaningful scale who need dynamic, short-lived credentials paired with granular access policies.

Akeyless takes a different shape: commercial, cloud-managed from the start, built for multi-cloud environments, and it stretches past plain secrets storage into just-in-time access and password sharing. Its certificate rotation runs automatically, with revocation triggered instantly the moment a compromise is detected, even if a private key has already leaked Secure Enterprise AI: Unified Secrets & Non-Human Identity Management. There's no self-hosted option on the table, which is a deliberate tradeoff for teams that would rather not run the infrastructure themselves, and it lands well for organizations already committed to a zero-trust, multi-cloud posture who'd rather hand the operational weight to someone else.

Neither tool is the universal answer, and picking between them (or something else entirely) comes down to how much infrastructure a team wants to own versus rent. What doesn't change across either choice is the underlying architecture this piece has been building toward: scoped identities, credentials that expire on their own, values that never sit exposed in an agent's context, and an audit trail that can explain not just what happened, but why the agent thought it was allowed to do it. Agent framework integration is a key consideration: does it work with LangChain, CrewAI, and AutoGen. Another consideration is whether there are Python, Go, and JavaScript SDKs. It can be self-hosted or HCP managed, and operates under the BSL 1.1 license, which is no longer open source as of August 2023.