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.

An end-to-end walkthrough reveals mistakes that component diagrams hide. Document one successful delegated request, including every credential accepted, every identity transformation, and every independent authorization decision.

The delegated request sequence

1 Lisa → human authorization flow: authenticate and approve delegation
2 XYZ → local SPIRE Workload API: obtain agent credential
3 XYZ → PingFederate STS: subject token + actor evidence + target
4 STS: validate inputs; check pairing, approval, target, permissions
5 STS → XYZ: access token for the tool service
6 XYZ → tool: present token and any required possession proof
7 Tool: validate token; authorize requested operation
8 Tool → STS/API: use an explicitly permitted downstream flow
9 API: independently validate and authorize case/4821 mutation
10 Each boundary: preserve verified attribution and outcome

The published IdP integration separates subject and actor token processing, exchange policy, and access-token-manager mapping. Treat those as distinct review points rather than assuming that one successful token validation authorizes the complete workflow.

Credential-validation matrix

A JWT-SVID identifies its subject using the SPIFFE ID and includes an audience for the intended verifier. It is not automatically an OAuth access token for every API. Acceptance at an STS requires an agreed validation and trust profile.

Trace the identities without collapsing them

{
"sub": "user:lisa",
"aud": "case-management-api",
"client_id": "agent-xyz-client",
"scope": "cases.read cases.update",
"act": {
"sub": "spiffe://agents.example.org/agent/xyz"
},
"delegation_id": "approval-81a6"
}

This is an illustrative output payload, not a complete token profile. delegation_id is an application-defined extension. The outer subject represents Lisa; act identifies the current actor. Client identity identifies the OAuth client. The authenticated transport peer may be a tool service rather than the original agent. Retain those distinctions in policy and logs. RFC 8693 provides delegation semantics; application approval is a separate deployment concern. [6]

Standalone and asynchronous alternatives

For standalone work, authorize XYZ under an agent-specific policy rather than borrowing Lisa’s authority. The API may directly accept SPIFFE authentication or accept an STS-issued token whose subject is the agent. This choice depends on the API’s supported credential profiles, not on a universal SPIFFE requirement.

If the tool receives an opaque token, use trusted introspection and check its result according to the agreed profile. Introspection is not a reason to omit audience or operation checks. Its response and any caching policy become part of the authorization boundary. [7]

For queued work, protect the job’s identity and approval context from modification, then re-evaluate authorization at execution time. A string saying user:lisa in a message is not a credential. Record both the originating agent and the executing worker; do not silently pretend that the worker is still the original transport caller.

Takeaway: each hop must know what evidence it receives, what authority it establishes, and what authority it is allowed to pass onward.

An agent can perform an operation under its own authority or perform the same operation on behalf of a person. Those are different security events.

“Agent XYZ modified this resource” identifies a machine principal. “Agent XYZ modified this resource using Lisa’s authority” identifies both an authorization subject and an acting party.

SPIFFE supplies the agent’s verifiable workload identity. OAuth token exchange can connect that identity to delegated user authority while preserving the distinction between whose permissions apply and which software exercised them. These are complementary layers, not capabilities SPIFFE automatically combines.

Start with the agent’s workload identity

For this example, Agent XYZ runs as a workload registered with SPIRE:

spiffe://agents.example.org/agent/xyz

SPIRE attests the execution environment and local workload, matches its evidence against registration policy, and delivers the appropriate SVID through the Workload API. The identity belongs to the attested workload—not to an agent name supplied in a prompt or HTTP header.

That distinction suggests an important design rule: identify the execution boundary you actually control.

If a single orchestrator process runs ten logically different agents with access to the same credentials, labeling them with ten names does not create ten independently attested security principals. Where strong separation matters, give the agents distinct workload boundaries and issuance policies; otherwise, treat their logical names and run IDs as application metadata rather than independent cryptographic identities. This follows from the Workload API’s caller-identification model.

Model one: the agent acts as itself

For autonomous work, the application authenticates Agent XYZ and authorizes the agent principal directly.

There are two common integration patterns:

• Direct SPIFFE authentication: the API accepts an X.509-SVID over mTLS, or a JWT-SVID intended for that API.
• Identity-to-token exchange: a token service validates the agent’s SPIFFE credential and issues an application access token representing the agent.

A proposed audit record for this model could look like:

{
     "event": "resource.update",
     "identity_mode": "standalone_agent",
     "effective_subject": "spiffe://agents.example.org/agent/xyz",
     "current_actor": "spiffe://agents.example.org/agent/xyz",
     "authorization_principal": "agent-xyz",
     "resource": "case/4821",
     "outcome": "success",
     "request_id": "req-7ec15",
     "agent_run_id": "run-93a2"
}

Here, no user’s authority is involved. The application should evaluate its agent-specific policy, not silently substitute the permissions of the person who originally scheduled the job.

Model two: Lisa’s authority, Agent XYZ’s actions

Now suppose Lisa asks Agent XYZ to update a resource.

The desired application semantics are:

Authorization subject: Lisa
Current actor:         Agent XYZ
Permission source:     Lisa’s rights for this application
Audit attribution:     Lisa, acting through Agent XYZ

OAuth 2.0 Token Exchange, defined in RFC 8693, provides a protocol for requesting tokens with delegation semantics. Its act claim distinguishes the acting party from the token’s subject.

“Actor token” and “actor claim” are different things

The actor_token is an input to token exchange: evidence identifying the proposed actor.

The act claim is information in the resulting token: the issuer’s assertion identifying the current actor.

In this design:

• The subject token represents Lisa.
• The actor token represents Agent XYZ.
• The issued access token retains Lisa as sub and identifies Agent XYZ in act.sub.

A JWT-SVID can serve as actor evidence if the token service explicitly supports and trusts that profile. Its subject is the agent’s SPIFFE ID, and its audience should identify the token service accepting it. A JWT-SVID is not, merely because it is a JWT, a user-delegated OAuth access token.

The exchange

The architecture is:

Lisa’s authorized delegation
+
Agent XYZ’s verified SPIFFE identity
|
v
Token service / STS
|
v
Access token: subject=Lisa, actor=XYZ
|
v
Resource application

An illustrative token-exchange request contains these form fields; client authentication is handled separately under the token service’s configured policy:

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
subject_token=<Lisa's eligible subject token>
subject_token_type=urn:ietf:params:oauth:token-type:access_token
actor_token=<Agent XYZ's JWT-SVID>
actor_token_type=urn:ietf:params:oauth:token-type:jwt
requested_token_type=urn:ietf:params:oauth:token-type:access_token
audience=case-management-api
scope=cases.read cases.update

The request asks for delegation; it does not grant it. RFC 8693 also defines may_act, which can express eligibility to become an actor, but the issuer must still apply its delegation policy.

For this implementation, require the STS to check:

• Lisa’s token is valid and eligible for this exchange.
• The agent credential is valid for the STS and maps to an approved actor.
• Agent XYZ may act for Lisa in this application.
• The requested audience and permissions are permitted.
• The resulting actor identity comes from verified evidence, never a caller-supplied display name.

These are proposed deployment requirements, not automatic behavior implied by accepting the exchange grant. They implement the issuer-side policy boundary described by RFC 8693.

The resulting access token

An illustrative decoded payload—not a complete access-token profile—is:

{
     "iss": "https://identity.example.org",
     "sub": "user:lisa",
     "aud": "case-management-api",
     "client_id": "agent-xyz-client",
     "scope": "cases.read cases.update",
     "iat": 1793325600,
     "exp": 1793325900,
     "jti": "delegated-token-4b781",
     "act": {
          "sub": "spiffe://agents.example.org/agent/xyz"
     }
}

The outer subject remains Lisa. The actor identifies Agent XYZ. client_id identifies the OAuth client and should not be assumed interchangeable with the actor identity.

Can it have all of Lisa’s rights?

Yes—as an explicit application policy, not as an inherent property of act.

For the requested model, the application can evaluate its normal user authorization rules against Lisa while retaining Agent XYZ for attribution. The token must still permit the relevant resource and operation; adding an actor claim does not manufacture permissions or bypass audience restrictions.

A useful implementation policy is:

Effective permissions =
Lisa’s current application permissions
∩ token-authorized operations
∩ delegation policy

To preserve all of Lisa’s application rights, the token and delegation policy must allow that set. For narrower automation, restrict them to the task. OAuth security guidance favors audience-restricted, least-privilege tokens rather than broadly reusable authority.

Full-rights delegation has a deliberate consequence: compromising the authorized agent can expose the same application operations Lisa could perform. Actor attribution improves investigation; it is not a privilege boundary.

Programming applications to retain the actor

Issuing the claim is only half the implementation. The application must preserve it through authentication, authorization, execution, and audit.

The following is a recommended application architecture.

1. Build a verified request identity

At the authentication boundary, validate the access token using the configured issuer, signature policy, intended audience, and temporal checks. Where the API adopts RFC 9068, apply that profile’s validation requirements rather than merely decoding a JWT.

Construct an immutable, request-scoped identity object with fields such as:

effective_subject
current_actor
prior_actors
oauth_client_id
token_issuer
token_id
authorized_scopes
authenticated_transport_peer
delegation_id

Recommended rules:

• Extract the actor only from validated token claims or trusted introspection results.
• Keep issuer-qualified user identity; a bare sub is not necessarily globally unique.
• Preserve the SPIFFE trust domain in actor identifiers.
• Reject malformed actor structures.
• Do not infer “human request” merely because act is absent.
• On delegated-only endpoints, require the expected actor information.

These are application controls designed to make the RFC’s subject/actor distinction operational.

2. Separate permission evaluation from attribution

Business logic should receive both identities, even when authorization intentionally uses only Lisa’s permissions.

For example:

Permission lookup:
subject = user:lisa

Activity attribution:
subject = user:lisa
actor   = spiffe://agents.example.org/agent/xyz

Avoid collapsing this into one username field. In the proposed implementation, authorization receives the verified subject and relevant token constraints; audit receives the complete verified identity context.

This separation preserves the purpose of the act claim: distinguishing delegated execution from acting directly as the subject.

3. Emit structured business events

A proposed event schema:

{
     "event": "case.update",
     "identity_mode": "user_delegation",
     "effective_subject": {
          "issuer": "https://identity.example.org",
          "id": "user:lisa"
     },
     "current_actor": {
          "id": "spiffe://agents.example.org/agent/xyz"
     },
     "oauth_client_id": "agent-xyz-client",
     "token_id": "delegated-token-4b781",
     "delegation_id": "delegation-81a6",
     "request_id": "req-a740",
     "agent_run_id": "run-93a2",
     "action": "case.update",
     "resource": "case/4821",
     "authorization": {
          "decision": "allow",
          "permission_source": "subject",
          "policy_version": "case-policy-17"
     },
     "outcome": "success"
}

The field names are a suggested schema, not SPIFFE or OAuth standards.

For this schema, I would require:

• Both successful operations and denied attempts carry the identity context.
• The event records the affected business object and committed outcome.
• Tokens and private keys are excluded from logs.
• Agent-supplied run IDs are marked as correlation metadata, not authentication evidence.
• Database audit columns retain both modified_by_subject and modified_by_actor.

A human-readable rendering can then say:

Lisa updated case 4821 through Agent XYZ.

The structured event retains the identifiers needed for investigation.

4. Carry the identity into background execution

Do not let request identity disappear when work moves to a queue or worker.

In the proposed architecture, enqueue a protected job context referencing the verified subject, actor, delegation, and original request. At execution time, obtain or validate authority appropriate to the worker and operation; do not treat an arbitrary queue field such as “user”: “lisa” as permission to act.

Also avoid retaining Lisa’s identity in a mutable global variable: concurrent jobs must not share authorization or audit context.

5. Preserve delegation across service boundaries

For a chain such as:

Lisa → Agent XYZ → Tool service → Resource API

RFC 8693 permits nested actor claims. The outermost actor is the current actor; nested actors represent earlier actors. Previous actors are informational and must not become an alternative source of permissions.

An illustrative claim at the resource API might be:

{
     "sub": "user:lisa",
     "act": {
          "sub": "spiffe://services.example.org/tool/case-editor",
          "act": {
               "sub": "spiffe://agents.example.org/agent/xyz"
          }
     }
}

For this design, log the current actor and retained history, and correlate each hop. Never authorize by taking the union of every actor’s permissions.

Attribution is not proof that the actor presented the token

A signed act claim says the issuer associated Agent XYZ with the delegated token. A bearer token can nevertheless be presented by whoever possesses it. Actor attribution alone does not prevent replay.

For stronger attribution, use sender-constrained access tokens where supported. RFC 8705 binds a token to an mTLS client certificate through cnf.x5t#S256; the resource server verifies that the presenting certificate matches the binding.

With rotating SPIFFE certificates, that binding is to the specific certificate, not simply its SPIFFE ID. The implementation must coordinate access-token renewal and certificate rotation. TLS termination must also preserve a trustworthy validation boundary; an untrusted forwarded certificate header is not equivalent to an authenticated peer. These follow from RFC 8705’s certificate-binding mechanism.

The takeaway

For agent identity, keep three questions separate:

1. Which workload is this? SPIFFE provides the verifiable identity.
2. Whose authority is being exercised? Delegated tokens preserve the user as subject.
3. Which software exercised that authority? The actor claim preserves attribution.

Then make the application record all three at the business-event boundary.

The goal is not merely an access token containing Agent XYZ’s name. It is an authorization and audit model that can reliably distinguish Lisa acting directly, Agent XYZ acting independently, and Agent XYZ exercising Lisa’s delegated authority.