The identity question is really an authority question
An enterprise agent can authenticate perfectly and still be unsafe. The credential may prove which runtime is making a request, while saying nothing about whether that runtime may act for this person, on this case, for this purpose, at this moment.
That gap is easy to miss because conventional applications often collapse several ideas into one service account. A service identity proves that the deployed workload is the expected workload. User authentication proves that the person at the channel is who they claim to be. Neither, on its own, proves that the agent has authority to perform a particular action on the user's behalf.
Authentication establishes identity; authorization establishes permitted action; delegation establishes whose authority is being exercised. Agentic systems need all three, recorded separately.
Google Cloud's Agent Identity model makes one part of this separation explicit. An agent can receive its own SPIFFE-based, cryptographically attested identity rather than share a generic service account. That is a useful control primitive. It does not remove the need to propagate human entitlement, constrain tools or evaluate the business decision before execution.
Three principals appear in every consequential tool call
The cleanest design starts by naming three principals.
- The human principal is the customer, employee, analyst or approver whose business entitlement constrains the request.
- The agent principal is the deployed agent instance or reasoning engine making the call. Its identity constrains which services and tools the runtime may reach.
- The resource principal is the tool, API or downstream service that owns the data and action. It decides whether to honour the request.
The third principal is often described merely as a tool. That understates its role. A payments API, case system or model gateway is an enforcement point. It should reject a request that lacks the required identity and authority evidence even when the agent produces a persuasive rationale.
This creates two independent checks. The policy decision point determines whether the proposed action is allowed. The tool enforces the resulting capability against its own resource and action. A model cannot promote itself into a broader role by changing a tool argument.
Own authority and delegated authority must not blur
An agent sometimes acts under its own authority. It may read a public product catalogue, retrieve a policy available to its business unit or write operational telemetry to an approved sink. In other cases it acts for an end user: read the relationship manager's assigned clients, draft a response from the customer's case, or submit an analyst-approved disposition.
Those modes need different evidence.
| Mode | Identity presented | Authority source | Appropriate examples | Unsafe shortcut |
|---|---|---|---|---|
| Agent's own authority | Attested agent identity | IAM policy bound to the agent principal | Read approved knowledge, emit telemetry | Shared runtime identity across unrelated agents |
| On behalf of a user | Agent identity plus signed user context | User entitlement and delegated scope | Read assigned client book, prepare a case action | User identifier supplied by the model as a string |
| Dual control | Agent, user and approver identities | Business policy requiring two parties | Release payment, close high-risk alert | Treating an interface click as evidence of review |
| System-to-system delegation | Agent identity plus narrow exchanged token | Policy decision tied to source and target | Call a downstream case API for one case | Forwarding a broad bearer token through every hop |
The on-behalf-of path is the dangerous one. If a tool accepts user_id=1234 because the model supplied it, the model controls the identity boundary. The user context must instead come from a signed authentication event and remain outside the model-editable payload.
The model may propose an action. It must never mint the authority that makes the action legal.
A capability should describe the decision, not just the caller
A bearer token that says “this agent may call the case API” is too broad for a consequential workflow. The authorization decision should produce a narrow capability describing the action that has actually been approved.
A useful capability envelope contains:
- agent identity and deployed version;
- user or business principal being represented;
- case, customer or resource identifier;
- allowed operation and parameter limits;
- business purpose and policy version;
- evidence or approval reference;
- issue time, expiry and one-time-use marker where appropriate;
- correlation identifier for the complete trajectory.
The tool validates this envelope before execution. A collections agent allowed to draft a hardship-plan amendment does not thereby receive permission to activate it. An analyst's approval can mint a second, short-lived capability for activation, bound to the exact plan and amount they reviewed.
This is deterministic-first design applied to identity. Language models interpret the case and prepare a recommendation. Ordinary policy code decides whether the proposed operation fits the person's entitlement, the agent's role and the case state.
The confused deputy is the central failure mode
An agent becomes a confused deputy when it holds legitimate access but uses that access for a request that lacks legitimate authority. Prompt injection is one route. A stale entitlement, mistaken entity resolution or ambiguous user instruction can produce the same outcome without an attacker.
Consider a relationship-manager assistant whose runtime can query the whole commercial-client dataset. Application code is expected to filter results to the manager's book. A retrieved document tells the model to use a different client identifier. If the downstream query trusts that identifier, the runtime's broad access converts untrusted content into cross-client disclosure.
The repair is not a better warning in the prompt. The database query must derive the client scope from signed user entitlement, and the tool must intersect it with the requested client before any row is read. The agent identity proves which deployed agent called. The user claim limits whose data the call may touch. Row policy enforces the intersection.
Evidence a reviewer can actually use
The audit record should preserve the authorization decision, not only the eventual tool call. At minimum it needs the identities of the agent and represented user, the proposed action, the policy inputs, the policy version, the outcome and the capability identifier used at execution.
That record answers distinct review questions:
- Was this the deployed agent version approved for the journey?
- Was the user entitled to this customer and operation at that time?
- Which case facts influenced the authorization decision?
- Did a person approve the exact action or only review a summary?
- Did the tool execute within the approved parameters?
- Can the capability be revoked or shown to have expired?
An explanation generated after the event cannot substitute for this record. It may help a reviewer understand the business reasoning, but it does not prove which identity and policy checks ran.
A credit refer-back worked example
Take a credit refer-back agent that gathers missing documents, reconciles figures and drafts a proposed disposition. The gathering tools operate under the agent's own read authority, intersected with the underwriter's portfolio entitlement. The agent can write working state to the case but cannot change the authoritative lending decision.
When the agent proposes “information complete; return to automated assessment,” the policy service checks the case identifier, underwriter entitlement, mandatory-document flags, exposure threshold and policy version. Low-risk cases may receive a capability to advance to the next deterministic assessment. Higher exposures require an underwriter approval event, which mints a one-use capability bound to the proposed transition.
The design prevents four common errors. A prompt cannot change the underwriter identity. A stale portfolio assignment fails at entitlement resolution. The agent cannot use a read credential to advance the case. An approval for one transition cannot be replayed against another case.
The model remains valuable: it interprets documents, resolves ambiguity and assembles the recommendation. The authority boundary remains ordinary, testable software.
Design tests before release
The identity design is not ready because the happy path succeeds. It is ready when the boundary survives hostile and mistaken paths.
| Test | Attempt | Required result |
|---|---|---|
| User substitution | Prompt requests another user's portfolio identifier | Downstream policy ignores model-supplied identity and denies access |
| Agent substitution | Unapproved agent version reuses a valid user session | Agent-principal policy denies the call |
| Scope inflation | Tool argument asks for a broader action than the capability | Tool rejects before execution |
| Replay | Previously approved capability is used again | One-time or expired capability is rejected |
| Cross-case use | Capability for case A is attached to case B | Resource binding fails |
| Stale entitlement | User loses portfolio access mid-session | Fresh authorization check denies subsequent action |
| Missing approver | Agent presents a generated approval explanation | No signed approval event, so no execution capability is minted |
These tests belong in continuous integration and in the recurring adversarial suite. Identity policy changes should trigger them just as a model change triggers evaluation.
Platform direction and limits
Google's Agent Identity documentation is useful because it gives an agent a distinct, attested SPIFFE identity and integrates it with IAM, principal access boundaries, VPC Service Controls and audit logging. It also distinguishes an agent acting for itself from access delegated by a user. Those are the right primitives.
Product maturity still matters. Some integrations are preview features, and supported services can change. A platform team should verify availability, location, token binding, revocation and audit semantics for the exact runtime before relying on them as a control. In a multicloud estate, the logical model should remain portable even when the credential implementation differs.
SPIFFE helps at that portability boundary by defining workload identities and verifiable identity documents. NIST SP 800-207A supplies the broader zero-trust frame: policy should rely on application and service identity as well as network and user identity. Neither standard decides the business delegation model for a bank. That remains an architecture and policy responsibility.
The authority envelope is an interface contract
The capability envelope needs a formal schema, not a convention hidden in orchestration code. Its fields should divide into four groups: identity, decision scope, control state and evidence. That structure makes the contract readable by policy engines, tool adapters and auditors without asking the model to reinterpret it.
Identity fields name the attested workload, deployed agent version, represented person and approving person when one is required. Decision-scope fields name the operation, target resource, permitted parameter bounds and business purpose. Control-state fields hold the policy version, issue time, expiry, revocation status and replay protection. Evidence fields point to the case snapshot, approval event and trajectory record that supported the decision.
The case-state digest is especially useful. It binds authority to the facts that were reviewed. If the payment amount, beneficiary, customer risk flag or account status changes after approval, the digest no longer matches. The system returns for a new decision instead of stretching an old approval over new facts.
An approval should authorize an immutable proposal, not a vaguely described intention. This is the difference between “the analyst approved a refund” and “the analyst approved refund request 8f31, for account 7092, up to GBP 420, using policy version 17.” The first statement is easy to display. The second is possible to enforce.
The envelope should remain outside model-editable text. A model may populate a proposed-action object, but trusted application code resolves the represented principal and case state. The policy service then issues the signed envelope. The resource service validates the signature, audience, bounds and freshness before applying its own domain checks.
Choose delegation strength by consequence and reversibility
Not every call requires a one-time capability and dual approval. Excess control creates queues, encourages workarounds and obscures the truly consequential decisions. The useful design axes are consequence and reversibility.
| Decision class | Typical action | Delegation pattern | Freshness requirement | Execution control |
|---|---|---|---|---|
| Low consequence, reversible | Save a private draft | Agent identity plus user session | Session lifetime | Schema and ownership check |
| Low consequence, hard to reverse | Send an external message | User delegation bound to recipient and template | Minutes | Preview plus one-use send authority |
| Material, reversible | Place a temporary account restriction | User entitlement plus policy-issued capability | Current case state | Reason code and bounded duration |
| Material, hard to reverse | Release funds or close an alert | Agent, entitled user and independent approver | Immediate | Dual control, one-use capability and local recheck |
Reversibility is not the same as technical rollback. Reversing a wrongly sent vulnerability letter may be technically possible while the customer harm remains. Likewise, an account hold may be removed, yet still create a missed payment. The risk classification belongs to the business process owner, not the platform team alone.
Use the weakest delegation mechanism that still makes the consequence defensible. A read-only product lookup can rely on workload authority. A customer-record read needs the user entitlement intersected with the workload role. A financial mutation needs a proposal bound to live case state and, at the appropriate threshold, a second human decision.
This classification should appear in the tool registry. Each operation declares its consequence, reversibility, required principals, maximum capability life and replay rule. The policy engine consumes those attributes. Reviewers can then see why two operations on the same API have different controls.
Delegation is a lifecycle, not a token
The control model must cover issuance, use, expiry and revocation. Many designs spend time on issuance and assume a short expiry solves everything else. It does not. A user can lose access while a session remains active. A customer can withdraw consent. A case can enter a legal hold. An agent version can be withdrawn after an evaluation failure.
Revocation needs two paths. Emergency revocation blocks an agent version, credential family or operation immediately. Business revocation changes a user's entitlement, an approver's mandate or a case restriction. The resource should consult sufficiently current state for the action's consequence. A cached entitlement acceptable for an internal draft may be unacceptable for releasing money.
One-time use is also an application property. OAuth token exchange can narrow audience and scope, but it does not prove that a particular business operation has not already happened. A tool adapter should enforce a transaction nonce or idempotency key against its own durable record. Security-token validity and business-operation uniqueness are separate checks.
Failures should be reason-coded without leaking sensitive policy. AGENT_VERSION_DENIED, USER_NOT_ENTITLED, CASE_STATE_CHANGED, APPROVAL_MISSING, CAPABILITY_EXPIRED and REPLAY_DETECTED support operations and evaluation. They are more useful than a generic “authorization failed,” and safer than returning the complete policy expression to the model.
Put enforcement where the state is authoritative
Central policy is valuable because it applies one decision grammar across agents and tools. Local enforcement remains necessary because the resource service owns the final state. The policy service can authorize a refund up to a limit. Only the payments service knows whether the transaction has already been reversed, is under dispute or is no longer refundable.
The architecture therefore has two planes. The authority control plane manages principal registration, tool classifications, policy, approval rules, capability issuance and revocation. The execution data plane carries calls and performs the resource-local check. Both emit evidence into the same trajectory.
This split also clarifies ownership. Security engineering owns credential integrity and workload attestation. The business domain owns the action policy and risk classification. The agent platform owns proposal schemas, trajectory correlation and enforcement integration. The resource owner owns the final precondition and idempotency check. Internal audit tests the joined evidence rather than accepting any team's assertion in isolation.
Centralize the grammar of authority; keep the final veto beside the authoritative state. That principle survives cloud changes. One platform may use SPIFFE identities, another managed workload identities, and another OAuth exchange. The institution's decision object can stay stable.
Operate authority as a measured control
Production monitoring should show more than allowed and denied counts. Track denials by reason, agent version, operation and represented-principal type. Watch for sudden increases in scope inflation, stale entitlement or replay. Compare capability issuance with actual execution so unused approvals and abandoned actions are visible.
Sampling also matters. Review a set of allowed actions against the case state and policy that existed at issuance. Review a set of denied actions to detect false blocks and attempted boundary probing. Where people approve actions, inspect override rates, review times and seeded test decisions without turning those measures into productivity targets.
The evidence pack for a release should contain the principal catalogue, operation classifications, policy diff, negative-path results, one end-to-end replay and the revocation exercise. It should name the residual risk. “IAM configured” is not an assurance conclusion.
The aim is not to make every action bureaucratic. It is to make every action's authority legible. Low-risk paths should be fast because their limits are explicit. High-risk paths should be slower for named reasons. When the controls are designed around the decision, the model can change without reopening the institution's identity model.
Design approval as a transfer of authority
Human approval is often modelled as a user-interface event. A reviewer sees a summary and selects approve. The system then records the click beside whatever the agent executes later. That design proves a person interacted with a screen. It does not prove the person transferred authority for the executed action.
A defensible approval binds four objects. The reviewer identity comes from a fresh authenticated session. The proposal is immutable and includes every material parameter. The evidence view shows the sources and case facts used to form that proposal. The approval event signs the proposal digest, policy version and permitted execution window.
If the agent changes a beneficiary, amount, reason code or customer after approval, the digest changes and the authority becomes unusable. If a policy update changes the approval rule, the capability issuer can require re-evaluation. If the case state changes, the resource service can deny execution even though the approval remains authentic.
The review interface therefore belongs to the authority architecture. It should distinguish source facts from model interpretation. It should show missing or conflicting evidence. It should state the exact effect of approval. It should allow referral, correction and refusal rather than make approval the path of least resistance.
Four-eyes control needs the same precision. Independence is not created by sending the same generated summary to a second person. The second reviewer needs the relevant primary evidence, their own entitlement check and a clear statement of the first reviewer's decision. Where the policy requires independent judgement, the workflow should prevent the second decision from becoming a blind confirmation.
A human decision becomes a control only when the approved object and the executed object are provably the same. Review-time metrics can help test whether the control is alive, but they require careful interpretation. Fast approvals may indicate a simple case, an excellent interface or inattentive review. Seeded challenges, correction quality and evidence inspection provide stronger signals than speed alone.
Approval withdrawal also needs a path. A reviewer may discover an error before execution, or a customer may revoke consent. The approval service should mark the event withdrawn and propagate revocation to the enforcement tier. A narrow execution window reduces exposure but does not replace explicit withdrawal.
The operating design should handle unavailable reviewers without weakening authority. Low-risk work may wait or route to another entitled queue. Time-critical, material work may follow a documented emergency procedure with named roles and retrospective review. The agent should never reinterpret queue pressure as permission to bypass approval.
Finally, separate approval of the recommendation from approval of the action. A credit analyst may agree with the model's assessment while lacking authority to issue the offer. A compliance officer may confirm the alert rationale while operations owns closure. Recording those decisions separately prevents one broad “approved” status from collapsing distinct mandates.
This is where the three-principal model pays off. The agent supplies the proposed action. The human supplies a bounded business decision. The resource supplies the final state check. No principal can silently borrow the authority of another.
Sources
- Google Cloud, Agent Identity overview, current product model and stated preview boundaries.
- Google Cloud, Workload Identity Federation, token exchange, attribute mapping and conditions.
- SPIFFE, SPIFFE concepts and Workload API.
- IETF, RFC 8693: OAuth 2.0 Token Exchange.
- NIST, SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments, 2023.
The durable architecture is not “give every agent an identity.” It is “bind every consequential action to the agent, the represented principal, the resource, the purpose and the evidence that made the action permissible.”