Transaction Tokens For Agents

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 13 October 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Traditional zero trust authorization systems face new challenges when applied to AI agent workloads. Unlike conventional web services, AI agents possess capabilities for autonomous operation, behavioral adaptation, and dynamic integration with various data sources. These characteristics may lead to decisions that extend beyond their initial operational boundaries.¶

Existing zero trust models, which effectively manage permissions and access scopes for traditional web services, require enhancement to address the unique properties of AI agents. Authorization systems must evaluate each AI agent interaction independently, considering both the immediate context and intended action. This necessitates more sophisticated approaches to policy enforcement, behavioral monitoring, and audit tracking to maintain security governance.¶

Transaction Tokens (Txn-Tokens) are short-lived, signed JSON Web Tokens RFC7519 that convey identity and authorization context. However, the current Txn-Token format lacks sufficient context for services within the call chain to implement fine-grained access control policies for agent-based workflows. Specifically, it does not provide adequate information about the AI agent's identity or its initiating entity, limiting transaction traceability. With this extension, Transaction Tokens will carry agent identity information which will help in better traceability for AI Agent's actions deep down the web service graph connecting multiple web services involved in completing a transaction in distributed systems.¶

This document defines three new contexts within the Transaction Token to address these limitations:¶

1. The act claim, which identifies the AI agent performing the action, aligning with OAuth 2.0 Token Exchange RFC8693 terminology for actor tokens¶

2. The sub claim, as defined in OAUTH-TXN-TOKENS, which represents the principal on whose behalf the transaction is being performed. The population of this field follows the rules specified in the base Transaction Tokens specification, based on the 'subject_token' provided in the token request.¶

3. An optional agentic_ctx claim. The value of this claim, if present, MUST be a JSON object. The agentic_ctx claim conveys attributes about the agent and its operational constraints that are relevant to authorization, auditing, and policy evaluation.¶

This extension leverages the existing Txn-Token infrastructure to enable secure propagation of AI agent context throughout the service graph.¶

2. Terminology

Agentic-AI: AI Agentic applications are software applications that utilize Large Language Models (LLM)s and plans, reasons,and takes actions independently to achieve complex, multi-step goals with minimal human oversight.¶

Workload: An independent computational unit that can autonomously receive and process invocations, and can generate invocations of other workloads. Examples of workloads include containerized microservices, monolithic services and infrastructure services such as managed databases.¶

Trust Domain: A collection of systems, applications, or workloads that share a common security policy. In practice this may include a virtually or physically separated network, which contains two or more workloads. The workloads within a Trust Domain may be invoked only through published interfaces.¶

Call Chain: A sequence of synchronous invocations that results from the invocation of an external endpoint.¶

External Endpoint: A published interface to a Trust Domain that results in the invocation of a workload within the Trust Domain. This is the first service in the call chain where request starts.¶

Transaction Token (Txn-Token): A signed JWT with a short lifetime, providing immutable information about the user or workload, certain parameters of the call, and specific contextual attributes of the call. The Txn-Token is used to authorize subsequent calls in the call chain.¶

Transaction Token Service (Txn-Token Service): A special service within the Trust Domain that issues Txn-Tokens to requesting workloads. Each Trust Domain using Txn-Tokens MUST have exactly one logical Txn-Token Service.¶

3. Protocol overview

Principal    Agent App    External    Authorization   Txn-Token
                         Endpoint        Server        Service
   |            |           |              |             |
   | Invoke     |           |              |             |
   | agent task |           |              |             |
   |----------->|           |              |             |
   |            |           |              |             |
   |            | Call external API        |             |
   |            |---------->|              |             |
   |            |           |              |             |
   |            |   OAuth Challenge        |             |
   |            |<----------|              |             |
   |            |           |              |             |
   |            | Initiate Auth Code Flow  |             |
   |            |------------------------->|             |
   |            |           |              |             |
   |            | Auth Code                |             |
   |            |<-------------------------|             |
   |            |           |              |             |
   |            | Exchange code for token  |             |
   |            |------------------------->|             |
   |            |           |              |             |
   |            | Access Token (AT1)       |             |
   |            | w/ sub, clientId claims  |             |
   |            |<-------------------------|             |
   |            |           |              |             |
   |            | Call with AT1            |             |
   |            |---------->|              |             |
   |            |           |              |             |
   |            |           | Request Txn-Token          |
   |            |           | with AT1, Subject token    |
   |            |           | as param     |             |
   |            |           |--------------------------->|
   |            |           |              |             |
   |            |           |              |    Validate AT1
   |            |           |              |    Extract claims
   |            |           |              |    Set sub from Subject token
   |            |           |              |    Set act from AT1.clientId
   |            |           |              |             |
   |            |           |              |             |
   |            |           |              |             |
   |            |           |              |             |
   |            |           | Txn-Token    |             |
   |            |           |<---------------------------|
   |            |           |              |             |

Legend:
----> : Request flow
<---- : Response flow
  |   : Component boundary

Agent App    External    Authorization   Txn-Token
            Endpoint        Server        Service
    |           |              |             |
    | Self-     |              |             |
    | triggered |              |             |
    | event     |              |             |
    |--+        |              |             |
    |  |        |              |             |
    |<-+        |              |             |
    |           |              |             |
    | Call external API        |             |
    |---------->|              |             |
    |           |              |             |
    |   OAuth Challenge        |             |
    |<----------|              |             |
    |           |              |             |
    | Client Credentials Grant |             |
    |------------------------->|             |
    |           |              |             |
    | Access Token (AT1)       |             |
    |  sub, aud claims         |             |
    |<-------------------------|             |
    |           |              |             |
    | Call with AT1            |             |
    |---------->|              |             |
    |           |              |             |
    |           | Request Txn-Token          |
    |           | with AT1, Subject token    |
    |           | as param     |             |
    |           |--------------------------->|
    |           |              |             |
    |           |              |    Validate AT1
    |           |              |    Extract claims
    |           |              |    Set sub from aud
    |           |              |    Set act.sub from clientId or sub
    |           |              |             |
    |           |              |             |
    |           |              |             |
    |           | Txn-Token    |             |
    |           |<---------------------------|
    |           |              |             |

Legend:
----> : Request flow
<---- : Response flow
  |   : Component boundary
  +   : Internal process
--+   : Self-triggered event

Notes:
* AT1: Access token obtained via Client Credentials Grant
* External Endpoint uses subject token for authenticating itself to Txn-Token Service
* AT1 is included as parameter in Txn-Token request
* Self-triggered events can be scheduled tasks or external triggers
* Token validation includes signature and claims verification

{
  "txn": "c2dc3992-2d65-483a-93b5-2dd9f02c276e",
  "sub": "user:alice@example.com", // if its human initiated
  "aud": "https://trading.trust-domain.example/stocks",
  "iss": "https://txn-svc.trust-domain.example",
  "iat": 1697059200,
  "exp": 1697059500,
  "purp": "trade.stocks",
  "tctx": {
    "action": "BUY",
    "ticker": "MSFT",
    "quantity": "100"
  },
  "req_wl": "apigateway.trust-domain.example", // API gateway requests Txn-token
  "act": {
     "sub":"agent-identity-1" // 3P agent hitting API gateway owned by trust domain
  }
}

"agentic_ctx": {
  "agent_type": "planner+tool-orchestrator", // A string describing the functional role of the agent (for example, “planner”, “tool-orchestrator”, “data-assistant”, “code-execution-agent”). The semantics and allowed values are deployment-specific.
  "agent_version": "3.4.2", // A string indicating a version or configuration identifier for the agent. This value can be used to associate the transaction with a particular, reviewed agent policy or release
  "intent": "enumerate and validate production search services before Q4 traffic spike", // A string describing the high-level purpose of the transaction from the agent’s perspective (for example, “trade.stocks”, “enumerate.search.services”, “generate.billing.report”). This value is intended to support coarse-grained, intent-aware authorization policies.
  "allowed_actions": ["read"],
  "environment_constraints": { "environment": "prod", "region": "us" },
}

"agentic_ctx": {
    "agent_type": "tool-orchestrator",
    "intent": "validate search services",
    "authorization_details": [
      {
        "type": "search_service_access",
        "actions": ["read", "list"],
        "locations": ["https://api.search.example/v1"]
      }
    ],
    "environment_constraints": {
      "environment": "prod",
      "region": "us"
    }
}

4. Multi-agent flows

In complex agentic workflows, a primary agent (the "Delegator") may delegate sub-tasks to one or more secondary agents ("Delegatees"). This document defines a mechanism to preserve the delegation lineage across these transitions. Note that preserving lineage is optional.¶

{
  "txn": "c2dc3992-2d65-483a-93b5-2dd9f02c276e",
  "sub": "user-77",
  "iss": "https://txn-svc.trust-domain.example",
  "iat": 1712850000,
  "exp": 1712850300,
  "act": {
    "sub": "search-agent-v2",
    "deployment": "prod-us-west-1"
  },
  "actchain": [
    {
      "sub": "researcher-agent-v1",
      "iat": 1712849950
    }
  ],
  "purp": "web.search.execute",
  "agentic_ctx": {
    "agent_type": "tool-orchestrator",
    "intent": "validate search services",
    "allowed_actions": ["read"],
    "environment_constraints": {
      "environment": "prod",
      "region": "us"
    }
  }
}

5. Security Considerations

1. All the security considerations mentioned in OAUTH-TXN-TOKENS apply.¶

2. Token Replay Protection Implementations MUST enforce strict token lifetime validation. The short-lived nature of Transaction Tokens helps mitigate replay attacks, but implementations SHOULD also consider:¶

   • Implementing token tracking mechanisms within trust domains¶

   • Validating token usage context¶

3. Actor Identity Security¶

   • Implementations MUST validate act claims in tokens¶

   • The Txn-Token Service MUST verify the authenticity of actor context before token issuance¶

   • During replacement flow, Txn-Token Service MUST NOT modify the act field in the incoming Txn-Token¶

4. Principal Context Protection¶

   • Systems MUST prevent unauthorized modifications to the sub claim during token propagation. Txn-Tokens are cryptographically signed to ensure integrity.¶

   • During replacement flow, Txn-Token Service MUST NOT modify the sub claim in the incoming Txn-Token¶

   • The Txn-Token Service MUST follow the subject population rules defined in OAUTH-TXN-TOKENS to ensure proper principal representation¶

5. Transaction Chain Integrity¶

   • Implementations MUST maintain cryptographic integrity of the token chain¶

   • Services MUST validate tokens at trust domain boundaries¶

   • Systems MUST implement protection against token tampering during service-to-service communication¶

6. AI Agent Specific Controls¶

   • Implementations MUST enforce scope boundaries for AI agent operations¶

   • Systems SHOULD implement behavioral monitoring for AI agent activities by logging act and sub claims in audit logs¶

   • Systems MUST maintain audit trails of AI agent activities¶

7. Token Transformation Security¶

   • The Txn-Token Service MUST validate all claims during access token to Txn-Token conversion¶

   • Implementations MUST verify signatures and formats of all tokens¶

   • Systems MUST prevent unauthorized manipulation during token transformation¶

   • The Txn-Token Service MUST ensure that the act field accurately represents the agent identity from the access token¶

8. Replacement Token Considerations¶

   • Systems MUST verify the authenticity and validity of original tokens before replacement¶

   • Systems MUST implement controls to prevent unauthorized replacement requests¶

   • The immutability of act and sub claims during replacement ensures consistent identity context throughout the transaction lifecycle¶

9. Infrastructure Security¶

   • All component communications MUST use secure channels¶

   • Implementations MUST enforce strong authentication of the Authorization Server¶

   • Systems MUST implement regular rotation of cryptographic keys¶

   • Trust domain boundaries MUST be clearly defined and enforced¶

10. Multi-Agent Considerations:¶

    • Chain Depth and Bloat: Deeply nested agent calls can lead to significant JWT size increases, potentially impacting HTTP header limits. The TTS MAY impose a maximum depth for the actchain. If the maximum depth is exceeded, the TTS MUST either reject the request or truncate the oldest entries in the chain, provided that a "truncated" flag is added to the claim to alert downstream services of the loss of provenance.¶

    • Privilege Escalation: A Delegator MUST NOT be able to request a replacement token with broader permissions or a higher-tier principal than what is asserted in its own subject_token. The TTS MUST validate that the requested scope and purp are a logical subset of the original token.¶

    • The TTS MUST verify that the workload requesting a replacement token is the entity identified in the act claim of the subject_token. This prevents an unauthorized workload from "injecting" itself into a transaction chain or extending a chain it is not part of.¶

    • During the replacement flow, the TTS MUST NOT allow the modification of the sub (principal) or txn claims. These fields provide the "anchor" for the entire transaction; any modification would effectively initiate a new transaction, requiring a fresh authentication event rather than a replacement flow.¶

6. References

Appendix A. Acknowledgments

The authors would like to thank the contributors and the OAuth working group members who gave valuable input to this draft.¶

Appendix B. Contributors

name: Atul Tulshibagwale org: SGNL email: atul@sgnl.ai¶

Author's Address