Credential Management Patterns for Tool-Calling AI Agents

Tool-calling AI agents cannot safely hold raw credentials, because the loop that executes their actions is itself untrustworthy. Sound credential management for these systems has less to do with where a secret sits in storage and more to do with whether the architecture separates the systems that hold access from the systems that decide how to use it.

Why tool-calling agents cannot safely hold raw credentials

An agent's execution loop runs on two inputs at once, and neither can be trusted on its own terms. The first is the instructions it receives, which can be injected or manipulated by anything the agent reads, a document, an email, a web page, a line of metadata. The second is the code path those instructions trigger, a sequence of tool calls that the agent itself assembles at runtime, in an order no engineer fixed in advance. A traditional application holds a secret inside a deterministic code path: the branches are known, the calls are known, and a credential sitting in that path is exposed only to the extent the code itself is exploitable. An agent has no such fixed path. Its tool-call sequence is shaped moment to moment by a language model reasoning over content it did not generate and cannot fully verify, so a credential placed inside that loop is exposed to every way the model's reasoning can be steered off course.

That distinction stopped being theoretical in May 2026, when Composio disclosed an incident that traced back to a single compromised Gmail OAuth token belonging to a Composio employee. The attacker used that token to intercept magic-link sign-in emails, gained access to internal systems, moved through an internal agentic monitoring tool, registered malicious tool definitions, and escalated to arbitrary code execution inside the tool sandbox. Composio's own disclosure states that the attacker "demonstrated deep knowledge of our API surface and internal architecture," and reporting on the breach puts the number of API keys exfiltrated at approximately 5,241. None of the controls that failed were about password strength or rotation schedules. They failed because the systems holding credentials and the systems executing agent actions were never structurally separated, so one compromised token became a path all the way to code execution.

The specific failure modes that arise when agents hold standing credentials

Standing credentials granted to an agent at deployment time produce at least four distinct failure modes, and none of them show up until the agent starts acting on its own.

The first is confused deputy risk. An agent acting on behalf of one user can end up carrying credentials that also reach another user's data, because the credential was scoped to the agent's service account rather than to the specific user and task it was delegated to handle. Arcade.dev's 2026 authentication platforms guide identifies this as a direct consequence of shared service accounts and static API keys combined with indirect prompt injection: the agent has no internal mechanism for distinguishing its own authority from the authority it happens to be exercising on someone else's behalf.

The second is credential drift. API keys and OAuth tokens get issued once, at setup, and are rarely revisited after that. As an agent's responsibilities expand over time, its credentials tend to accumulate permissions rather than get reissued at the narrowest scope the current task actually needs.

The third is scope inheritance between agents sharing an environment. Composio's post-incident analysis names this directly: the structural control missing from its architecture was scope isolation between a monitoring function and a remediation function. The elevated credentials the remediation tool carried were the same credentials available inside the sandbox once the attacker had registered a malicious tool definition. A monitoring agent's access became a remediation agent's access by proximity, not by any policy decision.

The fourth is the absence of any enforcement point at the moment each tool call executes. Once a credential has been issued to an agent, it is usable for any action that credential permits, and nothing checks whether the specific action about to run is authorized for the task and user context the agent is operating under right now. The paper introducing the Open Agent Passport specification (OAP), published in March 2026, names this the pre-action authorization gap: the decision to execute a tool call is made either by the model itself, which is a probabilistic, alignment-based judgment, or by ad hoc application-layer input validation. Neither one amounts to a security-grade authorization layer, and neither enforces a declarative policy. The same paper reports that security researchers found more than 492 MCP servers exposed in production without authentication or encryption, and documents CVE-2026-26118, an SSRF vulnerability in an Azure MCP Server tool with a CVSS score of 8.8, exploited by sending specially crafted input as an authorized, legitimate user. The attacker in that case did not need to steal anything. What was missing was any policy governing what a legitimately held credential was allowed to do.

What a token vault does and does not do

The first architectural answer to this problem is to stop letting the agent hold the credential. A token vault is a separate service that stores, refreshes, and revokes credentials on the agent's behalf; instead of an API key or OAuth token sitting in the agent's context window or environment variables, the vault injects the correct token at the moment a tool call actually needs one, logs that it did so, and the agent never sees the raw secret. Nango's 2026 guide describes the full set of responsibilities this covers: encrypted storage at rest, refresh and rotation across the credential's lifecycle, authentication of the agent itself, per-request injection, per-identity scoping, and an audit log of every credential use. The same guide explains why this matters more for agents than for conventional applications: most agents have no browser available to complete an interactive OAuth consent flow and no secure local storage primitive, so without a vault the realistic fallback is a long-lived API key that nobody ever rotates.

A compromised agent cannot read back the tokens it is using, so if a prompt injection exfiltrates the agent's environment, it finds only a placeholder or an opaque reference. WorkOS's architecture comparison, published in September 2026, describes how Google's Managed Agents implementation enforces this: credentials are write-only through the API, no endpoint ever returns them, and when a credential is exposed as an environment variable, that variable holds a placeholder string. An egress proxy substitutes the actual credential only when a request is headed to a domain already listed in that credential's trusted_domains configuration; a request carrying the placeholder toward any other host gets rejected. The same comparison describes Rubrik's approach, which mints a new token for each individual tool call rather than injecting one pulled from storage, so a leaked token is bounded to a single operation and expires as soon as that operation completes.

What vaulting does not remove is the vault's own willingness to grant access whenever the agent asks for it. If an agent has been manipulated by a prompt injection into calling a tool it should never call, the vault has no basis for refusing: it will inject the credential for that call exactly as it would for a legitimate one, because credential separation and call authorization are two different controls answering two different questions. Composio's remediation illustrates the boundary of what vaulting alone fixes. Post-incident, the company's APIs no longer return connected-account tokens or custom OAuth client secrets, OAuth credentials are encrypted with envelope encryption, and API keys and session keys are stored only as hashes. Those changes close off storage exposure. They say nothing about which agent action should be authorized to request which credential in the first place, and that question sits in a separate layer.

Per-call token minting as a tighter scope boundary than vault injection

A vault-injected token, even a well-governed one, can remain valid for an entire session or longer, and a token that lives that long can be stolen and replayed for any call the session still permits. Minting a fresh, short-lived token for each individual tool call closes that window: the token is scoped to one operation and expires the moment that operation finishes, so a stolen or intercepted token has no use beyond the single call it was issued for. WorkOS's architecture comparison treats Rubrik's per-tool-call minting as a distinct design choice from vault injection for exactly this reason: each call receives a freshly minted token, and the token's lifetime is bounded to that one operation.

Minting at this granularity also lets scope be set as narrowly as the current call allows, rather than at the width of everything the agent might eventually need. Arcade.dev's analysis of production agent authentication frames the durable version of this pattern as two identities plus delegated context: the agent's own identity, the user's identity, and a task-specific authorization context evaluated fresh at the moment of the call. An agent does not need standing access to a SaaS system in the abstract. It needs to execute one specific action, on behalf of one specific user, inside one specific task, and a properly minted token should encode exactly that intersection and nothing wider.

This has a direct bearing on the confused deputy risk described earlier. A token minted for a specific user-agent-task triple carries that delegation context inside it, so a resource server can verify not just that the caller holds valid credentials but that those credentials were granted for this user and this task specifically, rather than borrowed from a broader service account that happens to reach further than the current request requires. The tradeoff is latency: minting a token per call adds a real cost at the credential layer compared to reusing one already injected into a session, and that cost has to be weighed against the exposure it closes.

Pre-action authorization as the enforcement layer that vaulting and minting cannot replace

Scoping credentials tightly and minting them per call still leaves one question untouched: whether the call being made is the right call. An agent operating on manipulated instructions can request exactly the correct, narrowly scoped, freshly minted credential for an action it should never have taken in the first place, because nothing between the agent's decision and the tool's execution is checking the decision itself. That is the job pre-action authorization does, and it is a different job from anything vaulting or minting performs. Vaulting and minting govern what secrets an agent can reach. Pre-action authorization governs whether a specific tool call, with its specific arguments, is permitted to run at all, given the current user, the current agent, the current task, and the delegation context attached to it.

The OAP paper frames this gap in direct terms: current safety architectures lean on model alignment, which is probabilistic and set at training time, and on post-hoc evaluation, which is retrospective and runs in batches after the fact. Neither gives a deterministic, policy-based decision at the level of an individual tool call, made before that call executes. The paper's reference implementation answers the gap with a synchronous interception layer: every tool call is evaluated against a declarative policy covering user, agent, task, resource, scope, and operation, before it runs, and the decision, whichever way it goes, produces a cryptographically signed audit record. The adversarial results reported are the strongest evidence that this layer changes outcomes rather than merely documenting them: under a permissive policy, social engineering succeeded against the model 74.6% of the time; under a restrictive OAP policy enforcing the same declarative rules, a comparable population of attackers achieved a 0% success rate across 879 attempts. The gap is between a model guessing at whether an instruction is legitimate and a policy layer that does not have to guess, measured in the paper at a median of 53 milliseconds per decision, fast enough that synchronous interception does not noticeably slow an agent down in ordinary tool-call workflows.

This layer complements sandboxing. A sandbox contains the damage a successful attack can do once it is running. It does not stop an unauthorized action from running inside the sandbox in the first place, which is what pre-action authorization is positioned to do before the sandbox ever becomes relevant. The "Comment and Control" class of vulnerabilities documented in CI/CD research makes the distinction concrete: agents processing untrusted GitHub metadata, pull request titles, issue bodies, HTML comments, were manipulated into exfiltrating legitimate, in-scope credentials, API keys and access tokens the agent was fully entitled to hold, by posting them back through GitHub itself as comments. The credential was valid. A vault would have issued it without hesitation, because nothing about the request looked like credential theft from the vault's point of view. What was absent was a policy check on whether this tool call, posting a comment containing a secret, was authorized for this task.

Pre-action authorization also makes least-privilege a live condition. Instead of fixing a capability at deployment and hoping the agent exercises it responsibly for the life of its deployment, the policy gets evaluated again at every call, so scope appropriate earlier in a session can be narrowed, or revoked outright, as the task itself changes shape.

Why tool-level permission checks are not enough: argument-level enforcement

A policy that only asks whether an agent is allowed to call a given tool stops one step short of where the risk actually lives. Authorizing "this agent may call the file-write tool" or "this agent may call the payments API" says nothing about what the call is actually going to do once it runs, because the danger in most of these incidents sits inside the arguments, not inside the choice of tool. An agent authorized to post a GitHub comment is still authorized to post a comment containing a secret, unless the policy inspects the content of that comment rather than merely the fact that a comment-posting tool was invoked. An agent authorized to call a payments API is still authorized to transfer an unlimited amount to an arbitrary account, unless the policy constrains the amount and the recipient as conditions of the call rather than treating "payments API, allowed" as the end of the question.

Enforcement at the tool level answers whether an action class is permitted in principle. Enforcement at the argument level answers whether this particular invocation, with these particular parameters, stays inside the bounds the task and the delegated user actually authorized, and that second question is where most of the failure modes described earlier actually resolve. Confused deputy risk appears in an argument, the identifier of whose data is being touched, not in the name of the tool being called. Credential drift appears in the scope of what a call requests, not in whether a call of that type is allowed to exist. A policy layer that stops at the tool boundary leaves exactly the gap that CVE-2026-26118 exploited: an authorized caller, a permitted tool, and a crafted parameter doing the damage. Closing that gap means the authorization decision has to look at what the call is actually asking the system to do, every time, before it does it.