Keeping Provider Credentials Outside the Agent

An agent needs context to plan an action. It rarely needs the credential that performs the action.

Putting provider secrets into prompts, tool results, memory, or general-purpose agent state expands the exposure surface. The secret can appear in traces, retries, summaries, screenshots, model input, or a later tool call. Redacting logs after the fact does not repair a design in which the planning plane possessed broad execution authority.

Evidence boundary: This article is part of Independent Product R&D and documents a Target Reference Architecture. It describes intended controls, not measured performance or operational assurance.

The target property is narrower and testable: the agent works with references and authorized intent, while an isolated executor obtains only the downstream credential required for the approved action at the execution edge.

Separate four identities

“The agent identity” is not one thing. A governed transaction crosses at least four identity concerns:

1. Human principal: the person or organizational actor who supplies intent, exact approval, or bounded delegation.
2. Agent identity: the planning actor that proposes a transaction and explains its reasoning.
3. Workload identity: the isolated runtime that is permitted to execute a specific authorized action.
4. Downstream credential: the account, token, key, or payment instrument that an external provider accepts.

Each identity proves something different. Authenticating an agent does not prove user authority. Authenticating a workload does not let it choose different terms. Possessing a provider credential does not establish that a particular transaction was approved.

The SPIFFE workload identity model is useful context for this separation: it treats a workload as a software unit with its own short-lived identity rather than borrowing a human identity. The target architecture remains protocol-neutral, but the principle is broadly applicable.

Give the agent references, not secrets

The planning plane needs to know that an eligible execution method exists, which capabilities it supports, and which constraints apply. It can operate on an opaque credential reference such as “approved purchasing instrument for this tenant and category.” It does not need the underlying secret value.

References should reveal as little as possible while remaining usable for policy. They may carry non-sensitive metadata—credential class, allowed action family, tenant, status, or a display label—but they should not be convertible into provider authority by the agent itself.

When a proposal is authorized, the control plane issues a scoped execution grant. The isolated executor presents that grant and its workload identity to a credential broker. Only then does the broker resolve the approved reference into provider access for the permitted audience and action.

Credential isolation boundary

Conceptual target design. This diagram communicates intended trust boundaries and control flows; it is not a deployment topology or claim of production operation.

The boundary is a responsibility model, not a deployment map. The broker and executor might be separate processes or stronger isolation units, but public content should not infer security from a box label. The controls that matter are verifiable identity, least privilege, explicit audience, constrained lifetime, isolated handling, and fail-closed behavior.

What a scoped grant should express

A grant is not a smaller version of a broad API key. It represents the authority created by one authorization decision. Its verifier should be able to determine:

• which tenant and principal the decision belongs to;
• which workload may present it;
• which executor or destination class is the audience;
• which action and target are permitted;
• which amount, quantity, or policy constraints remain applicable;
• which transaction binding and request identity it references;
• when it becomes valid and when it expires;
• whether the underlying authorization is cancelled or no longer usable.

OAuth security best current practice recommends minimum privilege and audience restriction, and discusses sender-constrained access where feasible. Those are helpful design inputs, not proof that a particular target implementation provides them. Every claimed property still needs implementation and concurrency tests.

Short lifetime reduces exposure but does not replace scope or audience checks. A broad credential can do substantial harm during a brief window. Conversely, a narrowly scoped grant with no revocation or replay strategy can remain dangerous after the transaction has changed.

Broker policy belongs outside the model

The credential broker should make deterministic decisions from authenticated workload identity, verified grant claims, current credential status, tenant boundary, and provider audience. It should not call the model to decide whether access “seems reasonable.”

On rejection, return a minimal reason such as expired grant, audience mismatch, revoked reference, or unavailable provider access. Do not return the credential, a secret-bearing diagnostic, or a configuration dump. The agent can use the reason to request a new decision without learning protected material.

The Model Context Protocol elicitation guidance illustrates a related boundary: sensitive authentication information should use a dedicated interaction path rather than ordinary agent-visible form data. The target design generalizes that concern to transaction execution.

Standards references last reviewed: 17 September 2026.

Worked example

Consider a fictional data-purchase workflow. All names and values in this example are illustrative.

An analyst asks an agent to obtain a licensed market report within an approved research budget. The agent finds an eligible report and proposes the exact product, publisher, license class, and price ceiling. Policy approves the proposal under a bounded delegation.

The agent receives an authorization reference, not the publisher credential. An isolated purchasing workload presents its identity and the scoped grant to the broker. The broker verifies that this workload may use the tenant’s research-purchase credential for that publisher, product, price ceiling, and validity window. Access is made available only for the execution attempt. The executor sends the request and returns a filtered result containing the provider reference and receipt evidence.

If the agent changes the report edition after authorization, the broker does not “helpfully” reuse the credential. The transaction binding no longer matches, so the attempt returns for a new policy decision. If the broker cannot verify the workload identity, it denies credential access even when the proposal itself was approved.

Control the return path too

Credential isolation fails if a secret can re-enter the agent through an error message, provider echo, trace attribute, or debugging attachment. Treat output filtering as part of the boundary:

• allowlist result fields returned to the agent;
• classify and redact request and response headers before telemetry;
• exclude secret-bearing payloads from general logs;
• separate operator diagnostics from model-visible errors;
• test provider error bodies and redirects, not just successful responses;
• retain provider references and receipts without retaining reusable authority.

Observability needs deliberate correlation. Use transaction and execution identities to connect traces rather than copying credentials into logs. Audit evidence should show that a broker decision occurred and which constraints it evaluated, while access controls protect any sensitive operational detail.

Revocation, caching, and rotation

Caching can quietly weaken an otherwise careful broker. If an executor caches resolved credentials beyond the authorized operation, the effective lifetime and scope may exceed the grant. The design should define whether caching is forbidden, bound to one execution context, or invalidated by expiry and revocation signals.

Credential rotation and grant expiry are different events. Rotation changes downstream material. Expiry removes transaction authority. A broker must check both. Revoking a credential reference should stop new resolutions, while in-flight outcomes move through explicit failure or reconciliation handling.

These behaviors should be verified under clock skew, broker restart, concurrent requests, revoked references, and delayed execution. “Short-lived” is a target control, not evidence until those cases are exercised.

Failure modes

Implementation checklist

• Model human, agent, workload, and downstream credential identities separately.
• Keep reusable provider credentials out of prompts, memory, ordinary tool output, and general logs.
• Give the agent opaque references with only policy-relevant metadata.
• Bind execution grants to tenant, workload, audience, action, transaction, constraints, and expiry.
• Verify current authorization and credential status at broker access time.
• Isolate credential resolution and provider invocation from the planning plane.
• Allowlist fields returned from the provider boundary.
• Define caching, rotation, revocation, and clock-skew behavior.
• Test rejection paths and provider errors for secret leakage.
• Preserve decision evidence without storing reusable downstream authority.

The previous article, One Authorization, One Commit Boundary, explains where the scoped grant originates. Next, “Uncertain” Is a State, Not an Error covers what happens when execution returns no definitive result. See the project overview and full case study for the complete reference design. To discuss implementation access, request repository access.