]>

abhishek@abhishekgoswami.io

General Internet Engineering Task Force OAuth 2.0 JWT AI Agents Authorization Agent Checksum LangGraph Autonomous Agents This document specifies Agentic JSON Web Token (Agentic JWT), as an extension to OAuth 2.0 that addresses authorization challenges unique to autonomous agentic AI systems. This protocol solves the problem of Zero-Trust drift due to non-deterministic Agentic AI clients causing separation between user's (resource owner's) intent and client application's actions. Traditional OAuth 2.0 assumes that client applications faithfully represent user intent when requesting authorization. This assumption breaks down when autonomous AI agents dynamically generate workflows, create sub-agents, and make authorization decisions without continuous human oversight. We term this the "intent-execution separation problem." Agentic JWT introduces three mechanisms to address this problem: (1) cryptographic agent identity through agent checksums (based on agent's system prompts, tools and configurations), (2) workflow-aware token binding that links user intent to agent execution, and (3) a new OAuth 2.0 grant type (agent_checksum) for secure token issuance, (4) a flavor of PoP (Proof-of-Possession) at the level of an agentic identity to prevent token replays by other agents in the same multi-agent process. This specification enables Zero-Trust security principles in multi-agent systems while maintaining backward compatibility with existing OAuth 2.0 infrastructure. The security analysis and experimental validation are described in the companion research paper.

Introduction OAuth 2.0 is designed for deterministic client applications that execute some workflow on behalf of a resource owner . The principle is that an authorization server (or Identity Provider, IDP) validates the client application using an authorization grant appoved by the resource owner and issues an access token as the proof of authorization, which is then used by some fixed workflow on the client to invoke an API hosted on the resource server. This mechanism breaks down for client applications using agentic AI with LLM reasoning because the decision to call resource server APIs could be taken by non-deterministic LLM reasoning that creates a separation between user's intent and actual agentic execution. Consider a multi-agent vulnerability patching system where a supervisor agent coordinates planner, classifier, and patcher sub-agents. Traditional OAuth 2.0 cannot detect when a low-privilege classifier agent tricks a high-privilege patcher into modifying critical system files, as the bearer token provides no cryptographic binding between user intent and agent execution. While next-generation protocols like GNAP address some OAuth 2.0 limitations through JSON-based grant negotiation, they do not provide the agent-specific identity verification and workflow binding mechanisms required for autonomous AI systems. This document addresses the following critical gaps in existing authorization frameworks for autonomous agents:

• Agent Identity: How to cryptographically verify agent identity beyond client_id credentials
• Intent Binding: How to bind user-authorized intent to specific agent workflows
• Delegation Control: How to prevent unauthorized cross-agent privilege escalation
• Agent level Proof-of-Posession: How to prevent token replaying by another agent running within the same client process.

This specification does NOT address:

• Model non-determinism or LLM safety
• Agent framework-specific implementation details
• Performance optimization techniques

Agentic AI based applications are rapidly solving more use cases and have already become targets for massive investments in enterprises across industries. Agentic clients would likely proliferate much faster than the currently available Zero-Trust implementations, including OAuth 2.0. The fundamental Zero-Trust principles outlined in the NIST 800.63 publication and are very much applicable and sound but current implementations need to catch up. This protocol enhancement attempts to achieve permanent protection from the possibility of Zero-Trust drift in API invocations done by agentic client applications. This specification outlines this novel protocol as fully backward compatible with the current OAuth 2.0 primitives while expanding the token issuance and resource server validation processes to recognzie agents as separate identities, their currently running version, the currently executing workflow and entire delegation chain in case of multi-agent applications. It also defines a way to make agentic clients auditable on the authorization server side.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

A comprehensive threat modelling using the STRIDE methodology , including experimental evaluation, and performance analysis is described in the research paper, . This document focuses on protocol specification for implementers. The system architecture and mechanisms described in this specification are the subject of U.S. Patent Application 19/315,486 .

This document uses the following terms in addition to those defined in and

Agentic Client:

An autonomous AI agent that acts as an OAuth 2.0 client. Unlike traditional clients, agentic clients can dynamically generate workflows, create sub-agents, and make authorization decisions without continuous human interaction.

Agent Checksum:

A SHA-256 cryptographic hash computed over the agent's configuration, including system prompt, available tools, and model parameters. The agent checksum uniquely identifies the agent's behavioral specification and serves as its cryptographic identity.

Intent Token:

A JWT (JSON Web token, ) issued by the authorization server that encapsulates user-authorized intent. The intent token includes new claims, and semantics such the workflow definition, requested scopes, agent checksum binding, workflow delegation chain, and user approval status. It is fully compatible with plain JWT tokens and other JWT primitives like JWS (JSON Web Signature, ) and JWE (JSON Web Encryption, ).

Workflow Binding:

The cryptographic association between a user-approved workflow and the access token issued for its execution. Implemented through the workflow_id and workflow_hash claims.

Delegation Assertion:

A cryptographic proof that an agent is authorized to execute a specific workflow on behalf of a user. Combines agent identity verification, intent binding, and scope restrictions. The mechanism is similar in spirit to OAuth 2.0 Token Exchange but uses agent-specific cryptographic binding instead of token exchange grants.

Agent Checksum Grant or agent_checksum:

A new OAuth 2.0 grant type (defined in Section 7) that allows agents to exchange intent tokens for access tokens using agent checksum verification instead of client credentials.

Supervisor Agent:

In multi-agent systems, the agent that coordinates sub-agent workflows and maintains the delegation chain. Referenced in examples throughout this document.

Intent-Execution Separation:

The security gap that occurs when an agent executes actions that diverge from user-authorized intent. Traditional OAuth 2.0 cannot detect this separation because bearer tokens do not bind authorization to specific execution contexts.

Human in the Loop

An agentic AI architectural pattern that involves some steps of an agentic workflow to be done or approved by human. The agentic workflow executes to a specific point and then pauses by notifying for human approval, it then waits until an approval is received before continuiing with the workflow.

Authorization Server or Identity Provider or IDP

This is the "Authorization Server" as defined in

Client Shim Library

Designed to be used as a dependency in any agentic client application to make the protocol flow of this intent based agentic jwt protocol easy to implement. It reduces the work on these client applications to a single line of code and hides all the complexity involved in performing the tasks necessary for seamless minting of intent tokens, verifying agent registrations from IDP (or Authorization Server), and tracking runtime agent workflow so that workflow state can be used while requesting an intent token.

This specification recognizes three agent types based on autonomy level:

Fully Supervised Agents:

Require human approval for each action

Semi-Autonomous Agents:

Execute pre-approved workflows with human oversight, such as when using Human in the Loop pattern.

Fully Autonomous Agents:

Execute complete workflows without human intervention

The security requirements vary by agent type, with fully autonomous agents requiring the strongest guarantees.

This agentic JWT architecture introduces the following novel (but backward compatible) protocol features:

• Enhancements in JWT Claims: The protocol introduces some new claims required for supporting the verification of agentic AI clients.
• A new Authorization Grant called agent_checksum: The protcol introduces a novel authorization grant called agent_checksum that allows the agentic client applications to act on behalf of the resource owner and enables the authorization servers to issue tokens without explicit credentials, by simply using an agent's runtime identity. An agent's runtime identity is typically composed of its system prompt, its tool specification (or a hash of actual tool function code), and LLM configuration (if applicable).
• Authorization Server token issuing protocol: The protocol adds unique verification capabilities on the authorization server side used during token issuance process.
• Resource Server verification protocol: The protocol adds additional verification capabilities on the resource server side.
• Intent Token: This is the new JWT compatible token that contains the additional claims plus the agent specific identity information. (see Intent Token).

All of the above mentioned architectural choices are fully backward compatible with OAuth 2.0. The architecture components that make these features possible can be implemented using general purpose programming languages like python, nodejs, java etc. The exact logical component design is outlined below:

• Client Shim Library: Implements the client side logic that performs the tasks necessary for seamless minting of intent tokens, verifying agent registrations from IDP (or Authorization Server), and tracking runtime agent workflow so that workflow state can be used while requesting an intent token.
• Authorization Server Library: Implements the Authorization Server side validation logic for authenticating incoming client requests using agent_checksum authorization grant.
• Resource Server Library: Implements the Resource Server side logic for token validation for intent tokens including per agent Proof-of-Posession verification.

The Agentic JWT protocol flow is conceptually similar to that of OAuth 2.0 at high level. However, the internal structure and mechanism is different and encapsulates agentic aware protocol features.

| Resource | | | | | | Owner | | | | | | | | | |<-+--(B)---Authorization-Grant------+ | | | | | (agent_checksum) +-----------------+ | | | | | | | | | | Shim Library | | +-----------------+ | | +--+---(C)-----agent_checksum------->| | | | | | | | | | | | | Authorization | | | | | | Server | | | |<-+--(D)------intent-token----------+ | | | | | (with agent information) +-----------------+ | | | | | | | | +-----------------+ | | +--+--(E)------intent-token--------->| | | | | | | Resource | | | | | | Server | | | |<-+--(F)----Protected-Resource------+ | | +----------------+ | +-----------------+ +----------------------+ Workflow: User → IDP → Intent Token → Agent → Access Token → API ]]>

The protocol flow described in Figure 1 outlines the interactions between the client (via Shim Library), the Resource Owner, the Authorization Server, and the Resource Server. This flow is fully compatible with the original OAuth 2.0 protocol flow. The complexities of verifying registered agents on the Client, capturing runtime identity of an agent for minting intent tokens, tracking runtime workflow and sending these to Authorization Server with the intent token request, are hidden inside the Shim Library. A Client application just needs to include the Shim library as a dependency to make this flow work. The protocol flow steps are described below:

1. The client makes an authorization grant request to the resource owner either directly or preferably via the authorization server. Having authorization grant means that each agent running within the client process has been registered as identity in the authorization server with an Agent Checksum (see ) of its system prompt, tool specifications, and LLM configuration.
2. The client receives an authorization grant that can be used to request intent tokens from the authorization server. This is new authorization grant type called agent_checksum. The agent_checksum authorization grant is based on an agent's inherent signature used as its identity. An agent's signature comprises of its system prompt, tools specifications (or tool function code), and LLM configuration. This new grant type is described in
3. The shim library running within the client process requests an intent token by presenting the authorization grant of 'agent_checksum' which uses the currently running agent's signature as part of the input. The shim library computes the runtime Agent Checksum (see of the running agent and includes in the intent token request.
4. The authorization server validates the request against the registered agents, by comparing agent checksum in the input with regisrered checksums, and if valid, issues the intent token.
5. The shim library, running within the client process, requests the protected resource from the resource server by presenting the intent token for authentication and authorization information.
6. The resource server validates the intent token,and if valid, serves the request.

This specification defines a new OAuth 2.0 grant type for autonomous AI agents: "agent_checksum". This grant type enables agents to obtain access tokens (called intent tokens in context of this specification) by proving their identity through cryptographic checksum verification rather than traditional client credentials. The grant type is designed specifically for agentic clients that:

• Have registered their agent checksum with the authorization server
• Optionally execute pre-approved workflows with defined steps
• Maintain delegation chains across multi-agent systems
• Require proof-of-possession token binding

Grant Type Identifier: Note: For brevity in examples, this document uses the short form "agent_checksum" instead of the full URN.

The client shim library (see ), on behalf of an agent, makes a request to the token endpoint by sending the following parameters using the "application/json" format with a character encoding of UTF-8:

grant_type:

REQUIRED. Value MUST be "agent_checksum" (or the full URN).

agent_id:

REQUIRED. The unique identifier of the registered agent.

computed_checksum:

REQUIRED. The SHA-256 checksum computed over the agent's current configuration. Format: "sha256:<hex>".

workflow_id:

REQUIRED when workflow_enabled is true. The identifier of the registered workflow being executed.

workflow_step:

REQUIRED when workflow_enabled is true. The identifier of the specific workflow step being executed.

workflow_enabled:

OPTIONAL. Boolean indicating whether workflow validation should be enforced. Default: false.

requested_scopes:

REQUIRED. Array of OAuth 2.0 scopes requested for this token.

audience:

REQUIRED. The intended audience (resource server) for the token. May be a single string or array of strings.

delegation_context:

OPTIONAL. Object containing delegation chain information for multi-agent workflows. Contains "chain" (array of parent agent_ids) and "completed_steps" (array of completed workflow step identifiers).

Example HTTP request (with line breaks for readability): { "grant_type": "agent_checksum", "agent_id": "vulnerability-patcher-v1", "computed_checksum": "sha256:a3c7f2e8d9b4f1e2c8a7d6f3e9b2c4f1...", "workflow_id": "auto-patch-workflow-v1", "workflow_step": "step_3_patch_application", "workflow_enabled": true, "requested_scopes": [ "repo:write", "vulnerability:read" ], "audience": "https://api.github.com", "delegation_context": { "chain": [ "supervisor-agent", "planner-agent", "vulnerability-patcher-v1" ], "completed_steps": [ "step_1_analyze_manifest", "step_2_create_patch_plan" ] } } ]]>

The token endpoint MUST be protected. In the reference implementation, requests require an Authorization header with a bearer token that has the "generate:intent-token" scope and audience "idp.localhost". This token may well be the usual JWT client level access token that uses one of the traditional OAuth 2.0 Authorization Grants . Implementations MAY use different authentication mechanisms (e.g., client credentials, mutual TLS) but MUST ensure that only authorized entities can request tokens on behalf of agents.

Upon receiving a token request, the authorization server MUST perform the following validation steps IN ORDER:

1. Grant Type Validation: Verify that grant_type equals "agent_checksum". If invalid → Return error "unsupported_grant_type" ()
2. Agent Existence Check: Verify that agent_id exists in the agent registry. If not found → Return error "unknown_agent" ()
3. Checksum Verification: Retrieve the registered checksum for agent_id. Compare computed_checksum with the stored checksum. If mismatch → Return error "agent_checksum_mismatch" ()
4. Workflow Step Authorization (if workflow_enabled): Validate that the agent is authorized to execute the specified workflow_step within workflow_id. Verify prerequisite steps are completed (from delegation_context). Check approval requirements if step requires approval. If unauthorized → Return error "workflow_step_unauthorized" (
5. Token Creation: If all validations pass, create and sign the intent token ().

For the checksum verification procedure please see

When workflow_enabled is true, the authorization server MUST validate the workflow execution state:

1. Verify that workflow_id exists in the workflow registry
2. Verify that workflow_step exists within the workflow definition
3. Check that all required prerequisite steps have been completed:
   • Retrieve the step definition for workflow_step
   • Identify all steps marked as "required" that appear before workflow_step in the workflow sequence
   • Verify all required steps are present in delegation_context.completed_steps
4. If the step has requires_approval=true:
   • Locate the most recent approval gate step before workflow_step
   • Verify that approval gate step is in completed_steps
   • If no approval gate found or not completed → reject request

This validation ensures that agents cannot skip required steps or bypass approval gates in multi-step workflows.

If delegation_context is provided, the authorization server SHOULD validate the delegation chain:

• Verify that all agents in the chain are registered
• Verify that the chain represents a valid delegation path (parent agents authorized the delegation)
• Verify that the requesting agent is the last element in the chain

The delegation_context.chain array represents the delegation hierarchy from the original initiating agent to the current agent. For example: ["supervisor", "planner", "patcher"] indicates that the supervisor delegated to the planner, which delegated to the patcher.

If the request is valid and all verification checks pass, the authorization server issues an intent token and returns it in the response: Response fields:

access_token:

REQUIRED. The intent token encoded as a JWT.

token_type:

REQUIRED. MUST be "Bearer".

expires_in:

RECOMMENDED. Lifetime in seconds. For intent tokens, this SHOULD be short (e.g., 300 seconds / 5 minutes).

scope:

OPTIONAL. Space-delimited list of scopes granted. MAY differ from requested_scopes if authorization server applies restrictions.

The intent token is a JWT with the following claims: Standard JWT Claims:

iss (Issuer):

REQUIRED. Authorization server identifier.

aud (Audience):

REQUIRED. Intended recipient(s). Value from request.audience.

sub (Subject):

REQUIRED. Agent identifier (request.agent_id).

exp (Expiration):

REQUIRED. Token expiration time (Unix timestamp). SHOULD be iat + 300 seconds for intent tokens.

iat (Issued At):

REQUIRED. Token issuance time (Unix timestamp).

jti (JWT ID):

REQUIRED. Unique token identifier for replay prevention.

scope:

REQUIRED. Space-delimited OAuth 2.0 scopes.

Proof-of-Possession Claim:

cnf (Confirmation):

REQUIRED. Proof-of-possession confirmation as defined in RFC 7800 . Contains "jwk" field with the agent's public key in JWK format.

Intent-Specific Claims (nested under "intent" object):

workflow_id:

REQUIRED when workflow_enabled. Workflow identifier.

workflow_step:

REQUIRED when workflow_enabled. Current step identifier.

executed_by:

REQUIRED. Agent executing this step (same as sub).

delegation_chain:

REQUIRED. Cryptographic hash of the delegation sequence. Computed as SHA-256 over the pipe-delimited chain of agent_ids, truncated to 16 hex characters. See

step_sequence_hash:

REQUIRED. Cryptographic hash of completed workflow steps. Computed as SHA-256 over pipe-delimited completed step IDs, truncated to 16 hex characters. See

Agent Proof Claims (nested under "agent_proof" object):

agent_checksum:

REQUIRED. The verified agent checksum (from request.computed_checksum). See for detailed agent identity and checksum analysis.

registration_id:

REQUIRED. The registration identifier from the agent registry, enabling token revocation at the registration level.

Example decoded intent token payload:

The delegation_chain and step_sequence_hash provide cryptographic integrity over the workflow execution path: Delegation Chain Hash: Step Sequence Hash: If an agent has skipped steps or altered the delegation chain, the IDP side library will be able to detect during intent token request. However, including these hashes in the intent token additionally enables resource servers to detect if an agent has skipped steps or altered the delegation chain.

Error responses follow the OAuth 2.0 error response format defined in Section 5.2 of RFC 6749 :

Error Code: unsupported_grant_type HTTP Status: 400 Bad Request Description: The grant_type parameter does not equal "agent_checksum". Example:

Error Code: unknown_agent HTTP Status: 401 Unauthorized Description: The agent_id is not registered with the authorization server. Recommended Action: Agent must complete registration (Section 6.1) before requesting tokens. Example:

Error Code: agent_checksum_mismatch HTTP Status: 401 Unauthorized Description: The computed_checksum does not match the registered checksum for the agent_id. This indicates that the agent's configuration (prompt, tools, or model parameters) has been modified since registration. Security Implication: This is a critical security error that may indicate:

• Unauthorized modification of the agent
• Attempted impersonation attack
• Code integrity violation

Recommended Action: Agent must re-register with updated checksum before requesting tokens. Authorization server SHOULD log this event for security monitoring. Example:

Error Code: workflow_step_unauthorized HTTP Status: 403 Forbidden Description: The agent is not authorized to execute the specified workflow_step. This may occur when:

• Prerequisite steps have not been completed
• Required approval gate has not been passed
• Step is not defined in the workflow
• Agent is not assigned to this workflow step

Recommended Action: Review workflow definition and ensure all required prerequisites are met. Example:

Error Code: invalid_request HTTP Status: 400 Bad Request Description: The request is malformed or missing required parameters. Common causes:

• Missing required fields (agent_id, computed_checksum, etc.)
• Invalid JSON format
• workflow_enabled=true but workflow_id/workflow_step missing
• Invalid checksum format (must be "sha256:<hex>")

Example:

For grant type specific security considerations, see:

• Checksum verification:
• Token lifetime: Section
• Workflow validation:

For comprehensive security analysis, see .

The authorization server maintains an agent registry mapping agent_id to registration records. Each record contains:

• agent_id - Unique identifier
• checksum - SHA-256 agent checksum
• registration_id - Unique registration instance ID
• public_key - Agent's public key (for cnf claim)
• registered_at - Registration timestamp
• version - Registration version (for checksum updates)

Multiple registrations may exist for the same agent_id when the agent's configuration changes. The authorization server uses the LATEST registration for verification.

The workflow registry stores workflow definitions including:

• workflow_id - Unique workflow identifier
• steps - Ordered array of workflow step definitions

Each step contains:

• step_id - Unique step identifier
• required - Boolean indicating if step is required
• requires_approval - Boolean for approval requirement
• approval_gate - Boolean marking this step as approval gate
• agent_id - Agent authorized to execute this step (optional)

The checksum verification and workflow validation add overhead to token issuance. Implementations SHOULD:

• Cache agent registry lookups to reduce database queries
• Use indexed database queries on agent_id for fast lookup
• Pre-compute workflow step dependencies to speed validation
• Implement connection pooling for registry data stores

The reference implementation shows ~4.3% overhead compared to standard OAuth 2.0 token issuance, which is acceptable for most production deployments.

Agent identity in this specification is based on cryptographic checksums computed over an agent's configuration. Unlike traditional client credentials that can be shared or stolen, the agent checksum provides a unique cryptographic fingerprint of the agent's actual implementation. The agent checksum serves three critical functions:

• Identity Verification: Proves that an agent's configuration matches what was registered with the authorization server
• Code Integrity: Detects unauthorized modifications to the agent's system prompt, tools, or configuration
• Non-Transferability: Prevents credentials from being reused by different agent implementations

This section defines how agent identity is established, verified, and maintained throughout the agent lifecycle.

An agent's identity is derived from its specification, which includes all components that define the agent's behavior:

agent_id:

REQUIRED. Unique identifier for the agent. MUST be unique within the application scope. Format: alphanumeric with hyphens, e.g., "vulnerability-patcher-v1".

prompt:

REQUIRED. The complete system prompt that defines the agent's role, capabilities, and constraints. This is the full text provided to the language model that shapes agent behavior.

tools:

REQUIRED. Array of tool definitions available to the agent. Each tool includes name, description, and parameter schema. The order of tools MUST be deterministic.

configuration:

OPTIONAL. Additional configuration parameters including:

• model_name - Language model identifier
• temperature - Sampling temperature (0.0-1.0)
• max_tokens - Maximum generation length
• top_p - Nucleus sampling parameter

Example agent specification for a vulnerability patching agent:

Tools may be included in the checksum computation at two levels:

Shallow (Default):

Only the tool signature (name, description, parameters) is included in the checksum. The actual function implementation is not hashed. This allows tool implementation to evolve without requiring re-registration.

Deep:

The complete tool implementation, including normalized function source code, is included in the checksum. This provides stronger integrity guarantees but requires re-registration for any code changes.

Implementations MUST support shallow checksums. Deep checksums are OPTIONAL and MAY be indicated through tool metadata. In the reference implementation, tools are marked for deep checksumming using a decorator: When including source code in deep checksums, implementations MUST normalize the source code to ensure formatting changes do not affect checksums while logic changes are always detected.

Tool function signatures MUST be normalized to remove framework-specific wrapper parameters that do not affect agent behavior. This ensures that checksums remain stable across different agent frameworks. Wrapper Parameters to Remove:

• config - Framework configuration object
• callbacks - Callback handlers
• run_manager - Execution manager
• tags - Execution tags
• metadata - Execution metadata
• run_id - Execution identifier
• **kwargs - Catchall for framework parameters

Reference implementation for signature normalization: str: """ Get function signature with wrapper parameters removed. """ # Unwrap decorators to get original function current = func try: current = inspect.unwrap(func) except (ValueError, AttributeError): pass sig = inspect.signature(current) # Known wrapper parameters to filter out WRAPPER_PARAMS = { 'config', 'callbacks', 'run_manager', 'tags', 'metadata', 'run_id', 'parent_run_id', 'configurable', 'recursion_limit' } # Build cleaned parameter list cleaned_params = [] for name, param in sig.parameters.items(): # Skip known wrapper params if name in WRAPPER_PARAMS: continue # Skip VAR_KEYWORD (**kwargs) if it looks like wrapper catchall if param.kind == inspect.Parameter.VAR_KEYWORD: continue # Skip VAR_POSITIONAL (*args) used by wrappers if param.kind == inspect.Parameter.VAR_POSITIONAL and name == 'args': continue cleaned_params.append(param) # Create new signature new_sig = inspect.Signature( cleaned_params, return_annotation=sig.return_annotation ) return str(new_sig) ]]> This normalization is CRITICAL for cross-framework compatibility. Without it, the same logical tool would have different checksums when used in LangChain vs CrewAI vs other frameworks.

For deep checksum tools that include source code, implementations MUST normalize the source code using Abstract Syntax Tree (AST) parsing. This ensures that formatting changes do not affect checksums while any logic changes are always detected. Normalization process:

1. Parse source code to AST (Abstract Syntax Tree)
2. Remove docstrings (captured separately in tool description)
3. Remove comments (not part of execution logic)
4. Unparse AST to canonical form

Reference implementation: None: """ Remove docstring nodes from AST in-place. Docstrings are captured separately in tool description, so we remove them from implementation to avoid duplication. """ for node in ast.walk(tree): if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef, ast.ClassDef, ast.Module)): if (node.body and isinstance(node.body[0], ast.Expr) and isinstance(node.body[0].value, ast.Constant) and isinstance(node.body[0].value.value, str)): # This is a docstring - remove it node.body = node.body[1:] if len(node.body) > 1 else [ast.Pass()] def normalize_source(source_code: str) -> str: """ Normalize Python source code using AST. This ensures that formatting changes don't affect checksums while logic changes are always detected. Strips: - Comments (not part of execution logic) - Formatting differences (whitespace, indentation) - Docstrings (captured separately in checksum) Preserves: - All execution logic - Variable names (semantically significant) - Control flow structures - Function calls and their arguments """ # Remove leading indentation source = textwrap.dedent(source_code) try: # Parse to AST tree = ast.parse(source) # Remove docstrings remove_docstrings(tree) # Unparse to canonical form normalized = ast.unparse(tree) return normalized except SyntaxError: # If code has syntax errors, return as-is # This will cause checksum mismatch (correct behavior) return source def get_tool_source_code(func: callable) -> str | None: """ Get normalized source code for a tool function. Returns None if source cannot be retrieved. """ try: source = inspect.getsource(func) normalized = normalize_source(source) return normalized except (OSError, TypeError): return None ]]> This normalization means:

• SAME checksum: Reformatting code, adding comments, changing indentation
• DIFFERENT checksum: Changing logic, adding/removing statements, modifying control flow

Example demonstrating normalization:

The agent checksum MUST be computed as follows:

1. Construct Agent Components Object: Create a JSON object containing the agent's configuration:
2. Canonicalize JSON: Serialize the object using RFC 8785 JSON Canonicalization Scheme (JCS). This ensures deterministic ordering of keys and consistent formatting. Canonical serialization is REQUIRED because:
   • JSON objects have no inherent key ordering
   • Whitespace and formatting vary across implementations
   • Floating point precision may differ
   • Unicode escaping can be inconsistent
3. Compute SHA-256 Hash: Hash the canonical JSON bytes using SHA-256 as defined in FIPS 180-4 .
4. Format Checksum: Encode the hash as lowercase hexadecimal (64 characters): Note: The reference implementation uses bare hex encoding. Implementations MAY prefix with "sha256:" for explicit algorithm identification.

Implementations MUST ensure checksum computation is deterministic across different platforms, languages, and runtime environments. Reference Implementation (Python): str: """ Normalize prompt string for consistent checksum computation. Apply this in BOTH client and server-side computation. """ if not prompt: return "" # 1. Strip leading/trailing whitespace normalized = prompt.strip() # 2. Normalize line endings (Windows \r\n vs Unix \n) normalized = normalized.replace('\r\n', '\n') # 3. Collapse multiple consecutive newlines into single newline import re normalized = re.sub(r'\n\s*\n', '\n', normalized) # 4. Strip whitespace from each line lines = [line.strip() for line in normalized.split('\n')] normalized = '\n'.join(lines) # 5. Remove empty lines lines = [line for line in lines if line] normalized = '\n'.join(lines) return normalized def compute_agent_checksum(agent_components) -> str: """ Compute deterministic SHA-256 checksum for agent configuration. Args: agent_components: Object with fields: - agent_id: str - prompt_template: str - tools: list of Tool objects - configuration: dict Returns: 64-character lowercase hex string (SHA-256 hash) """ # Construct canonical components object components = { "id": agent_components.agent_id, "prompt": normalize_prompt(agent_components.prompt_template), "tools": sorted([ { "name": tool.name, "signature": tool.signature, "description": tool.description # "source_code" included only for deep checksum tools } for tool in agent_components.tools ], key=lambda x: x["name"]), # Sort tools by name "config": agent_components.configuration } # Serialize with sorted keys for determinism content = json.dumps(components, sort_keys=True) # Compute SHA-256 hash return hashlib.sha256(content.encode('utf-8')).hexdigest() ]]> Critical Requirements:

• Use json.dumps() with sort_keys=True for deterministic JSON serialization
• Normalize prompts using the exact normalization function above (whitespace, line endings, empty lines)
• Sort tools by name before serialization
• Encode JSON string as UTF-8 before hashing
• Output lowercase hexadecimal (64 characters)
• Tool signatures MUST use get_core_signature() to remove wrapper parameters (see Section 4.2.4)

Common Implementation Pitfalls:

• Not normalizing prompts identically on client and server (most common cause of checksum mismatch)
• Including wrapper function parameters in tool signatures (config, callbacks, run_manager, etc.)
• Platform-specific line endings (\r\n vs \n) in prompts
• Non-deterministic tool ordering (MUST sort by name)
• Using standard JSON.stringify() without sort_keys
• Uppercase hexadecimal encoding (MUST be lowercase)

Before an agent can request tokens, it MUST register its checksum with the authorization server. Registration creates a binding between the agent_id and its cryptographic identity. The registration process:

1. Agent computes its checksum client-side
2. Agent sends registration request to IDP
3. IDP validates agent configuration
4. IDP recomputes checksum for verification
5. IDP stores agent_id → checksum mapping
6. IDP returns registration confirmation

The authorization server MUST perform the following steps:

1. Validate Request Structure: Verify all required fields are present and properly formatted
2. Compute Checksum: Recompute agent checksum from agent_components using the algorithm defined in Section 4.2.1
3. Check for Duplicates: Verify that the computed checksum does not already exist in the registry. If it does, reject with error "duplicate_agent". This prevents agent impersonation.
4. Generate Registration ID: Create unique registration identifier:
5. Store Registration: Persist mapping:
6. Return Confirmation: Return registration details to client

Success response: Error response (duplicate checksum):

When an agent's configuration changes (e.g., tool updates, prompt modifications), a new checksum is computed and the agent MUST re-register. NOTE: This registration process can be automated by introdcuing additional steps into CI / CD or by Model Context Protocol (MCP, ) integration to the IDP server, or by any other agent resource management process. Regardless of the methodology used the underlying conceptual process remains the same. Update procedure:

1. Compute new checksum from updated configuration
2. Submit new registration request (same agent_id)
3. IDP validates new checksum is different from previous
4. IDP creates new registration record with incremented version
5. IDP MAY maintain previous registrations for audit trail
6. IDP uses LATEST registration for token validation

Example: Agent version progression The IDP MUST use the latest version (highest registered_at) for checksum verification during token requests.

Before requesting a token, the agent MUST compute its current checksum and include it in the token request. This proves that the requesting agent's configuration matches the registered identity. Client-side process:

Upon receiving a token request, the authorization server MUST verify the agent checksum: The comparison MUST use constant-time string comparison to prevent timing attacks that could reveal checksum information. NOTE: The authorization server retrieves the LATEST registration for the agent_id, as agents may re-register with updated checksums when their configuration changes.

Agent identity progresses through several stages:

1. UNREGISTERED: Agent exists but has not registered with IDP. Cannot request tokens.
2. REGISTERED: Agent checksum stored in IDP registry. Can request tokens if checksum matches.
3. VERIFIED: Agent successfully authenticated and obtained token. Identity confirmed through checksum match.
4. UPDATED: Agent configuration changed, new checksum computed, re-registration required. Previous tokens may be invalidated.
5. REVOKED: Agent identity revoked by administrator. All tokens invalidated. Cannot request new tokens.

Valid state transitions: REGISTERED | v REGISTERED --[token request + checksum match]--> VERIFIED | v VERIFIED --[config change]--> UPDATED --[re-register]--> REGISTERED | v ANY STATE --[admin action]--> REVOKED ]]>

Agent identity security considerations:

• Checksum strength: See
• Registration security: See
• Agent Registry Security: See

For comprehensive security analysis, see .

This section describes the detailed protocol flows for agent registration, token issuance, and authorization. Each flow includes step-by-step procedures, HTTP request/response examples, and validation requirements. The flows in this section build upon the abstract protocol flow described in , providing complete implementation guidance for:

• Agent registration and checksum verification
• Workflow registration and definition
• Intent token issuance with user approval
• Access token requests using agent_checksum grant
• API authorization and token validation
• Multi-agent delegation chains

Before an agent can request tokens, it MUST register its identity with the authorization server. This flow establishes the cryptographic binding between the agent_id and its configuration checksum.

Agent registration sequence: │ │ │ │ │ │ │ 3. POST /register/agent│ │ │──────────────────────>│ │ │ (agent_components, │ │ │ public_key) │ │ │ │ │ │ │ 4. Recompute │ │ │ checksum │ │ │<─────────── │ │ │ │ │ │ 5. Check for │ │ │ duplicates │ │ │<─────────── │ │ │ │ │ │ 6. Store │ │ │ registration │ │ │<─────────── │ │ │ │ │ 7. Registration response│ │ │<──────────────────────│ │ │ (registration_id, │ │ │ checksum) │ │ │ │ ]]>

1. Agent Checksum Computation (Client-Side): The agent runtime computes its configuration checksum using the algorithm defined in . This includes the agent's prompt, tools, and configuration parameters.
2. Public Key Generation (Optional): If proof-of-possession is required, the agent generates an RSA key pair and prepares the public key in PEM format.
3. Registration Request: The application sends a registration request to the IDP's agent registration endpoint, including the complete agent configuration and optional public key.
4. Server-Side Checksum Verification: The IDP recomputes the agent checksum from the submitted configuration and verifies it matches the claimed checksum.
5. Duplicate Detection: The IDP checks if the computed checksum already exists in the registry. If found, the request is rejected with error "duplicate_agent" to prevent agent impersonation.
6. Registration Storage: The IDP creates a unique registration_id, stores the mapping (agent_id → checksum → registration_id), and persists the registration record.
7. Response: The IDP returns the registration_id and computed checksum to the client for verification.

Workflows define the sequence of steps that agents execute and the authorization requirements for each step. Workflow registration establishes the workflow definition with the IDP before execution.

│ │ (workflow_id, steps[]) │ │ │ │ │ 2. Validate │ │ structure │ │<─────────── │ │ │ │ 3. Check for │ │ duplicates │ │<─────────── │ │ │ │ 4. Store │ │ workflow │ │<─────────── │ │ │ 5. Registration confirmation │ │<────────────────────────────────────────│ │ (workflow_id, status) │ │ │ ]]>

Workflow registration request: { "workflow_id": "auto-patch-workflow-v1", "steps": { "step_1_analyze_manifest": { "required": true, "requires_approval": false, "agent_id": "vulnerability-analyzer" }, "step_2_create_patch_plan": { "required": true, "requires_approval": false, "agent_id": "patch-planner" }, "step_3_approval_gate": { "required": true, "requires_approval": false, "approval_gate": true }, "step_4_apply_patch": { "required": true, "requires_approval": true, "agent_id": "vulnerability-patcher-v1" }, "step_5_verify_patch": { "required": true, "requires_approval": false, "agent_id": "patch-verifier" } } } ]]> Success response:

This flow describes how an agent requests an intent token using the agent_checksum grant type. The flow includes agent identity verification, workflow step authorization, and token issuance.

│ │ │ │ │ │ │ │ │ │ │2. Compute │ │ │ │ │ checksum │ │ │ │<────────────│ │ │ │ │ │ │ │ │ │3. Checksum │ │ │ │ │────────────>│ │ │ │ │ │ │ │ │ │ │4. POST /token│ │ │ │ │──────────────┼─────────────>│ │ │ │ (agent_id, │ │ │ │ │ checksum, │ │ │ │ │ workflow) │ │ │ │ │ │ │ │ │ │ │ │5. Get agent │ │ │ │ │ registration │ │ │ │ │───────────────>│ │ │ │ │ │ │ │ │ │6. Registration │ │ │ │ │<───────────────│ │ │ │ │ │ │ │ │ │7. Verify │ │ │ │ │ checksum │ │ │ │ │<─────────── │ │ │ │ │ │ │ │ │ │8. Validate │ │ │ │ │ workflow step│ │ │ │ │<─────────── │ │ │ │ │ │ │ │ │ │9. Create token │ │ │ │ │<─────────── │ │ │ │ │ │ │ │10. Token │ │ │ │ │<─────────────┼─────────────│ │ │ │ response │ │ │ │ │ │ │ │ ]]>

1. Execution Trigger: Agent execution is triggered by application logic or user request.
2. Checksum Computation: Client computes current agent checksum using algorithm from Section 5.3.
3. Checksum Return: Agent runtime returns computed checksum to client library.
4. Token Request: Client sends token request to IDP with agent_checksum grant type, including agent_id, computed checksum, workflow details, and requested scopes.
5. Registry Lookup: IDP retrieves agent registration from registry based on agent_id.
6. Registration Return: Registry returns stored registration including registered checksum.
7. Checksum Verification: IDP compares computed_checksum (from request) with stored checksum. If mismatch, return error "agent_checksum_mismatch".
8. Workflow Step Validation: If workflow_enabled=true, IDP validates:
   • Workflow exists in registry
   • Step exists in workflow definition
   • Required prerequisite steps are completed
   • Approval requirements are satisfied
   If validation fails, return error "workflow_step_unauthorized".
9. Token Creation: IDP creates intent token with:
   • Standard JWT claims (iss, aud, sub, exp, iat, jti, scope)
   • cnf claim with agent's public key
   • intent object with workflow details
   • agent_proof object with checksum and registration_id
10. Token Response: IDP returns token response with access_token, token_type, expires_in, and granted scopes.

This flow describes how a resource server validates an intent token and authorizes an API request from an agent. The validation includes token signature verification, checksum validation, workflow binding checks, and scope verification.

│ │ │ │ │ │ │ │ │2. GET /api │ │ │ │──────────────>│ │ │ │ Bearer token│ │ │ │ │ │ │ │ │3. Get JWKS │ │ │ │───────────────>│ │ │ │ │ │ │ │4. Public keys │ │ │ │<───────────────│ │ │ │ │ │ │ │5. Verify │ │ │ │ signature │ │ │ │<─────────── │ │ │ │ │ │ │ │6. Validate │ │ │ │ claims │ │ │ │<─────────── │ │ │ │ │ │ │ │7. Check scope │ │ │ │<─────────── │ │ │ │ │ │ │ │8. Process │ │ │ │ request │ │ │ │<─────────── │ │ │ │ │ │ │9. API response│ │ │ │<──────────────│ │ │ │ │ │ │10. Result │ │ │ │<────────────│ │ │ │ │ │ │ ]]>

1. Extract Token: Resource server extracts Bearer token from Authorization header.
2. Retrieve JWKS: Resource server fetches IDP's JSON Web Key Set for signature verification.
3. Verify Signature: Resource server verifies JWT signature using IDP's public key identified by "kid" header.
4. Validate Standard Claims:
   • Check token not expired (exp > current time)
   • Validate issuer (iss matches expected IDP)
   • Validate audience (aud matches resource server)
   • Check token issued time (iat not in future)
5. Validate Agent Proof:
   • Verify agent_proof.agent_checksum is present
   • Verify agent_proof.registration_id is present
   • Optionally verify checksum against known agents
6. Validate Workflow Binding (if applicable):
   • Check intent.workflow_id matches expected workflow
   • Verify intent.workflow_step is authorized for this API
   • Validate delegation_chain if delegation is restricted
7. Verify Scopes: Check that requested operation is permitted by token scopes.
8. Proof-of-Possession (Optional): If required, verify PoP signature using public key in cnf claim.
9. Process Request: If all validations pass, execute the API operation.

Multi-agent workflows involve delegation chains where a supervisor agent delegates tasks to subordinate agents. Each agent in the chain requests its own token, building upon the delegation context from parent agents. This flow illustrates a three-agent delegation chain for automated vulnerability patching:

• Supervisor Agent - Orchestrates the workflow
• Planner Agent - Creates patch strategy
• Patcher Agent - Applies the actual patch

│ │ (step_1, │ │ │ │ │ chain=[]) │ │ │ │ │ │ │ │ │ │2. Token │ │ │ │ │<─────────────┼─────────────┼──────────┼────────────│ │ │ │ │ │ │3. Delegate │ │ │ │ │ to Planner │ │ │ │ │─────────────>│ │ │ │ │ │ │ │ │ │ │4. Request │ │ │ │ │ token │ │ │ │ │─────────────┼──────────┼───────────>│ │ │ (step_2, │ │ │ │ │ chain=[S]) │ │ │ │ │ │ │ │ │ │5. Token │ │ │ │ │<────────────┼──────────┼────────────│ │ │ │ │ │ │ │6. Delegate │ │ │ │ │ to Patcher│ │ │ │ │────────────>│ │ │ │ │ │ │ │ │ │ │7. Request│ │ │ │ │ token │ │ │ │ │──────────┼───────────>│ │ │ │(step_4, │ │ │ │ │chain=[S,P]) │ │ │ │ │ │ │ │ │ │8. Approval │ │ │ │ │ required │ │ │ │ │<───────────│ │ │ │ │ │ │ │ │ │9. Approve │ │ │ │ │───────────>│ │ │ │ │ │ │ │ │10. Token │ │ │ │ │<─────────┼────────────│ │ │ │ │ │ │ │ │11. Execute │ │ │ │<───────── │ │ │ │ │ ]]> Legend: S = Supervisor, P = Planner

1. Supervisor Token Request: Supervisor agent requests token for step_1 with empty delegation chain.
2. Supervisor Executes Step 1: Supervisor analyzes the manifest and determines patching is needed.
3. Delegation to Planner: Supervisor delegates to Planner agent, passing delegation context.
4. Planner Token Request: Planner requests token for step_2, including Supervisor in chain.
5. Planner Executes Step 2: Planner creates patch strategy and identifies target packages.
6. Delegation to Patcher: Planner delegates to Patcher agent, passing updated delegation context.
7. Patcher Token Request: Patcher requests token for step_4, including full delegation chain.
8. Approval Check: IDP detects step_4 requires approval (step_3 is approval gate). Step_3 must be in completed_steps or request is rejected.
9. User Approval: User has already approved at step_3 approval gate.
10. Token Issuance: IDP issues token to Patcher with:
    • delegation_chain: SHA-256("supervisor-agent|patch-planner|vulnerability-patcher-v1")
    • step_sequence_hash: SHA-256("step_1|step_2|step_3|step_4")
11. Patcher Execution: Patcher applies the security patch using the intent token.

At each delegation step, the IDP validates:

1. Chain Continuity: Current agent is appended to delegation_context.chain, not inserted or replaced.
2. Step Sequence: completed_steps contains all required prerequisite steps.
3. Approval Requirements: If step requires approval, the most recent approval gate must be in completed_steps.
4. Agent Authorization: Current agent is authorized to execute the requested workflow step.

Resource servers MAY additionally validate:

• Delegation depth is within acceptable limits
• All agents in delegation chain are registered and not revoked
• Delegation chain matches expected workflow pattern

Future Work Future versions or extensions of this specification may align with the Grant Negotiation and Authorization Protocol (GNAP) , which provides a JSON-based foundation for dynamic authorization scenarios. A GNAP binding for Agentic JWT would enable the agent-specific security mechanisms defined in this specification to work within the GNAP framework. Additional areas for future development include:

• Integration with Model Context Protocol (MCP) standard
• Support for additional hash algorithms beyond SHA-256
• Cross-domain agent identity federation
• Support for gRPC protocol.
• Support for prorietary protocols used for database connections, and asynchrnous messaging.

This specification requires IANA to register a new OAuth 2.0 authorization grant type, JWT claims, OAuth parameters, and error codes in the appropriate registries.

This section registers the following grant type value in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for Auth" : OAuth Grant Type Registration

Grant Type	URN	Common Name	Change Controller	Reference
agent_checksum	urn:ietf:params:oauth:grant-type:agent_checksum	Agent Checksum Grant type for OAuth 2.0	IETF	[this document],

This section registers the following claims in the IANA "JSON Web Token Claims" registry established by : JWT Claims Registrations

Claim Name	Claim Description	Change Controller	Specification Document
workflow_id	Identifier of the workflow being executed	IETF	[this document],
workflow_step	Identifier of the current workflow step	IETF	[this document],
executed_by	Agent identifier executing the workflow step	IETF	[this document],
delegation_chain	SHA-256 hash of agent delegation sequence	IETF	[this document],
step_sequence_hash	SHA-256 hash of completed workflow steps	IETF	[this document],
agent_checksum	SHA-256 checksum of agent configuration	IETF	[this document],
registration_id	Unique agent registration instance identifier	IETF	[this document],

This section registers the following parameters in the IANA "OAuth Parameters" registry established by : OAuth Parameters Registrations

Parameter Name	Parameter Usage Location	Change Controller	Specification Document
agent_id	token request	IETF	[this document],
computed_checksum	token request	IETF	[this document],
workflow_id	token request	IETF	[this document],
workflow_step	token request	IETF	[this document],
workflow_enabled	token request	IETF	[this document],
delegation_context	token request	IETF	[this document],
requested_scopes	token request	IETF	[this document],

This section registers the following error codes in the "OAuth Extensions Error Registry" established by : OAuth Error Code Registrations

Error Name	Error Usage Location	Related Protocol Extension	Change Controller	Specification
unknown_agent	token error response	Agent Checksum Grant	IETF	[this document],
agent_checksum_mismatch	token error response	Agent Checksum Grant	IETF	[this document],
workflow_step_unauthorized	token error response	Agent Checksum Grant	IETF	[this document],

This specification does not define any new media types. Agent identity verification and token issuance use existing media types:

• application/json (RFC 7159) - For token requests and responses
• application/jwt (RFC 7519) - For intent tokens

Summary of IANA registrations required by this specification: IANA Registration Summary

Registry	Number of Registrations
OAuth URI	1
JSON Web Token Claims	7
OAuth Parameters	7
OAuth Extensions Error Registry	3
TOTAL	18

Security Considerations This section describes Threat Model and Security Considerations similar to OAuth 2.0 .

The agent checksum is the primary security mechanism in this grant type. Implementations MUST:

• Use constant-time comparison when verifying checksums to prevent timing attacks
• Log all checksum mismatch events for security monitoring
• Consider implementing rate limiting on checksum verification failures to prevent brute-force attacks
• Reject checksums that don't match the expected format (sha256:<64 hex chars>)

SHA-256 provides 256-bit security against collision and preimage attacks. This is sufficient for agent identity purposes given:

• Checksums are not used for long-term secrets (only identity binding)
• Collision resistance prevents two different agents from having same checksum
• Preimage resistance prevents deriving agent config from checksum

Future versions of this specification MAY support alternative hash algorithms (e.g., SHA-3) through algorithm prefix versioning.

Agent registration endpoints MUST be protected with authentication and authorization to prevent:

• Unauthorized agents registering under legitimate agent_ids
• Denial of service through excessive registrations
• Checksum enumeration attacks

The reference implementation requires admin-level OAuth tokens with "register:intent" scope for registration endpoints.

The agent registry contains sensitive identity information and MUST be protected:

• Store checksums with access controls (only IDP can read)
• Encrypt registry data at rest
• Log all registry access for audit trails
• Implement rate limiting on registry queries
• Regularly backup registry with integrity verification

Intent tokens SHOULD have short lifetimes (5-10 minutes) because:

• They represent user intent for a specific workflow step
• Workflow state may change rapidly in multi-agent systems
• Short lifetime limits the window for token theft/replay

The reference implementation uses 5 minutes (300 seconds). But this value should be fully configurable.

The cnf (confirmation) claim with JWK binding provides proof-of-possession, preventing token theft. Resource servers SHOULD:

• Verify that API requests include proof of possession of the private key corresponding to the JWK in the cnf claim
• Reject tokens presented without valid proof-of-possession
• Use mechanisms like DPoP for proof-of-possession validation

Authorization servers MUST implement access controls on workflow definition endpoints. Only authenticated administrators with appropriate privileges SHOULD be able to create or modify workflow definitions. Implementations SHOULD validate workflow definitions for security properties such as: (1) no cycles in agent transitions, (2) appropriate scope restrictions at each step, (3) required approval gates for high-privilege operations.

Workflow step validation is critical for preventing privilege escalation. But is applicable only if enabled. Authorization servers MUST:

• Enforce prerequisite step completion before issuing tokens
• Verify approval gates have been passed for steps requiring approval
• Validate that the delegation_chain is consistent with the workflow definition
• Prevent agents from skipping required steps

The delegation_chain hash provides integrity over the agent delegation path. However, implementations SHOULD additionally:

• Maintain a server-side record of delegation chains
• Validate that each delegation was authorized
• Limit delegation depth to prevent infinite delegation chains
• Revoke all tokens in a delegation chain if a parent agent is compromised

Implementation Considerations

Cryptographic Requirements Implementations MUST use cryptographically secure hash functions for agent checksum computation. SHA-256 or stronger algorithms are REQUIRED. Weaker algorithms such as MD5 or SHA-1 MUST NOT be used. For proof-of-possession key binding, implementations MUST support EdDSA with Ed25519 curves or ECDSA with P-256 curves. RSA keys with minimum 2048-bit length MAY be supported for backward compatibility. Intent hash computation MUST use SHA-256 or stronger. The hash MUST be computed over the canonical JSON representation of the intent token to ensure consistent results across implementations.

Privacy Considerations Authorization servers and resource servers MUST implement appropriate data retention and deletion policies to minimize privacy risks. Token logging and audit trails SHOULD exclude sensitive user data when possible. If user data must be logged, implementations SHOULD use tokenization or anonymization techniques to protect privacy. Cross-border data transfers of tokens containing personal information MUST comply with applicable data protection regulations such as GDPR, CCPA, and similar frameworks.

Denial of Service Considerations The additional cryptographic operations required by this protocol (checksum computation, signature verification, hash computation) introduce potential denial of service attack vectors. Implementations SHOULD implement rate limiting on token endpoints. Authorization servers SHOULD monitor for patterns indicating DoS attacks, such as: (1) excessive token requests from single clients, (2) repeated failed checksum validations, (3) malformed token requests designed to trigger expensive validation operations. Resource servers MAY implement caching of validation results (with appropriate cache invalidation) to reduce computational overhead for repeated token validations.

Threat Analysis The following 12 distinct security threats across six STRIDE categories enumerated with their categorization and mitigation status in , have been used to demonstrate the need for this Agentic JWT protocol. Threat Enumeration and Mitigation Status

ID	Threat Name	STRIDE	OWASP	Mitigation
T1	Agent Identity Spoofing	Spoofing	A01:2021	A1, A2
T2	Token Replay Attacks	Spoofing	A02:2021	A6
T3	Shim Library Impersonation	Spoofing	A08:2021	A1, A2
T4	Runtime Code Modification	Tampering	A03:2021	A1, A12
T5	Prompt Injection Attacks	Tampering	LLM01:2025	A12
T6	Workflow Definition Tampering	Tampering	A04:2021	A8, A11
T7	Cross-Agent Privilege Escalation	Priv. Elev.	A01:2021	A3, A7, A8
T8	Workflow Step Bypass	Priv. Elev.	A01:2021	A8, A10
T9	Scope Inflation	Priv. Elev.	LLM06:2025	A7, A8
T10	Intent Origin Forgery	Repudiation	A09:2021	A9, A10
T11	Delegation Chain Manipulation	Repudiation	A02:2021	A6, A9
T12	Agent Configuration Exposure	Info. Disc.	A01:2021	A1, A2

OWASP categories referenced A01:2021 (Broken Access Control), A02:2021 (Cryptographic Failures), A03:2021 (Injection), A04:2021 (Insecure Design), A08:2021 (Software and Data Integrity Failures), A09:2021 (Security Logging and Monitoring Failures), LLM01:2025 (Prompt Injection) , LLM06:2025 (Excessive Agency) . Mitigation anchors (detailed in ): A1 (Agent Checksum Verification), A2 (Shim Library Integrity), A3 (Scope Binding), A6 (PoP Key Binding), A7 (Delegation Context), A8 (Workflow State Tracking), A9 (Intent Hash Binding), A10 (Step Authorization), A11 (IDP Access Control), A12 (Input Validation).

Threat Descriptions and Attack Vectors This section provides detailed descriptions of each identified threat, including attack vectors and real-world precedents. presents this information in tabular form. Threat Descriptions and Attack Vectors

ID	Description	Attack Vector
T1	A malicious agent impersonates a legitimate agent by replicating its identifier, source code structure, prompts, and tool configurations to create a malicious agent with identical checksum signatures.	Attacker gains access to agent source code (e.g., through repository compromise) and creates a malicious agent with identical checksum signatures.
T2	Intercepted intent tokens are replayed by unauthorized agents to gain access to protected resources.	Network interception or memory dumps expose valid intent tokens that are replayed before expiration.
T3	Malicious replacement of legitimate shim library with compromised version that bypasses security controls.	Supply chain compromise or local privilege escalation to replace shim library files.
T4	Agent prompts, tools, or configurations are modified at runtime after successful checksum registration.	Memory injection, debugger attachment, or reflection-based modification of agent properties.
T5	Malicious inputs cause LLM agents to generate unintended instructions that bypass security policies. , .	Crafted user inputs or external data sources containing prompt injection payloads that manipulate agent reasoning.
T6	Unauthorized modification of workflow definitions in the authorization server to permit unauthorized agent transitions.	Compromised administrative credentials or authorization server vulnerabilities allowing workflow redefinition.
T7	Lower-privilege agent manipulates higher-privilege agent to perform unauthorized operations beyond the original user intent.	Agent A with read-only permissions crafts requests that cause Agent B to execute destructive operations.
T8	Agents skip required approval steps or execute workflow steps out of sequence to gain unauthorized access.	Direct API calls bypassing workflow engine or manipulation of workflow state tracking.
T9	Agents request or utilize broader scopes than originally intended for the specific workflow step.	Token minting requests with inflated scopes or misuse of broad scopes for unintended operations.
T10	Unable to cryptographically prove which user intent led to specific agent actions, enabling plausible deniability.	Lack of cryptographic binding between user intent and downstream agent actions.
T11	Modification or forgery of delegation chains to hide true origin of agent actions.	Manipulation of delegation assertion claims or replay of valid delegation chains in unauthorized contexts.
T12	Unauthorized access to agent prompts, tools, and configurations leading to system knowledge disclosure.	API endpoints exposing agent metadata or memory dumps revealing agent configurations.

Security Anchors and Mitigation Mechanisms The Agentic JWT protocol employs twelve security anchors that collectively address all identified threats. describes each mitigation mechanism and the threats it addresses. Security Anchors and Mitigation Mechanisms

Anchor	Mechanism	Threats
A1	Agent Checksum Verification: Runtime checksum computation and verification against registered values	T1, T3, T4, T12
A2	Shim Library Integrity: Cryptographic validation of shim library authenticity	T1, T3, T12
A3	Scope Binding: Cryptographic binding of authorized scopes to specific workflow steps	T7, T9
A6	Proof-of-Possession Key Binding: Per-agent cryptographic keys bound to tokens	T2, T11
A7	Delegation Context Validation: Verification of delegation chain authenticity	T7, T9
A8	Workflow State Tracking: Authorization server maintains workflow execution state	T6, T7, T8
A9	Intent Hash Binding: Cryptographic binding of user intent to token lifecycle	T10, T11
A10	Step Authorization: Per-step authorization checks at resource servers	T8, T10
A11	Authorization Server Access Control: Protection of workflow definitions	T6
A12	Input Validation and Sanitization: Validation of agent inputs and LLM outputs	T4, T5

References National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology NIST NIST NIST NIST OWASP Foundation OWASP Foundation OWASP Foundation OWASP Foundation LangChain LangChain CrewAI Anthropic PBC Google pending To be updated with actual arXiv identifier after publication IANA IANA IANA IANA

Acknowledgements This work builds upon the foundational contributions of the OAuth working group and the broader internet security community.

Contributors

abhishek@abhishekgoswami.io