The security community spent roughly a decade getting developers to stop putting passwords in config files. Hardcoded database credentials, static API keys in .envfiles, service account passwords committed to source control — we built tooling, wrote policies, ran training, and eventually made this pattern embarrassing enough that most engineers stopped doing it by reflex.
AI agent architectures are doing it again. At scale. Automatically.
That is a description of how most agent deployments are currently configured, not a metaphor, and it is the problem that secrets management for AI workloads is designed to solve.
The Problem, Precisely
An AI agent is a software process that takes a goal, breaks it into steps, and calls external tools — APIs, databases, services — to complete those steps. Unlike a traditional application that calls one or two services with a predictable credential set, an agent might call five, ten, or fifteen different tools per task, each requiring its own credential. The agent needs an API key for the contract management system, a different key for the vendor portal, a database credential for the financial system, a token for the document store.
The naive implementation — and the current default in most agent frameworks — is to load all of those credentials at startup from a configuration file or environment variable store. The agent reads its config, holds all credentials in memory for the duration of its process, and uses them as needed. This is convenient. It is also exactly the pattern that privileged access management exists to prevent.
The credential surface of an agent workload is not one or two service accounts. It is a collection of credentials, one per tool, multiplied by however many agent instances are running. If those credentials are long-lived — valid for months, rotated on a quarterly schedule, or never rotated at all — then a single compromised agent process hands an attacker persistent access to every system that agent could reach. The blast radius is the entire tool set, and the access persists until someone notices and rotates.
That is the problem. Not a new category of problem, but a familiar one reintroduced at a scale that breaks the operational patterns we built to manage it.
- Secrets management problem: AI agents require credentials for each tool they call, and the default pattern of storing those credentials as long-lived keys in agent configuration creates a large, persistent attack surface that conventional rotation practices cannot adequately govern at agent workload scale.
How Vault-Issued Short-Lived Credentials Work
The solution is to stop treating credentials as configuration and start treating them as runtime artifacts. A secrets vault (HashiCorp Vault is the reference implementation most teams encounter first, though AWS Secrets Manager, Azure Key Vault, and CyberArk's Conjur follow the same pattern) issues credentials on demand, scopes them to a specific use, and expires them automatically.
The mechanism, step by step.
Step 1: The agent run initiates. A procurement workflow kicks off. The agent has a task: check three vendor registrations in SAM.gov, pull the corresponding contract records, and flag any discrepancies. It needs credentials for SAM.gov's API, the contract management system, and the document store.
Step 2: The agent authenticates to the vault. Before calling any external system, the agent presents its identity to the vault. How that identity was provisioned is a separate question — covered in the prior piece in this series — but the vault needs to verify that this agent is who it claims to be before issuing anything.
Step 3: The vault evaluates policy. The vault checks its access policy: is this agent authorized to receive a credential for the SAM.gov API? With what scope? For how long? Policy is defined by whoever administers the vault — typically the security or platform team — and it specifies whether the agent can get a credential and what that credential can do. Read-only access to SAM.gov vendor records. No write access. No access to the payment tables in the financial system.
Step 4: The vault issues a short-lived credential. The vault generates a credential — an API key, a database password, a signed token, depending on what the target system accepts — and attaches a time-to-live (TTL). For a task expected to complete in under ten minutes, a 15-minute TTL is a reasonable bound. The credential is valid for 15 minutes. After that, it is dead, regardless of whether the agent used it.
Step 5: The agent calls the API using the issued credential. The SAM.gov call goes through. The credential works. The agent continues to the next tool, requests a credential for the contract management system, same process.
Step 6: The TTL expires. The task completes in eight minutes. The credential expires at the 15-minute mark. If the agent's process was compromised mid-task and an attacker extracted the credential from memory, they have a seven-minute window. Not a quarter. Not until someone notices. Seven minutes.
Step 7: The next run gets a new credential. When the workflow kicks off again — five minutes later, an hour later — the agent requests a fresh credential. The vault issues a new one. The previous credential is already dead.
You are no longer managing credentials. You are managing credential issuance policy. The vault handles the rest.
- Vault-issued short-lived credentials: Credentials generated at runtime by a secrets vault, scoped by policy to a specific agent and use case, and expired automatically after a defined TTL — replacing static long-lived keys with ephemeral artifacts whose compromise window is bounded by their lifetime rather than by a human rotation schedule.
What This Looks Like at Federal Scale
Consider a civilian agency running a procurement automation workflow. The agent's job is to cross-reference vendor registrations, pull contract history, check for debarment flags, and surface discrepancies for a contracting officer to review. It calls five external systems: SAM.gov, the agency's contract management platform, a debarment database, a document management system, and a financial obligations tracker.
The workflow runs roughly 400 times per day. The agency processes a high volume of modifications, renewals, and new awards, and the agent handles the initial triage for all of them.
With long-lived API keys in configuration: five static credentials, each valid until rotated. If the agent process is compromised — through a dependency vulnerability, a misconfigured container, a supply chain issue in the agent framework itself — an attacker has persistent read access to five federal systems. The keys stay valid until a human notices something wrong and initiates rotation, which in a federal environment with change management requirements might take days.
With vault-issued short-lived credentials: 400 runs per day, five credential requests per run, means the vault issues 2,000 credentials daily. Each expires in 15 minutes. A compromised agent process yields credentials with a remaining TTL measured in single-digit minutes. The attacker's window is not "until someone notices." It is "until the clock runs out on whatever credential they grabbed."
The audit trail also changes. Every credential issuance is a vault log entry. You know which agent requested a credential for which system at what time. When something goes wrong — and in a federal environment, the question is when, not if — you have a complete record of what the agent touched and when, not just what it was configured to be able to touch.
Federal security frameworks are moving toward this pattern for exactly these reasons. NIST SP 800-204D, which addresses authorization for microservices and API-based architectures, and the broader zero trust guidance in OMB M-22-09 both point toward dynamic, policy-driven credential issuance rather than static credential assignment. The agent workload pattern fits cleanly into that architecture — but only if the agent is actually using it.
- Federal procurement scenario: At 400 daily runs across five tools, a vault-issued credential model replaces five static long-lived keys with 2,000 ephemeral credentials per day, each with a bounded TTL — converting a persistent compromise risk into a narrow, time-limited exposure window and generating a complete audit trail in the process.
IDAM Concept Mapping: Service Account Credential Governance
The closest IDAM analog is service account credential governance — the practice of issuing non-human identities scoped credentials, rotating them on a defined schedule, and auditing their use. Your instinct that long-lived credentials in config files are a problem is exactly right, and the least-privilege and rotation principles you'd apply to a service account apply directly here.
Where the analogy breaks: service account governance assumes a manageable number of credentials rotated on a human-operated schedule. An agent workload at scale doesn't have five service accounts to govern — it has potentially thousands of credential issuance events per day, each tied to a specific task instance. Manual rotation governance doesn't survive contact with that volume. The vault-issued short-lived pattern replaces the rotation schedule entirely: credentials expire by design, not by calendar. The governance object shifts from the credential itself to the issuance policy — and that policy lives in the vault, not in a spreadsheet.
The Pattern We Already Eliminated, Reintroduced
There is a version of this conversation where the secrets management problem for AI agents sounds novel. It is not. The pattern of storing credentials in application configuration was identified as a critical vulnerability class before most current agent frameworks existed. The remediation — dynamic credential issuance, short TTLs, policy-driven access — has been available and well-documented for years. HashiCorp published the core vault architecture in 2015. The pattern is not new.
The deployment context is. Agent frameworks made it easy to pass API keys as environment variables and move fast. The security defaults in most agent tooling, as of mid-2026, are not good. Credentials are treated as configuration because that is the path of least resistance, and the teams building agent workflows are often not the teams responsible for credential governance.
This is the conversation worth having with a CAIO or CISO who raises agent credential hygiene. Their team almost certainly understands that long-lived keys are a risk — they do. The live question is whether the agent deployment they are running has a clean answer for how credentials are issued, scoped, and expired at the volume those agents are actually operating. Most don't. Most are running the password-in-a-config-file pattern under a different name, at a scale that makes the original version look quaint.
The vault-issued short-lived credential pattern is the answer. It is not complicated. It is not new. It is just not the default, and until it is, every agent architecture without it is a future incident waiting to be logged.
- The reintroduction problem: Long-lived API keys stored in agent configuration are functionally identical to the hardcoded credentials pattern the security community spent a decade eliminating — the same blast radius, the same rotation failure modes, the same audit gaps — now operating at the volume and automation scale of production AI workloads.