Disabling an agent is not one operation. The agent may possess an SVID, an OAuth token, an established connection, a queued job, and a refresh-capable authorization context. Incident containment must address each separately.

Credential lifecycle is not a revocation chain

Token exchange does not inherently consume the input credential. It also does not guarantee that revoking the subject or actor token invalidates every token previously issued from it. Build explicit relationships if downstream invalidation is required, and test them.

Disabling future issuance differs from rejecting existing credentials. A resource server validating a self-contained token from cached public keys may not learn that XYZ was disabled until some separate policy update reaches it. Introspection can expose current authorization-server state, but cache duration and resource-server behavior still determine enforcement latency. Revocation endpoint behavior must be understood for the actual token type and deployment.

An illustrative containment timeline

Times are examples, not product guarantees. A hypothetical five-minute access token with a one-minute cache does not imply six-minute universal containment: an already-authorized long-running operation or independently created session may last longer. Measure the actual behavior.

Containment runbook

• Preserve relevant identities, token IDs, approvals, policy versions, and execution evidence; do not collect raw credentials into ordinary logs.
• Isolate the runtime and prevent replacement workloads from reacquiring the same identity.
• Deny further exchange for the affected actor and revoke appropriate approval/refresh contexts.
• Apply API-level actor or delegation denial where supported; distribute it to every enforcement point.
• Suspend queued jobs and prevent a retry path from resurrecting authority.
• Determine whether active requests, sessions, or connections require termination.
• Review completed mutations and trigger business rollback or compensating actions where needed.
• Verify containment using previously issued credentials, not only new login attempts.

Avoid issuer-wide collateral damage

Removing an entire trust bundle or issuer can disrupt every workload under that authority and may still fail to stop cached or already-authorized activity immediately. Prefer a targeted actor/delegation deny mechanism when the issuer itself is not compromised. If signing authority is compromised, broader trust removal and key replacement may be justified; that is a different incident class.

An emergency deny-list is a proposed supplemental control. Define its authenticated distribution, cache lifetime, availability behavior, administrative ownership, and effect on already-running operations. A deny-list that is unavailable must not silently disappear from policy.

Recovery criteria

Recover the underlying workload and deployment authority before re-enabling issuance. Verify that the compromise cannot satisfy selectors again, clear unauthorized approvals, restore reviewed configuration, and rotate compromised keys where relevant. A new run identifier is not a remediation boundary if the same compromised workload can obtain the same identity.

Takeaway: the practical containment window is determined by every credential and enforcement cache, not by the shortest advertised token lifetime.

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

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.

A trusted signature answers a narrow question: did an accepted signing authority authenticate this token’s contents? It does not answer whether this token type belongs at this endpoint, whether its subject is eligible for exchange, or whether the requested target should trust the resulting authority.

Build explicit token-processing contracts

Use separate input contracts for human subject evidence and agent actor evidence. For JWT inputs, establish allowed issuers, issuer-associated verification keys, algorithms, expected profile, intended audience, required claims, and temporal rules. Do not select trust using an arbitrary key URL from the submitted token. JWT security guidance stresses algorithm verification, issuer/audience validation, and mutually exclusive rules where different token kinds could otherwise be confused.

An actor JWT-SVID and a human access token may both be signed JWTs, but they are not interchangeable. A user JWT should not satisfy the agent processor because it has a sub field. A workload credential should not become a human subject merely because its signature verifies.

IdP configuration review

Review the actual subject processor, actor processor, exchange policy, access token manager, and OAuth client configuration together. Verify the installed release’s behavior and extension capabilities. This guide does not prescribe unverified administrator UI paths or claim that all task constraints are natively implemented in an access token manager.

An illustrative policy contract

accept actor evidence only from configured agents.example.org authority
map verified SPIFFE subject → current actor
require approved (client, actor, user, tenant) relationship
permit exchange only to reviewed resource identifiers
grant permissions within subject rights AND delegation constraints
require current approval for high-impact tasks
reject caller-provided actor overrides
record policy decision and output token identifier

Input audiences and output validation

An exchange can legitimately transform a credential intended for one context into authority for another. Therefore, define which input contexts the STS accepts and which output targets each exchange relationship permits. Do not accept arbitrary audiences simply because the token was issued by a trusted issuer. Do not assume an API-only token is automatically an eligible exchange credential.

Resource servers must independently validate the issued access token. If using the JWT access-token profile, RFC 9068 supplies recipient validation requirements, including token typing and audience checks. An opaque-token deployment instead depends on its agreed introspection profile. Neither approach removes application authorization.

The act claim records delegated actor attribution. may_act expresses actor eligibility, not universal permission or task approval. A submitted actor name must never override the identity obtained from verified evidence.

Review evidence

• Export effective configuration, not only screenshots of one processor.
• Demonstrate rejection of cross-profile tokens and unauthorized audience transitions.
• Test omitted, malformed, and unexpected actor claims.
• Verify scopes are granted by policy rather than echoed from requests.
• Identify which component enforces resource-level and approval-level restrictions.

Takeaway: verification, mapping, and authorization are separate operations. Each requires a testable contract.