Why AI agents should never hold credentials.

An AI agent does not need to hold API keys, passwords, or tokens to do its job. It needs the effect of authority at the moment an approved action executes. Those are different things, and the gap between them is where most of the risk lives. The safer pattern is credential brokering: the agent requests an action, a boundary checks policy, and only then does a proxy inject a short-lived, narrowly scoped credential into the downstream call. The agent never sees the secret at any point.

The numbers are already against standing secrets

Verizon's 2025 Data Breach Investigations Report found credential abuse to be the most common way breaches begin, at 22% of cases, and 88% of attacks against basic web applications involved stolen credentials[1]. Meanwhile the machine-identity population keeps compounding: CyberArk's 2025 study measured 82 machine identities for every human one, with nearly half holding sensitive or privileged access, and 68% of organizations reporting no identity security controls for AI[2]. Every agent you deploy joins that population. Most machine identities run fixed code. An agent is the first kind whose behavior can be steered by whatever text it reads.

The confused deputy, now with a prompt

Put a standing API key in an agent's environment, configuration, or context window and you have wired a classic confused-deputy setup. The agent has authority. An attacker who cannot touch your systems can still touch your agent, through a support ticket, an email it summarizes, a web page it reads, or a document in its retrieval index. Prompt injection through any of those channels can steer the agent's behavior, and the OWASP Top 10 for Agentic Applications ranks this family of attacks among the most consequential precisely because agents act with real credentials on real systems[3].

If the secret is reachable from the agent's process, one poisoned run can exfiltrate it. After that the attacker no longer needs the agent. They have a standing key, and you have a rotation program and an incident report.

Broker authority instead

The alternative moves every secret out of the agent's reach.

• A default-deny proxy sits on the action path. The agent's request for an action goes to the boundary, not to the target system. No explicit policy answer means no action.
• Policy decides before any credential moves. Identity, delegated authority, approvals, and budget state are checked first.
• The grant is scoped and short-lived. Single-use or time-limited, bound to one action on one resource, injected by the proxy into the downstream call. Enforcement is fail-closed: if the boundary cannot confirm the grant is valid and unused, nothing executes.
• Revocation is one switch. Cutting an agent's authority is a boundary decision, not a hunt for every place a key was copied.

The payoff compounds. Prompt injection cannot leak what the agent never saw. A compromised run is contained to one scoped grant instead of a standing key. And because every grant passes through one boundary, each use lands in the audit trail with its authorization attached.

What to look for in an implementation

1. Secrets never appear in the agent's process, prompt, logs, or error messages.
2. Grants are per-action: single-use or short TTL, scoped to a specific resource.
3. The boundary is default deny and fails closed, including under partial outages.
4. One revocation point covers every agent and every credential.
5. Every grant issuance and use is recorded with the decision that allowed it.

Sources

1. Verizon, 2025 Data Breach Investigations Report.
2. CyberArk, 2025 Identity Security Landscape.
3. OWASP GenAI Security Project, Top 10 for Agentic Applications, December 2025.