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.