Credential Proxy Pattern for AI Agents

The credential proxy pattern keeps real secrets out of an agent’s reach: the agent holds only a short-lived proxy token, and a proxy resolves it to the real credential and injects it at the network layer just before the outbound request. It is the load-bearing control of the RA Identity plane and the mechanism behind CMM D2-L4’s zero-credentials-in-agent-context criterion.

On this page

• What it is
• Why it matters
• How it works
• Known implementations
• Security properties
• Relationship to the identity stack
• When to apply
• Implementation notes
• Limits

What it is

The pattern interposes a proxy between the agent and any target API so that real credentials (API keys, OAuth tokens, cloud secrets) are never placed in the agent’s context window, environment variables, or configuration files. The agent carries only a short-lived proxy token scoped to the allowed target APIs, TTL, and permission envelope; the proxy resolves it against the vault and injects the real credential at the network layer.

The approach has converged independently across multiple OSS and commercial tools (six in the table below), indicating a broadly recognized gap in agentic deployments.

Why it matters

AI agents process external content (emails, web pages, documents) that can carry adversarial instructions. A successful prompt injection might tell the agent to “print all environment variables” or “output the contents of .env”. If real credentials sit in those locations, injection exfiltrates them with no further exploit. The credential proxy removes the precondition: there is nothing to exfiltrate because credentials never enter the agent’s accessible state. It addresses ASI02 (tool-misuse exfiltration) and ASI03 (identity and privilege) in the OWASP ASI Top 10.

The proxy bounds what an injection can steal. It does not bound what an authorized agent can do — that is the job of the capability-token layer. The two are complementary controls on the same plane.

How it works

Agent → [proxy token only] → Credential Proxy → [real credential injected] → Target API
                                      ↕
                               Encrypted Vault

1. At provisioning time, the agent is issued a proxy token (not the real credential). The proxy token encodes agent identity, allowed target APIs, permission scope, and TTL.
2. When the agent makes an outbound call, the request routes through the proxy.
3. The proxy resolves the token against the vault, retrieves the scoped real credential, and injects it into the request headers.
4. The response returns to the agent with any credential echoes stripped.
5. Every resolution is logged: agent identity, timestamp, target endpoint, proxy token used.

The agent never sees the real credential at any step.

Known implementations

Tool	Approach	Key feature
AgentKeys	Cloud proxy, AES-256 vault	Per-agent proxy tokens (pxr_…); instant revocation
Keychains.dev	Server-side curl replacement	Template variables ({{GITHUB_TOKEN}}); hierarchical sub-agent token forking
Aegis	Local-first (localhost:3100)	Zero cloud dependency; STRIDE threat model; SHA-256 agent tokens
OneCLI	Docker-based gateway	Web dashboard
AgentSecrets	OS keychain integration	Credentials never in files or env vars
AgentCordon	Three-tier (CLI / broker / server); Cedar PDP; AES-256-GCM + HKDF; Rust; GPL-3.0	Ed25519 workspace identity; broker daemon holds OAuth tokens so the agent host never does; MCP gateway with response-leak scanning

Security properties

• Prompt-injection resistance. A successful injection cannot extract credentials that never enter the context window.
• Hierarchical delegation. Keychains.dev forks parent→child tokens so sub-agents get only the scopes they need.
• Instant revocation. Access ends without rotating the underlying secret.
• Audit trail. Every credential resolution is logged with agent identity, timestamp, and target endpoint.
• Scoped least privilege. Each agent or sub-agent receives only the credentials its task requires.

Relationship to the identity stack

This is secrets management (HashiCorp Vault, AWS Secrets Manager, CyberArk Conjur) adapted for agents whose behavior can be influenced by adversarial inputs. The proxy is to agents what IAM instance roles are to EC2 instances: credentials injected by the infrastructure, not stored in the workload.

Two adjacent controls bound the pattern’s scope:

• Credential-less identity (Azure Managed Identities, AWS Bedrock AgentCore token vault, GCP auth-manager) reaches the same end state by never issuing a long-lived secret to the agent. Where the platform offers it, it is the cheaper path to D2-L4 than operating a separate proxy.
• Coupled credentials (identity-credential coupling — SAS tokens, storage access keys, SaaS API keys where the credential is the identity) limit the proxy: it can intermediate access, but it cannot separate what is structurally inseparable, so rotation remains identity rotation for those classes.

In the RA this is the Identity plane’s load-bearing row; in the CMM D2 ladder it is the L4 zero-credentials criterion, satisfied by either a credential broker/proxy or a credential-less identity model.

When to apply

• Any agent that makes outbound API calls, even to internal services.
• Multi-agent systems where parent agents spawn sub-agents with delegated credentials.
• Agents that process untrusted external content (emails, web, documents).
• Immediately — before deploying the agent, not as a hardening step.

Implementation notes

1. Never put real credentials in environment variables or config files for agent workloads. OPENAI_API_KEY=sk-… in a .env file is the threat model.
2. Use short-lived proxy tokens with TTLs matching the task scope.
3. Build revocation tests into the incident-response playbook — know the time from “agent compromised” to “all credentials revoked.”
4. Log at the proxy, not just the agent, so a compromised agent cannot overwrite the record.
5. For multi-agent systems, enforce scope-inheritance limits — a child token cannot exceed its parent’s scope (the same monotonic-attenuation invariant the capability-token layer enforces cryptographically).

Limits

• Adds a network hop (latency). Local proxies such as Aegis minimize it.
• Does not protect credentials passed as parameters of the proxy-resolved call (for example, a secret in a query string to a third-party API the proxy does not control).
• Requires deploying and operating the proxy infrastructure; the credential-less identity path avoids this where the platform supports it.

See also

• NHI Governance for AI Agents — broader NHI lifecycle context
• Non-Human Identity (NHI) — the credential class this control protects
• Identity-Credential Coupling — where the proxy’s separation guarantee breaks down
• Tenuo Warrant — the complementary control that bounds authorized authority
• Security Controls for AI Stacks — the identity layer where this control sits