How it works
Credential mediation puts a narrow service between the agent and the credential. The agent does not receive the raw secret. It requests an operation, the mediator checks policy, and the mediator either performs the operation itself or returns a short-lived capability that is constrained to that operation.
A typical flow is simple:
- The harness receives a proposed tool call or workflow step.
- The mediator maps that request to an allowed identity, account, resource, and action.
- Policy checks run against the current run state, approval status, environment, and risk class.
- The mediator injects the credential only into the trusted execution boundary, or exchanges it for a scoped token.
- The call is logged with attribution to the run, step, operator policy, and target service.
- Expiry, revocation, and rotation happen outside the agent's memory and transcript.
The important mechanism is separation. The model can reason about the need to call a payment API, publish to a CMS, query analytics, or open a browser profile. It does not need possession of the underlying secret. The harness holds that authority in a smaller, auditable component with deterministic rules.
Credential mediation can be implemented as a broker, proxy, gateway, signing service, or tool wrapper. The shape matters less than the boundary: secrets should move through infrastructure designed for secrets, not through natural-language context or unconstrained agent state.
Why it matters in an agent harness
Agent systems create a different credential risk than ordinary scripts. A script has a known control path. An agent has an execution trajectory. It may inspect files, call tools, summarize context, retry after errors, delegate to subagents, and incorporate external text. That makes raw credential exposure unusually expensive.
The first benefit is blast-radius control. If a run only needs read access to one repository, the mediated credential should not also be able to delete cloud resources, send email, or modify billing. The agent's capability should match the current task, not the operator's total authority.
The second benefit is observability. A mediated credential gives the harness a place to record who or what used authority, for which run, under which policy, and with what result. Without that layer, a downstream service may only see a generic API key. That is not enough when reconstructing an incident or deciding whether an action can be replayed.
The third benefit is reversibility. Some actions can be rolled back. Others can only be compensated. Credential mediation lets the harness require stronger checks before irreversible actions: publishing, spending, deleting, changing DNS, inviting users, or sending messages. The credential path becomes part of the control plane, not a hidden implementation detail.
The fourth benefit is prompt-injection containment. External content can ask the model to reveal secrets, alter destinations, or call tools with attacker-chosen parameters. If raw credentials are never in context, the model has less sensitive material to leak. If the mediator checks destinations and scopes independently, an injected instruction has to defeat a deterministic boundary rather than merely persuade a model.
This is also an operating discipline. Credential mediation forces teams to name the authority a workload actually needs. That naming work is tedious, but it is the difference between a bounded agent and a process with inherited administrator power.
Credential mediation vs token passthrough
| Concept | What receives authority | Main design consequence |
|---|---|---|
| Credential mediation | A trusted broker, proxy, or wrapper grants scoped authority per operation | The harness can enforce policy, attribution, expiry, and revocation before the secret reaches execution. |
| Token passthrough | The agent, worker, or tool receives an existing credential from the caller | The system is simpler, but the caller's authority can leak into places that were not designed to hold it. |
Token passthrough is not always wrong. It can be acceptable inside a narrow internal job where the execution path is deterministic, logs are strong, and the token is already scoped. In agentic systems, though, passthrough often becomes accidental delegation. The model is treated as if it only needs to decide what to do, while the runtime quietly hands it broad authority to do much more.
Credential mediation changes the default question. Instead of asking, "Can this agent have the user's token?" the harness asks, "What specific authority is justified for this step, and where should that authority terminate?" That shift usually leads to smaller credentials, clearer approvals, and fewer impossible incident reviews.
The Rifty take
We optimize for explicit authority over convenient authority. A harness should make the credential boundary visible enough that an operator can inspect it before something expensive happens and reconstruct it after something surprising happens.
The tradeoff is more policy surface. Mediation adds components, logs, expiry rules, and failure cases. We accept that cost when the alternative is placing long-lived secrets inside a stochastic work loop and hoping every future prompt, tool, memory, and retry behaves cleanly.
Implementation checks
- Raw secrets do not appear in model prompts, memory, traces, error messages, or tool result payloads.
- Every mediated credential has a scope, expiry, target service, allowed operation, and run identifier.
- The mediator fails closed when policy, state, identity, or approval data is missing.
- High-impact actions require stronger policy than low-impact reads, even when they use the same external account.
- Logs distinguish proposed action, approved authority, executed call, result, and any compensating action.
- Rotation and revocation can happen without editing prompts, rebuilding agents, or clearing model memory.
- Subagents receive only the authority needed for their assigned work, not the parent run's full credential set.
- Tests cover denied access, expired credentials, wrong destination, replayed requests, and injected tool arguments.
Frequently asked questions
Is credential mediation just secret management?
Credential mediation uses secret-management ideas, but the control point is different. Secret management stores and rotates sensitive values. Mediation governs how an agentic run receives usable authority for a specific action. In a harness, the policy decision, attribution, and runtime boundary matter as much as the stored secret.
When is token passthrough acceptable?
Token passthrough is acceptable when the token is already narrow, short-lived, and used inside a deterministic path with strong logging. It is risky when a broad user or service token is handed to an agent loop that can inspect untrusted content, retry, delegate, or call tools in changing sequences.
What should a credential mediator log?
A mediator should log the run, step, requested action, granted scope, target resource, policy decision, approval reference when relevant, execution result, and expiry. It should not log the raw secret. The goal is enough evidence to audit authority without creating another credential leak.
Does credential mediation prevent prompt injection?
Credential mediation does not eliminate prompt injection, but it reduces what an injection can obtain or misuse. The model cannot reveal secrets it never sees, and the mediator can reject calls that violate destination, scope, approval, or state rules. It is a containment boundary, not a complete defense.
How strict should credential scopes be?
Scopes should be as narrow as the operation permits, with stricter controls for irreversible or externally visible actions. Read-only analytics access and publishing access should not share the same authority. If the harness cannot explain why a run needs a credential, the credential is probably too broad.