Credential brokering for AI coding agents: why tokens should stay hidden

At a glance

What this is: The post argues that AI coding agents should not hold live credentials, because any credential the agent can reach can also be leaked or misused.

Why it matters: This matters because identity teams now have to govern agent-accessed secrets, delegated tool use, and ephemeral privilege with the same discipline they apply to service accounts and other NHIs.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Riptides' analysis of AI coding agent credential brokering and token exposure

Context

AI coding agents create a familiar identity problem in a new runtime: the agent needs access to repos, APIs, and build systems, but the moment a live token is placed inside the agent’s process, it becomes reachable by prompts, tools, and anything that can influence execution. The primary issue here is AI coding agent credential exposure, not model quality.

That is why this topic belongs in NHI governance as much as in application security. When a process can read a token, any instruction path that reaches the process can potentially exfiltrate or misuse that token, which makes identity placement and token brokering the real control point.

The article’s starting position is typical of modern AI-assisted development: teams want agents to act on their behalf, but they have not redesigned the credential boundary around that delegation. That gap is now operational, not theoretical.

Key questions

Q: How should security teams prevent AI coding agents from leaking credentials?

A: Keep credentials out of the agent’s process boundary, then broker access at the control layer so the agent never sees the reusable secret. That reduces the impact of prompt injection, malicious tool output, and supply-chain abuse because the runtime cannot exfiltrate what it cannot read. Scoping still matters, but placement is the first control.

Q: Why do AI coding agents create a different token risk than normal automation?

A: Because the agent is making runtime decisions from untrusted text, not just following a fixed script. If a token is reachable inside that environment, any prompt, tool response, or poisoned repository content can become a path to disclosure. The risk is therefore governance of delegated execution, not only secret storage.

Q: What breaks when credentials are embedded in agent configurations?

A: Embedded credentials break point-of-use governance. The secret can be invoked repeatedly, passed downstream into other tools, and remain active long after the original workflow changes. That makes revocation slower, audit trails weaker, and access reviews less meaningful because the control is attached to storage, not actual use.

Q: Who is accountable when an AI agent leaks a developer token?

A: The organisation remains accountable, because the agent was given access to a credential that should have been governed as a non-human identity asset. PAM, IAM, and lifecycle controls still apply, but they must be adapted to delegated tool use, short-lived access, and clear ownership for the broker or control plane.

Technical breakdown

Why direct credential placement inside an AI coding agent fails

An AI coding agent is not a passive script. It is a process that can inspect files, invoke tools, and react to text from repositories, prompts, and MCP-connected systems. If a token is stored in its environment or filesystem, the agent itself can read it, but so can injected instructions, malicious package hooks, and any tool output that gets interpreted as context. The control failure is not just exfiltration after compromise. It is that the credential sits inside the trust boundary of a runtime that is designed to process untrusted input. Once that happens, prompt injection becomes a credential access problem, not only a prompt safety problem.

Practical implication: keep live secrets outside the agent process boundary so untrusted text cannot directly reach them.

How credential brokering changes the trust model

Credential brokering moves the secret from the agent’s address space to a control layer that binds identity, destination, and policy. The agent sends a placeholder or unauthenticated request, and the broker inserts the real credential only at the point of use. That design reduces the attack surface because the token never appears in the shell environment, file system, or model context. It also creates clearer governance boundaries for workload identity, because the credential is no longer a general-purpose artefact the agent can reuse elsewhere. The key architectural shift is from possession-based trust to routed, scoped entitlement.

Practical implication: bind credentials to destination-specific identity rules rather than letting the agent possess reusable tokens.

Why MCP and tool access expand the exfiltration surface

MCP servers and other tool connectors widen the path from context to action. An agent may not need a credential to start, but once a connected tool asks for auth, the developer often supplies a token that persists across later prompts and tool calls. That creates a session-shaped exposure window, where multiple sockets, processes, and requests can all inherit the same privilege. The article’s core insight is that the danger is not limited to browser-like theft. It includes indirect leakage through logs, environment inspection, manipulated config files, and any downstream tool that accepts the credential once it is present.

Practical implication: treat tool connectors as part of the identity perimeter and scope their credentials to one destination and one purpose.

Threat narrative

Attacker objective: The attacker wants to turn the agent’s legitimate access into reusable credential theft that can be used to expand access beyond the original session.

1. Entry occurs when an attacker injects malicious instructions into repository text, package content, or connected tool output that the agent consumes during normal work.
2. Escalation occurs when the agent is prompted or tricked into reading a reachable credential from its environment, files, or tool configuration.
3. Impact occurs when the leaked token is reused to access repositories, APIs, or developer infrastructure, allowing data theft, repository manipulation, or further supply-chain abuse.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Credential brokering is becoming the correct control pattern for AI coding agents, not a niche hardening measure. Once an agent can inspect files, invoke tools, and respond to untrusted text, token possession becomes the wrong security primitive. The control question is no longer whether the agent can authenticate, but where the secret exists relative to the runtime that can be steered. For practitioners, that shifts attention from token strength to token placement.

Prompt injection is an identity problem when the injected text can reach a reachable credential. The attack does not need to defeat the model to succeed. It only needs to persuade the agent to read or forward a token that was already inside its trust boundary. That is why AI coding agent governance must be treated as delegated non-human identity management, not as isolated content filtering.

Identity does not select or combine tools dynamically mid-session was designed for a condition where action paths are bounded before execution begins. That assumption fails when an AI coding agent decides which tool to call next based on context it is still processing. The implication is that least privilege cannot be fully reasoned about at provisioning time alone, because the reachable action set changes inside the session.

Session-scoped use is the right mental model for agent access, but only if the session never holds the secret. A proxy or broker that injects credentials on the wire narrows the exposure window, yet it also highlights how fragile session trust becomes when every tool call can be influenced by prior context. Practitioners should read this as a governance warning about credential reachability, not as a simple proxy versus non-proxy debate.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• For a broader control lens, 52 NHI Breaches Analysis shows how weak lifecycle governance turns reachable credentials into recurring breach paths.

What this signals

The governance lesson for AI-assisted development is that agent access should be designed like any other non-human identity estate. Once developers can place long-lived tokens into agent contexts, the organisation inherits the same visibility, lifecycle, and offboarding problems it already has with service accounts, only now the exposure is runtime-driven.

Credential reachability debt: this is the accumulation of secrets that remain technically valid, operationally reachable, and poorly attributed across agent workflows. When that debt grows, the control problem shifts from stopping one exfiltration attempt to redesigning how credentials are introduced, bounded, and removed across the development toolchain.

Teams should expect identity review processes to become more central to AI coding governance. The practical next step is to connect developer productivity tools to identity and secret policy, then watch for any workflow where an agent can still read a token that a human would never be allowed to paste into chat.

For practitioners

• Separate token possession from agent execution Keep live credentials outside the agent process, shell environment, and workspace so the runtime never has direct read access to reusable secrets.
• Scope every agent credential to one destination Bind each credential to a single service, repository, or API so a compromised agent cannot reuse the same token across GitHub, cloud consoles, and internal tools.
• Treat MCP tools as identity-bearing surfaces Review every connected tool, including MCP servers, for how it requests, stores, and reuses credentials before allowing the agent to call it.
• Eliminate long-lived developer tokens from agent workflows Replace personal access tokens in environment variables or local config with brokering or short-lived access patterns that remove durable secrets from the workstation.
• Test for prompt-to-secret exfiltration paths Run red-team scenarios that try to move from injected text to .env access, token disclosure, and outbound exfiltration so you can see where the boundary fails.

Key takeaways

• AI coding agents turn credential placement into the primary security decision, because any secret they can reach can also be influenced or leaked.
• Brokered, destination-bound credential delivery reduces exposure far more effectively than relying on stronger tokens inside the agent process.
• Identity teams should govern agent workflows as NHI estates, with explicit attention to visibility, lifecycle control, and prompt-to-secret exfiltration paths.

Key terms

• Credential Brokering: Credential brokering is the process of using a trusted identity proof to issue a separate credential for a target system that cannot accept the original identity natively. It is useful for compatibility, but it also becomes a control point for scope, duration, logging, and revocation.
• Agent-held Secret: An agent-held secret is any credential placed inside the runtime of an AI agent, including environment variables, files, or in-memory configuration. This is a high-risk pattern because the agent processes untrusted text and tool output, so the secret becomes reachable by both legitimate actions and malicious instructions.
• Prompt-to-secret Exfiltration: Prompt-to-secret exfiltration is the path from injected text to credential disclosure. It occurs when malicious content convinces an agent to read, print, or forward a token it can access, turning a language interaction into a credential theft event.
• Session-Scoped Access: Session-scoped access is permission that exists only for a defined task or time window and is expected to end when the task ends. For NHI governance, it reduces lingering authority and makes AI-driven activity easier to review, revoke, and investigate when behaviour changes.

What's in the full article

Riptides' full post covers the operational detail this post intentionally leaves for the source:

• The exact daemon attach and identity binding workflow used to broker credentials on the host.
• The step-by-step GitHub token demonstration showing how a dummy token preserves functionality without exposing the real secret.
• The implementation details behind destination-scoped credential injection for workstations, CI runners, and Kubernetes nodes.
• The discussion of auditability, AI session attribution, and why the model treats one agent task as one control unit.

👉 The full Riptides post walks through the demo, the credential injection model, and the threat history behind agent-held tokens.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing identity security practice, it is worth exploring.