---
summary: Use OAuth token exchange to let SigID agents act for users or organizations with reduced scoped delegated access.
tags:
  - agents
  - delegation
  - token exchange
  - oauth
  - scopes
categories:
  - AI Agents
---

# Delegation & Token Exchange

<!-- agent:page
You are a coding agent implementing SigID delegation and OAuth token exchange for agents by following this reference.
First collect: grantor subject, grantee agent, tenant, exact token audience, requested scopes, expiry, optional spending caps, approval requirements, and whether this is a root delegation or sub-delegation.
Create tenant-scoped delegation records only when every requested scope is covered by the grantor and marked delegatable for the audience; keep audiences exact through the chain and make sub-delegation scopes, caps, and depth strictly narrower.
Exchange tokens with RFC 8693 using the user's subject_token and the agent's actor_token, then validate the issued token by signature, issuer, audience, tenant, expiry, reduced scope, subject, and act actor context.
Do not grant broad scopes for convenience, do not let callers provide delegation IDs in resource requests, and verify revocation cascades through descendant delegations, token-exchange sessions, and vault grants where configured.
-->

Delegation allows an agent to act on behalf of a user or organization with
reduced permissions. This is done through OAuth 2.0 Token Exchange (RFC 8693).

## When to Use Delegation

Use delegation when:

- An agent needs to perform actions for a user
- The agent should have limited, time-bound access
- You need audit trails showing both the user and agent
- You want the ability to revoke agent access independently

## Token Exchange Flow

1. User authenticates and receives an access token
2. Agent authenticates and receives its own access token
3. Agent exchanges both tokens for a delegated token
4. Agent uses delegated token to act on user's behalf

## Request Format

```bash
curl -sS "$SIGID_AUTH_ORIGIN/oauth/token" \
  -u "$SIGID_CLIENT_ID:$SIGID_CLIENT_SECRET" \
  -H "content-type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
  --data-urlencode "subject_token=$USER_ACCESS_TOKEN" \
  --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \
  --data-urlencode "actor_token=$AGENT_ACCESS_TOKEN" \
  --data-urlencode "actor_token_type=urn:ietf:params:oauth:token-type:access_token" \
  --data-urlencode "requested_token_type=urn:ietf:params:oauth:token-type:access_token" \
  --data-urlencode "audience=https://api.example.com" \
  --data-urlencode "scope=limited:scope"
```

## Delegated Token Design

| Field | Rule |
|---|---|
| Audience | Exact API or MCP server |
| Scope | Narrow tool or resource action |
| Subject | User or organization being represented |
| Actor | Agent identity |
| Expiry | Task-bound and short-lived |
| Approval | Required for sensitive or irreversible actions |

## Response

The delegated token contains:

```json
{
  "access_token": "...",
  "token_type": "Bearer",
  "expires_in": 300,
  "scope": "limited:scope"
}
```

The access token includes:

- `sub`: The user or organization being represented
- `act`: The agent identity (actor)
- `aud`: The intended audience
- `scope`: The reduced scope

## Validation

Resource servers should:

1. Verify the token signature and expiry
2. Check that `sub` represents the user/org
3. Check that `act` represents a valid agent
4. Verify `scope` is appropriately narrow
5. Enforce resource-level tenant checks

## Revocation

Delegated tokens can be revoked:

- By revoking the agent's credentials
- By revoking the original user token
- By administrative action

## See Also

- [Agent Authentication](agent-auth.md) - Agent auth methods
- [Verify Tokens](../developers/verify-tokens.md) - Validating delegated tokens