ZharfAI Team
An accounts-payable agent is asked to retrieve one approved purchase order, compare it with an invoice, and place the matched invoice in an enterprise resource planning queue. The quick integration copies an ERP service-account key into the agent runtime. That key can read every purchase order, write to several queues, and remain valid for months. It may appear in a tool trace, a crash dump, a copied prompt, or a subprocess the agent starts. Even if the model performs the intended task, the credential has already crossed the wrong boundary.
The reader decision is narrower and more useful than “how should we secure an AI agent?” It is: should this agent receive a credential at all, and if it must, how do we bind that credential to the workload, human or service subject, task, tenant, audience, action, and time window? For high-consequence operations, the best answer is often that a trusted broker should perform the action while the agent receives only the result.
Three concepts are often collapsed into “the agent's API key”:
The distinction matters because one identity can receive different authority for different tasks, and one task can require credentials for several audiences. A token accepted by the document store should not work at the payments API. A user may be allowed to approve invoices but not to grant the agent a reusable approval identity. The design should preserve this chain rather than flattening agent, user, and service into one account.
This extends the agent passport: resolve the subject and task first, then issue the smallest proof required for one downstream effect. It also complements tool permission design, where the model proposes an action but a deterministic layer decides whether the action exists, which arguments are valid, and whether confirmation is required.
Start every integration review with three patterns, ordered by how much reusable authority enters the agent boundary:
| Pattern | What the agent receives | Suitable use | Main risk |
|---|---|---|---|
| Broker-executed action | A capability handle or structured result; no resource credential | Payments, deletion, privileged administration, regulated records, irreversible writes | Broker becomes a critical policy and availability dependency |
| Exchanged short-lived credential | Audience-bound token with narrow scope and expiry | High-volume reads or bounded reversible writes where direct access is operationally useful | Token can still be replayed within its authority unless sender-constrained |
| Static or long-lived credential | General API key, password, private key, or refresh token | Legacy systems only, behind a compensating proxy and migration deadline | Broad blast radius, weak attribution, rotation burden, and leakage persistence |
“No credential” does not mean “no access.” The agent submits a typed request such as read_purchase_order(tenant, po_id) to a broker. The broker authenticates the workload, validates the task envelope, checks policy and freshness, invokes the resource under its own controlled identity, filters the response, and returns a bounded result. The resource secret never enters model context, tool arguments, extension processes, or general agent memory.
ZharfAI's analysis is that broker execution should be the default when a worst-case valid call is materially worse than an extra network hop. Issue a temporary credential only when the resource enforces the same narrow audience, subject, resource, action, tenant, and expiry, and direct access has a real operational benefit.
A broker must not accept “I am the purchasing agent” from a prompt or request body. It needs a verifiable workload identity rooted in the execution platform. NIST SP 800-207A, published in September 2023, describes cloud-native zero trust around application and service identities, with enforcement through components such as API gateways, sidecars, and identity infrastructure rather than network location alone.
SPIFFE's workload-identity model provides a useful concrete mechanism: a workload can obtain short-lived, automatically rotated X.509 or JWT identity documents without being provisioned with a co-deployed authentication secret. The document proves workload identity; it does not by itself grant every application permission. SPIFFE also cautions that JWT identity documents are bearer tokens and can be replayed until expiry, whereas X.509 identities require proof of the private key in a mutual TLS exchange.
On Kubernetes, the preferred primitive is a projected, rotating service-account token requested for a specific audience, not a manually created long-lived token Secret. The Kubernetes service-account guidance explicitly recommends the TokenRequest API or projected token volume and notes that long-lived Secret-based tokens are not recommended.
The resulting trust path is:
Network position may add a signal, but it is not identity. A process on the right subnet with a copied token is still the wrong workload.
OAuth 2.0 Token Exchange, RFC 8693, standardized in January 2020, defines a security token service interaction in which one token is exchanged for another. Its subject and actor concepts can represent the distinction between the party on whose behalf work occurs and the party acting. It also distinguishes impersonation—where the actor is indistinguishable from the subject—from delegation, where the actor remains identifiable.
That distinction is especially important for agents. A downstream audit should be able to say “procurement agent build 7 acted for employee 42 under task 913,” not merely “employee 42 called the ERP.” If the downstream protocol cannot carry both subject and actor, keep the missing relationship in an integrity-protected exchange record linked by a non-secret identifier. Do not invent a claim that the target does not validate.
OAuth 2.0 Security Best Current Practice, RFC 9700, published in January 2025, recommends audience-restricted and sender-constrained access tokens to reduce misuse of leaked tokens. It also reinforces minimum-privilege scope and protections for refresh tokens, including rotation or sender constraint for public clients. The operational translation is simple:
Temporary credentials are established in major cloud control planes. AWS STS temporary credentials are generated dynamically, expire, and avoid embedding long-term credentials. Google Cloud workload identity federation guidance describes exchanging external workload credentials for short-lived access, recommends dedicated identities over broad pool grants, and advises regional token endpoints where available. These are building blocks, not proof that an agent policy is correct.
For user OAuth, keep consent, current resource authorization, and permission for this task separate. Store refresh tokens in a dedicated credential service; give the agent an opaque connector handle. At invocation, the broker rechecks user status, tenant, requested scope, and step-up approval, then refreshes or exchanges access. Where provider scopes are coarse, a connector proxy must narrow methods, fields, resource IDs, rate, and response data.
The broker needs an immutable request that is richer than an OAuth scope string. A practical envelope can include:
| Field | Required property |
|---|---|
workload_id, deployment_digest | Attested runtime and approved software version |
subject_id, actor_id, delegation_id | Human or service subject, agent actor, and delegation chain |
tenant_id, membership_version | Security domain and freshness of membership |
task_id, purpose, expires_at | Bounded job, legitimate purpose, and hard deadline |
audience, actions, resource_handles | Exact receiver, verbs, and server-resolved objects |
confirmation_receipt | Human approval for the exact consequential action, when required |
policy_version, risk_tier | Decision logic used and applicable control tier |
nonce, parent_trace_id | Replay resistance and evidence linkage |
The model may fill a proposal, but it must not sign, widen, or choose the trusted fields. Resolve resource handles server-side: “invoice 811” should become the database object's immutable identifier after tenant-scoped lookup, not a model-supplied path. Every downstream exchange may narrow the envelope; none may extend its expiry, add an action, change tenant, or substitute a resource.
This is also where tenant isolation becomes non-negotiable. A token scoped to invoice:write but accepted across all customers is not narrow. Tenant identity must be derived from trusted membership state, bound into the policy decision, and enforced again at the resource—not accepted as a tool argument.
Consider the original accounts-payable task. Employee U-42 may submit invoices for tenant T-8 but may not release payment. The approved workflow is to read purchase order PO-91, compare it with invoice INV-811, and place a match record in a review queue.
ap-agent@prod, hashes the approved tool plan, and creates task TASK-913 with a five-minute deadline.PO-91 and INV-811 inside T-8, confirms that U-42 still has the submitter role, and records policy version 31.po:read limited to the resolved record. The token cannot call the queue or another tenant.review_queue:create using idempotency key TASK-913:match. The agent receives a receipt, not a queue credential.Prompt injection in the invoice cannot list other vendors because the read token is bounded to one audience and record. If the token leaks, 45 seconds is not the only defense: audience, resource, action, tenant, and preferably sender constraint limit replay. If U-42 loses the role mid-task, a changed membership version makes the broker deny the write even though the earlier read was legitimate.
Credential brokering fails if the happy path is narrow but recovery silently becomes broad. Test these cases:
Use idempotency at the effect target. Bind confirmation to the normalized request hash and expire it. On policy or membership change, stop issuance and revoke authority whose remaining lifetime exceeds the accepted exposure window. Fail closed on missing audience, task, tenant, or policy. A shared-service-account fallback converts an outage into an invisible security incident.
A dashboard showing that “100% of secrets are in a vault” does not reveal what agents can do. Measure the authority actually issued and exercised:
| Measure | Useful question |
|---|---|
| Static credentials reachable by agent runtimes | How much durable authority can still leak? |
| Token lifetime distribution by risk tier | Is access shorter than the task and response window? |
| Audience and resource-binding coverage | Can a captured token work elsewhere? |
| Broker-executed share of high-risk actions | How often does dangerous authority avoid the agent boundary? |
| Issued-to-used authority ratio | Are scopes and resource sets broader than observed need? |
| Denials after membership or policy change | Does freshness enforcement catch stale work? |
| Replay and idempotency conflicts | Are duplicate task paths reaching real effects? |
| Credential material in logs and traces | Are observability paths becoming secret stores? |
Do not log tokens. Record a protected fingerprint, audience, actions, subject, actor, tenant, task, issuance and expiry, policy version, decision, effect receipt, and denial reason. Protect this evidence; a trail containing usable credentials is another breach path.
The audit evidence guide offers the right standard: preserve the decision inputs and effect receipts needed to substantiate a control, not just a configuration screenshot or the agent's narrative of what it did.
Before enabling an agent connector, verify:
Revisit the decision when a connector adds a write method, a provider changes scopes, token exchange or proof-of-possession becomes available, task duration grows, the agent can run code or install extensions, a new tenant class arrives, or the consequence of a valid action changes. Review it after every credential exposure, replay, stale-membership denial, broker bypass, or unexplained difference between issued and used authority.
The durable principle is not “rotate secrets faster.” It is to stop treating a credential as the agent's property. Authority is borrowed for a named task, narrowed at every hop, and either exercised by a broker or represented by a short-lived proof that only the intended resource can accept. When the task ends, nothing reusable should remain inside the agent boundary.
A field guide to deciding what may be pooled, what must be siloed, and how to keep retrieval, memory, caches, tools, logs, and evaluations inside the right customer boundary.
Read More
A field guide to choosing serialization, version checks, transactions, leases, and fencing tokens when several AI workers can touch the same state.
Read More
A practical guide to Grok Bot's shared computer, role charters, routines, multi-agent handoffs, pricing, evidence, and safety boundaries.
Read MoreIf this note maps to a real system in your organization, start with the services page or a shipped case study.