Identity and execution
Should an Agent Ever See a Secret?
Credentials should be execution artifacts, issued to an attested workload for one governed effect—not durable knowledge available to an agent.
The answer should usually be no. An agent may be authorized to cause an effect, but it should not be entrusted with a reusable secret that can cause many effects beyond the governed path.
This is not an argument for credential-free systems. A database, SaaS API or cloud service still needs an authenticated caller. The architectural question is where that authority lives, when it is issued, and whether it can escape into prompts, tool definitions, configuration, memory or general-purpose traces. In an autonomous organization, those locations are not secure boundaries. They are working surfaces: copied between processes, summarized, logged, inspected and sometimes exposed to untrusted input.
The stronger design is to treat credentials as execution artifacts. The model requests an organizational effect. A governed runtime decides whether that effect is allowed. Only then does an isolated executor obtain the narrowly constrained authority required to perform it.
Authorization to act is not possession of a secret
An agent can state an intent such as: update this customer record to reflect an approved address change. That is not the same thing as holding a database password, a long-lived cloud access key, or a broadly scoped API token. The first is a request that can be evaluated in context. The second is portable authority: once copied, it may be usable outside the agent runtime, after the task has ended, and for operations never considered in the original decision.
This distinction matters because agent reasoning is intentionally flexible. An agent can select tools, combine information and revise plans. It should not also become a secret container. A prompt injection that changes a plan is already a governance problem. A prompt injection that extracts a reusable credential converts that problem into an access problem with a potentially much longer life.
The model should express the effect it needs. The runtime should hold and shape the authority that can produce it.
Zero-trust architecture supports this separation. NIST SP 800-207 rejects implicit trust based solely on network location or asset ownership. An executor on an internal subnet should not inherit permission merely because it is near a protected system. Each protected interaction needs authentication and authorization appropriate to that interaction.
A practical credential boundary
A governed runtime can make the boundary concrete with a sequence that is deliberately more structured than a tool call:
- Agent → governed effect request. The agent requests a defined business effect, identifying the actor or delegation context, purpose, target and intended operation.
- Policy decision. The control plane evaluates whether the effect is permitted under current organizational policy and records the decision.
- Workload attestation. The runtime authenticates the specific executor that will act. SPIFFE is useful here: its SVIDs are cryptographically verifiable workload identity documents, and its Workload API can identify local workloads without applications carrying authentication secrets.
- Credential exchange or controlled gateway. The runtime either performs the operation through a governed gateway, or issues an execution-specific grant to the isolated executor.
- Isolated execution and lifecycle record. The executor makes the protected call; the runtime records the use and the outcome without retaining the credential body.
This arrangement gives the model authority to ask, not authority to carry. It also makes denial meaningful. A rejected effect request leaves no broadly capable token in the agent context waiting to be used by a later plan.
Shape a grant for a destination and a moment
OAuth 2.0 Token Exchange, defined in RFC 8693, provides useful semantics for this model. It distinguishes delegation from impersonation and allows a request to identify a target resource or audience and scope. A broker can therefore exchange authenticated runtime authority for a token shaped for one destination and one allowed set of operations, rather than handing the executor a general credential.
The grant should be short-lived, audience-restricted and as narrow as the protected system permits. Temporary credentials are an established operational pattern: AWS recommends IAM roles and temporary security credentials instead of embedded long-term access keys, while AWS STS generates credentials dynamically and gives them a configured expiry. Vault can generate unique database credentials on demand and attach leases with TTLs that can be revoked individually or by prefix.
Short lifetime is valuable, but it is not magic. A stolen credential can still be abused while valid. Nor is expiry confirmation that a downstream account has been invalidated. Vault documents that dynamic-secret revocation can fail when it cannot communicate with the target system. A runtime must record requested revocation separately from confirmed invalidation, then continue to reconcile unresolved cases.
Bind use to the executor when the target supports it
A conventional bearer token is useful to whoever possesses it. Sender-constrained tokens reduce that portability. RFC 9449 defines DPoP, which binds an access token to a public key and requires proof of possession when the token is used. RFC 8705 describes mutual-TLS certificate-bound access tokens, binding use to the client certificate. These mechanisms do not eliminate replay or delegation abuse: proof validation, audience restriction, request binding, protected keys and short lifetimes still matter. But they make a copied token less useful than an ordinary bearer token.
The executor is the right place for the private key or client certificate because it can be isolated and attested. It is the wrong place for the language model’s visible context. SPIFFE’s short-lived, automatically rotated identity materials offer a basis for authenticating that workload, but SPIFFE is not an authorization system. Business purpose, actor authority and operation-level policy remain the runtime’s responsibilities.
The audit record must describe authority, not duplicate it
Autonomous organizations need to explain not only that a request reached a service, but why that request was permitted and what authority was actually exercised. The record for an execution grant should include the grant identifier, policy-decision identifier, workload identity, delegation chain, purpose, target resource, approved operation, constraints, issue and expiry times, use events, and revocation request and confirmation outcomes.
It should not include raw credentials, private keys or full token bodies. Those are not evidence; they are new copies of the thing the architecture is trying to contain. Where correlation is needed, identifiers and appropriate hashes can support it without turning the audit system into another secret store.
Kubernetes offers a related operational lesson. It recommends projected service-account tokens, and notes that bound tokens can be invalidated when associated Pods or ServiceAccounts are deleted. Identity and credential lifecycle should follow the lifecycle of the workload and the work, not the lifetime of an application deployment or an agent’s memory.
What changes in the operating model
This architecture moves a difficult decision out of prompt design and into the execution path. Tool specifications should describe available effects and required inputs, not embed API keys. Memory can retain approved context, references and decision records, but not durable access material. The credential broker becomes a policy-enforcement component coupled to workload identity, executor isolation and lifecycle reconciliation—not merely a wrapper around a secrets manager.
Some effects should not produce a credential at all. Where a gateway can validate the request and perform a bounded operation itself, that is often the cleaner boundary. A grant is necessary when the executor must interact directly with a target service; it is not the default product to hand to every tool.
The standards pieces are available, even if their integration is an engineering discipline rather than a finished universal product. SPIFFE supplies workload identity. OAuth token exchange supplies delegation vocabulary. DPoP and mutual TLS can constrain token use. STS and Vault demonstrate temporary and leased credentials. The IETF WIMSE working group’s active workload-identity drafts indicate continuing work on cross-system workload authentication, but those Internet-Drafts are not final standards.
The governing rule is simple: agents may participate in authorization decisions by presenting intent and context, but reusable credentials must remain outside their durable and model-visible state. An autonomous organization becomes more controllable when authority is issued at the last responsible moment, to the specific workload that can use it, for the smallest effect the organization has approved.
