An authenticated agent can still be manipulated. Identity controls must work even when the workload holds valid credentials and makes a harmful request. The useful threat model is therefore not only an outsider forging XYZ’s token; it is XYZ itself attempting an operation Lisa did not approve.

A worked prompt-injection scenario

Lisa asks XYZ to resolve case 4821. XYZ retrieves a document containing instructions to export customer records and send them to another service. The agent’s runtime, SPIFFE identity, and signing authority are unchanged. If its delegated token permits broad exports, authentication can succeed throughout the attack. The failure is excessive or insufficiently enforced authority, not a broken signature.

There are three independent constraints to examine: the target application, the operation within that application, and the specific object or mutation. An audience restriction can prevent use at payroll while doing nothing to stop a broad export at the authorized case API. A write scope may permit more than Lisa’s intended single-field update.

Task authorization outside the agent’s assertions

Recommended pattern: a trusted authorization interaction records Lisa’s approval, the authorized agent, target, resource, permitted actions, field-level constraints, expiration, and any use count. At exchange, consult that record rather than accepting an agent-supplied statement that Lisa approved. At execution, compare the actual request with the approved constraints. Approval must not be editable through the same untrusted content channel that proposes tool actions.

{
    "authorization_details": [
    {
        "type": "case_operation",
        "actions": [
             "update"
        ],
        "case_ids": [
            "4821"
        ],
        "allowed_fields": [
            "status"
        ],
        "allowed_status_values": [
            "resolved"
        ]
    }
  ]
}

The array structure illustrates RFC 9396 authorization_details. The case_operation type and its fields are custom; issuer and API must agree on semantics. Rich Authorization Requests do not automatically make these constraints native to RFC 8693 exchange or to every IdP release. A protected approval identifier plus server-side enforcement may be more practical than embedding all constraints.

Threats, controls, and residual risk

Threat	Recommended control	Residual risk
Injected tool instructions	Independent task/resource authorization	Allowed actions can still be abused within their bounds
Requested target substitution	STS audience-transition allowlist	Approved target might itself be overprivileged
Confused deputy tool	Bind delegated context to actual operation	Tool implementation bugs
Stolen bearer credential	Supported sender-constrained token	Key theft or compromised authorized runtime
Agent manufactures approval	Approval issued outside agent authority	Approval-service compromise or deceptive consent UI
Repeated approved mutation	Atomic use-count enforcement	Retry and transaction semantics require design

 

What possession proofs do not prove

Sender constraint makes token use depend on a presenting key. It does not prove that Lisa requested the operation or that the key holder has safe reasoning. DPoP binds proofs to HTTP method and URI and, for protected-resource calls, the token; it does not generally bind the business request body. Application authorization must validate the actual mutation independently.

Full-rights delegation is a conscious risk decision. If XYZ can exercise every operation Lisa can exercise in the application, a surprising request may still be authorized by policy. Neither an actor claim nor additional authentication can recover a narrower intention never represented in the grant.

Engineering acceptance questions

• Can injected content change approval records, audiences, or requested scopes?
• Does the API validate the actual object and body rather than only token claims?
• Which destructive actions require fresh approval or step-up?
• Are tool-provided identifiers canonicalized before policy comparison?
• Can an authorized agent repeatedly execute a nominally one-time task?

Takeaway: workload identity authenticates the execution boundary. Task authorization constrains what that boundary may do.