Scoped Credentials, Short-Lived Tokens, and Runtime Access: The Security Architecture AI Agents Actually Need

When an AI agent is granted access to a financial API, a code repository, or a communications platform, the security question most teams ask is whether that credential is stored safely. The more consequential question is what happens when it is not. Vault storage, secret rotation policies, and environment variable hygiene are necessary controls, but they address the wrong threat model for agentic systems. The actual risk in a production agent that touches Stripe, GitHub, or Slack is not that the credential will be extracted from storage: it is that the credential, once issued, carries permissions that far exceed what any single task requires. This article examines why blast radius, not storage security, is the foundational problem, and what a runtime credential architecture that addresses it looks like in practice.

Companion piece to our broader work on agent identity and access governance. See AI Agents Need Identity, Permissions, and Audit Trails: The Engineering Architecture Most Teams Are Missing for a detailed treatment of non-human identity governance, least-privilege entitlement models, and audit trail design for agentic systems in production.

The Blast Radius Problem with Long-Lived Tokens

A long-lived API token issued to an agent is, in practice, a standing grant of whatever permissions the token encodes for as long as the token remains valid. In most current deployments, that means an agent authorized to read a user's financial transactions also holds the credential to initiate transfers, modify account settings, or export bulk data, because the token was scoped to the application rather than to the task. If that token is exfiltrated through prompt injection, logged in plaintext by a middleware layer, or exposed through a dependency vulnerability, the attacker inherits the full permission surface immediately. There is no time window in which the credential is valid but the damage is limited, because the credential was never scoped to a limit in the first place. This is not a theoretical edge case: it is the structural consequence of treating agent access as analogous to service-to-service authentication in a microservices context, where long-lived machine credentials are the norm.

Why Vault Storage Alone Does Not Solve This

Secrets management platforms such as HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault reduce the probability of credential exposure at rest. They do not reduce the permission surface of the credential once it is retrieved. An agent that fetches a GitHub token from Vault at task startup and holds it in memory for the duration of a multi-step workflow is still carrying a token that could, if intercepted at any point in that workflow, grant write access to every repository the token was provisioned against. The vault solved the storage problem; it did not solve the scope problem. The distinction matters because the attack surface in agentic systems is not primarily storage: it is the runtime, where the agent is actively making API calls, processing external inputs, and potentially receiving adversarial instructions through the content it retrieves.

Runtime Credential Exchange as an Architectural Primitive

The alternative is to treat credential issuance as a runtime event that is scoped to a specific task, bounded in time, and terminated when the task completes. Rather than fetching a broad token at agent startup, the agent requests a credential at the moment it needs to perform a specific action, specifying the resource and operation required. The credential authority, whether that is an OAuth 2.0 authorization server, an internal policy engine, or a platform-native connector, issues a token scoped exactly to that request and with an expiry measured in minutes rather than days. If that token is compromised mid-task, the attacker receives a credential that is already near expiry and limited to one operation on one resource. The blast radius shrinks from the agent's entire permission envelope to the surface area of a single task.

What Connector Registration Makes Possible

For this model to work in practice, agents need a structured way to declare their integration requirements at registration time rather than acquiring credentials opportunistically at runtime. Vercel's Connect architecture illustrates one approach: integrations are registered as first-class connectors with defined scopes, and the platform mediates credential exchange on behalf of the agent rather than passing raw tokens to the agent directly. The agent never holds the underlying service credential; it holds a session-scoped reference that the platform resolves to the actual token at the point of the API call. This separation means that revoking access to a downstream service does not require hunting for tokens across agent configurations: the connector registration is the single point of control. For engineering teams managing agents that touch multiple external services, this architectural pattern reduces the operational burden of credential rotation and makes the agent's integration surface auditable from a single registry.

Per-Task Scoping in Financial Infrastructure

Mercury's Command product offers a concrete illustration of per-task scoping in a domain where the consequences of over-permissioned access are directly measurable in dollars. Rather than issuing an agent a general banking API credential, Command issues task-specific authorizations: an agent asked to pay a vendor receives a credential scoped to that payee, that amount, and that transaction window. An agent asked to retrieve a balance receives a read-only credential with no payment initiation capability. The authorization is not just time-bounded but operation-bounded, which means a compromised credential from a balance-check task cannot be used to initiate a transfer. This is the practical implementation of least-privilege at the task level rather than at the application level, and it is the model that financial infrastructure demands when agents are operating autonomously on behalf of users.

Audit Trails as a Consequence of Runtime Scoping

One underappreciated benefit of runtime credential exchange is that it produces a natural audit log without additional instrumentation. Because each credential request is a discrete event, the credential authority records what was requested, by which agent identity, for which resource, at what time, and whether the request was granted. This is structurally different from auditing a long-lived token, where the log records that a token was issued and later that it was used, but cannot reliably attribute individual API calls to specific agent tasks. For teams operating under SOC 2, PCI DSS, or financial services regulations that require demonstrable access controls, per-task credential issuance shifts audit evidence from a forensic reconstruction problem to a real-time record. The compliance implication is not marginal: regulators increasingly expect organizations to demonstrate that access was appropriate at the time of each operation, not merely that credentials were stored correctly.

Implementation Considerations for Engineering Teams

Adopting runtime credential exchange requires changes at three layers of the agent stack. The agent orchestration layer must be modified to request credentials at task boundaries rather than at startup, which means the task definition must include sufficient context for the credential authority to evaluate the request. The credential authority itself must be capable of evaluating fine-grained scope requests in low latency, since adding a round-trip to a policy engine on every API call will degrade agent performance if the authority is not designed for high-throughput evaluation. The connector layer must support token injection at the point of the API call rather than relying on the agent to manage credential state. None of these changes are trivial, and teams that attempt to retrofit them onto an existing agent architecture will encounter friction at each layer. The practical implication is that runtime credential exchange is significantly easier to build in from the beginning than to add after the fact, which makes architectural decisions made during initial agent design consequential for the security posture of the system at production scale.