Credential Proxy for AI Agents Without Secret Exposure

You have two choices when an AI agent needs access to a private repo, an internal API, a cloud CLI, or an MCP tool. You can give the agent a credential and hope the runtime behaves. Or you can give the agent a way to produce authenticated effects without giving it the bearer secret.

For security-minded platform teams, the second option is the real design target. A credential proxy for AI agents moves credential possession outside the agent runtime. The agent can ask for an approved action. A deterministic service decides whether the action is allowed, injects the credential at the boundary, logs the decision, and keeps the raw secret out of prompts, files, environment dumps, tool traces, and model context.

This changes the trust boundary. The secret stays with the broker while the agent receives only the approved capability.

The problem is capability, not storage

Traditional secret management assumes the application process is trusted enough to receive a secret. That assumption weakens when the process is an agent runtime that can read files, run shell commands, inspect environment variables, install dependencies, call tools, follow retrieved instructions, and send outbound requests.

The practical failure modes are concrete:

• A token appears in env, shell history, stdout, crash output, or a tool trace.

• A secret lands in .env, .npmrc, .aws/credentials, .kube/config, or a workspace file.

• A malicious dependency, prompt injection, or retrieved page persuades the agent to print, copy, or transmit sensitive values.

• A broad bearer token lets the agent do everything the user or project can do, even if the task only needed one repository or one API route.

OWASP frames the risk in the same direction. Its LLM01 guidance links prompt injection to sensitive disclosure, unauthorized function access, and command execution. Its LLM06 guidance ties agent risk to excessive functionality, excessive permissions, and excessive autonomy. The AI Agent Security Cheat Sheet calls out data exfiltration through tool calls, API requests, and outputs, then recommends per-tool scoping and audit trails.

The implication is direct: model instructions are not an authorization layer. "Do not reveal secrets" is useful as behavior guidance, but it cannot be the control that protects production credentials.

What a credential proxy for AI agents does

A credential proxy, also called an AI agent credential broker, auth proxy, agent vault, or egress proxy, sits outside the agent runtime. It turns a policy-approved request into an authenticated request without revealing the credential value to the agent.

In a simple version, the agent sends outbound traffic through a proxy. The proxy checks destination, method, path, user, project, agent identity, and session context. If the request is allowed, it injects the right header or token. If not, it fails closed. In a more advanced version, the proxy calls a credential callback, performs OAuth on-behalf-of flow, exchanges a token, asks Vault for a dynamic secret, or resolves a managed vault reference at egress time.

The design goal is narrow: the agent gets capability, not possession.

Reference architecture

A practical agent secrets management design has five separate pieces:

• Agent sandbox. Runs the model-driven workflow, tools, shell, and workspace with the least OS and network access that the task allows.

• Per-session identity. Identifies the user, project, workspace, agent, and session. Shared project identity is simpler, but user-scoped identity gives better attribution.

• Broker or egress proxy. Mediates outbound calls, injects credentials, blocks disallowed destinations, and redacts sensitive material from logs.

• Secret store or identity provider. Holds static secrets, refresh tokens, vault references, dynamic credential policies, or OAuth grants outside the sandbox.

• Policy and audit service. Makes deterministic authorization decisions, records request IDs and policy outcomes, and supports revocation while sessions are running.

This architecture can be implemented several ways. LangChain's Auth Proxy article describes credentials staying outside LangSmith sandboxes while a proxy injects auth headers, enforces egress policy, supports dynamic credential callbacks, and fails closed when callbacks fail. Anthropic's Claude Code secure deployment guidance recommends a proxy outside the agent boundary that injects credentials, enforces endpoint allowlists, logs requests, and keeps credentials in one secure location. HashiCorp's Vault pattern uses OAuth or token exchange, JWT auth, Vault policies, dynamic just-in-time credentials, correlation IDs, and audit logs to preserve user attribution.

The vendor details differ. The control plane shape is converging.

Where MCP helps, and where it does not

MCP authorization is becoming an important part of this stack, but it does not replace a credential proxy by itself.

The draft Model Context Protocol authorization spec is OAuth-oriented for HTTP transports. It defines MCP servers as OAuth resource servers, clients as OAuth clients, and requires protected resource metadata plus audience-bound access tokens for the intended MCP server. Microsoft Foundry Agent Service documentation, last updated on 2026-07-01, lists key-based authentication, Entra agent identity, project managed identity, OAuth identity passthrough, and unauthenticated access for MCP tools. It also recommends OAuth identity passthrough when per-user context must persist and warns that shared project secrets are accessible to people with project access.

That is valuable for remote MCP servers. It creates a path for scopes, user consent, and audience binding.

The weak spot is local stdio MCP. The MCP spec says stdio implementations should retrieve credentials from the environment instead of using the HTTP authorization spec. If a local agent can inspect the environment, read files, or call subprocesses freely, stdio MCP can fall back to the original failure mode: the credential exists inside the boundary you are trying to distrust.

Practical patterns by access type

Private GitHub repositories

GitHub fine-grained personal access tokens are a better starting point than classic PATs because GitHub documents that they can be limited to one owner, selected repositories, and specific permissions. Classic PATs can be broader, including access to every repository the user can access.

Even so, a fine-grained PAT is still a bearer secret. If the agent can read it, it can leak it. For a coding agent, a stronger pattern is to keep the token in a broker, pass Git traffic and GitHub API calls through an approved path, and scope the policy to the target repository, operation, and session. For example: clone and fetch are allowed for repo A, pull request creation is allowed for repo A, admin operations are denied, and calls outside GitHub are blocked unless separately approved.

Internal APIs

For internal APIs, static header injection is operationally simple. It works when the proxy can identify destination and route, then add the right authorization header. The trade-off is policy precision. If the token can call the full API, the proxy must enforce path, method, tenant, and payload constraints before the request leaves the sandbox.

Dynamic credentials give tighter control. The broker can exchange a session identity for a short-lived token with a limited audience and TTL. The agent still might leak a live token if it ever sees one, so the better design is still egress-time injection, not token handoff.

Cloud CLIs and package registries

CLIs are harder than clean HTTP tools because they have their own credential discovery rules. They may read files, env vars, config directories, helper commands, or OS keychains. Vault sidecar injection works well for many traditional workloads, but for agents it can still render the secret as a file or env-equivalent inside the workspace.

If the agent must use existing CLIs, constrain network egress at the sandbox or host level. Do not rely on the CLI respecting a proxy variable if the network can bypass it. Transparent HTTPS proxying can help, but it brings certificate authority management, TLS trust, and compatibility issues across SDKs, package managers, Git, Node fetch, and custom clients.

Managed agent vaults

Anthropic's Managed Agents vault documentation describes credentials stored once and referenced by vault ID at session creation. Environment-variable credentials are represented as opaque placeholders and replaced with real values at egress, so the agent does not see the secret value. That is the right direction: the runtime handles references, while secret material remains write-only and brokered.

The operating question is access control. If a vault is scoped to a workspace, then workspace API keys, project membership, and session creation permissions become part of the credential boundary. Revocation also has to affect running sessions, cached material, and proxy decisions, not only future vault lookups.

Policy decisions that matter

The hard part is not placing a proxy in the path. The hard part is deciding what the proxy should allow.

At minimum, policy should evaluate:

• User identity and whether the user is allowed to delegate this action to an agent.

• Agent identity, project, workspace, sandbox, and session.

• Destination host, protocol, port, method, path, and resource identifier.

• Credential audience, scope, TTL, and refresh behavior.

• Whether the operation requires human approval or step-up consent.

• Whether response data can be stored, logged, sent to the model provider, or included in later tool calls.

Practitioners in Hacker News field discussions were blunt about the failure mode: if the agent has shell access, it can run env or echo an API key. Another discussion identified tight least-privilege tokens as the hard part. Those comments are not formal standards, but they match the engineering reality: possession and policy are different problems.

When env vars are still acceptable

Env vars are not automatically wrong. They are acceptable when the credential is disposable, narrowly scoped, short-lived, and used in a low-risk local workflow. A throwaway token for a temporary sandbox is different from a long-lived production cloud key or a GitHub token with organization-wide reach.

Use a broker when at least one of these is true:

• The agent can touch private source code, customer data, production systems, or internal infrastructure.

• The credential grants access beyond the single task.

• The agent can run shell commands, install dependencies, or read arbitrary files.

• The workflow is multi-user, multi-tenant, or audited.

• Revocation must work during active sessions.

• Prompt injection could influence tool use or outbound requests.

Evaluation checklist

When evaluating a credential proxy for AI agents, ask questions that expose the real boundary:

• Can the agent ever read the raw credential through env, files, tool arguments, logs, or shell output?

• Does the proxy enforce destination, route, method, resource, user, project, and session policy?

• Are tokens audience-bound and short-lived where the upstream supports it?

• Can credentials be resolved per user rather than only through shared project identity?

• Does stdio MCP receive credentials from env, or does the harness add separate controls?

• Are audit logs redacted while still preserving request IDs, policy decisions, token identity, and correlation data?

• What happens when a credential is revoked while an agent run is active?

• Can network egress bypass the proxy?

• How is the broker itself isolated, monitored, rate-limited, and recovered after compromise?

The central trade-off is clear. Env vars and local files minimize integration work, but they place secrets inside the agent's most exposed boundary. A credential proxy adds infrastructure, policy work, and operational responsibility. In return, it lets the agent act without owning the credential.

For founders and platform engineers giving agents access to private repos, APIs, CLIs, and MCP tools, that distinction is the foundation. Capability belongs in the workflow. Credential possession belongs outside it.