# Agentic Zero Trust Protocol (AZTP)
> Author: Frederick Kautz

## Status of this Memo
> Status: DRAFT
> Version: 2025-04-06

This document specifies an identity and chain-of-trust protocol standard for agentic systems across trust boundaries, and requests discussion and suggestions for improvements. Distribution of this document is unlimited.

## Abstract
Modern distributed systems increasingly employ AI agents and automated tools that need to interact across trust boundaries. Traditional authentication methods often fall short when dealing with multi-agent systems that require chained delegation of authority. The Agentic Zero Trust Protocol (AZTP) addresses this challenge by providing a standardized framework for authenticating and authorizing multiple agents and tools across trust boundaries.

AZTP leverages the SPIFFE framework for secure identity issuance and enables service function chaining similar to those found in network service providers. By utilizing X.509 certificates for direct connections via mutual TLS (mTLS) and JWT tokens for authenticating with systems beyond direct connections, AZTP creates a robust chain of trust that can span multiple organizational boundaries while maintaining zero trust principles.

[toc]

## 1. Introduction

As distributed systems grow more complex and involve multiple autonomous agents, traditional authentication methods become inadequate. Modern AI-driven systems often require multiple agents working together across organizational boundaries, with each agent needing to pass authentication information through a chain of services while maintaining a traceable chain of trust.

The Agentic Zero Trust Protocol (AZTP) addresses this challenge by providing a standardized framework for authenticating multiple agents and tools across trust boundaries. AZTP builds upon the SPIFFE (Secure Production Identity Framework for Everyone) standard and extends it to support service function chaining.

AZTP enables direct authentication between adjacent services using mutual TLS with X.509 certificates, while also supporting authentication across multiple service hops using chained JWT tokens. This dual approach provides both the security benefits of mTLS for direct connections and the flexibility to extend trust across multiple service boundaries through JWT token chaining.

In an AZTP chain, each service in the chain validates tokens from the previous service, adds its own authentication, and passes the combined tokens to the next service. This creates a verifiable chain of trust that allows services to make authorization decisions based on the full chain of agents involved in a request.

## 2. AZTP Architecture

AZTP is designed to support complex multi-agent interactions across trust boundaries while maintaining zero trust principles. The architecture consists of several key components:

1. **Identity Provider**: Each trust domain has its own identity provider (typically a SPIFFE implementation) that issues X.509 SVIDs for workloads within its domain.

2. **AZTP Agents**: Services that participate in the AZTP protocol, capable of:
- Authenticating directly to adjacent services using mTLS
- Creating, validating, and forwarding chained JWT tokens
- Adding their own authentication information to the token chain
- Validating the chain of trust in incoming requests

3. **Token Chain**: A sequence of nested JWT tokens that creates a verifiable chain of trust across multiple services.

4. **Trust Domain Federation**: Configuration that allows validation of identities from other trust domains.

The AZTP architecture supports both:

- **Linear Chains**: Where Service A calls Service B, which calls Service C, and so on.
- **Branching Chains**: Where a service might call multiple downstream services, each continuing their own chain.
- **Merging Chains**: Where multiple independent chains converge at a single service.

In all cases, the full chain of trust is maintained and can be validated by any service in the chain.

## 3. Identity and Authentication

### 3.1. SPIFFE Integration

AZTP leverages SPIFFE for identity management. Each participating service must have a valid SPIFFE ID assigned by its trust domain's identity provider. The SPIFFE ID MUST be formatted according to the [SPIFFE ID specification](https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md).

AZTP systems MUST implement the SPIFFE Workload API to obtain SVIDs and trust bundles. This ensures that workloads can securely obtain their identities and the validation material needed to verify identities from other trust domains.

### 3.2. Direct Authentication with X.509 SVIDs

For direct connections between adjacent services, AZTP requires mutual TLS authentication using X.509 SVIDs as defined in the [X.509 SVID specification](https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md). This provides:

1. **Strong Authentication**: Both parties authenticate to each other.
2. **Communication Security**: All traffic is encrypted.
3. **Identity Verification**: Each party can verify the SPIFFE ID of the other.

The X.509 SVIDs MUST include the SPIFFE ID as a URI type in the Subject Alternative Name extension, exactly as specified in the X.509 SVID specification.

### 3.3. Chained Authentication with JWT SVIDs

For authentication beyond directly connected services, AZTP uses JWT SVIDs as defined in the [JWT SVID specification](https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md), with additional requirements for token chaining.

JWT SVIDs in AZTP:
1. MUST include all required claims as specified in the JWT SVID specification
2. MUST include additional AZTP-specific claims as defined in [Token Chain](#4-Token-Chain)
3. MUST support token nesting to create the chain of trust

## 4. Token Chain
The core innovation of AZTP is the token chain mechanism, which allows authentication information to be passed through multiple services while maintaining a verifiable chain of trust.

### 4.0 MCP Integration

AZTP provides robust security for Model Context Protocol (MCP) tool communications. When AI agents use MCP to access tools across organizational boundaries, AZTP ensures:

1. **Secure Agent-to-Tool Authentication**: Each agent and tool has a SPIFFE identity, enabling strong mutual authentication through X.509 SVIDs for direct connections.

2. **Cross-Boundary Tool Chain**: When tools need to call other tools (potentially in different trust domains), the AZTP token chain creates a verifiable sequence of delegated authority.

3. **Token-Based Tool Authorization**: Tool invocations carry AZTP tokens that define clear capabilities and constraints, ensuring tools only perform authorized actions.

4. **Transparent Authorization Context**: MCP servers receive the complete chain of agent identities involved in a request, enabling better authorization decisions and audit trails.

5. **OAuth 2.1 Federation with Chain of Trust**: AZTP extends standard OAuth 2.1 flows by adding token chaining, allowing cross-boundary authentication while maintaining the chain of trust between agents and tools.

### 4.1. Token Structure

AZTP JWT tokens extend the standard JWT SVID with the following additional claims:

1. **`aztp_version`**: (Required) The version of the AZTP protocol (current version is "1.0").
2. **`aztp_prev_token`**: (Optional) Contains the entire JWT token from the previous service in the chain, encoded as a string.
3. **`aztp_path`**: (Required) An array of SPIFFE IDs representing the path the request has taken so far.
4. **`aztp_capabilities`**: (Required) An object describing the capabilities this token grants.
5. **`aztp_constraints`**: (Optional) An object describing any constraints on the use of this token.

### 4.2. Token Nesting

Token nesting is the key mechanism that enables AZTP's chain of trust. Each service in the chain:

1. Receives a token from the previous service (which may already contain nested tokens)
2. Validates the received token
3. Creates a new token containing:
- Its own identity information
- The entire previous token (nested in the `aztp_prev_token` claim)
- Updated `aztp_path` information
- Potentially attenuated capabilities

The nesting process creates a structure like this:

Token_C{
  sub: "spiffe://domain-c/service-c",
  aztp_prev_token: "Token_B{
    sub: "spiffe://domain-b/service-b",
    aztp_prev_token: "Token_A{
      sub: "spiffe://domain-a/service-a",
      aztp_path: ["spiffe://domain-a/service-a"],
      ...
    }",
    aztp_path: ["spiffe://domain-a/service-a", "spiffe://domain-b/service-b"],
    ...
  }",
  aztp_path: ["spiffe://domain-a/service-a", "spiffe://domain-b/service-b", "spiffe://domain-c/service-c"],
  ...
}

This structure allows any service to validate the entire chain of trust by recursively unwrapping the tokens and validating each one individually.

### 4.3. Token Validation

When a service receives an AZTP token, it MUST perform the following validation steps:

1. Validate the outermost token using standard JWT SVID validation procedures:
- Verify the signature using the appropriate trust bundle
- Check the expiration time
- Verify the audience claim
- Verify that the `aztp_version` is supported

2. Extract and decode the `aztp_prev_token` (if present)

3. Recursively validate each nested token until the entire chain is validated

4. Verify that the `aztp_path` in each token correctly reflects the chain of services

5. Validate capabilities and constraints to ensure the request is authorized

A validation failure at any point in the chain MUST result in rejection of the entire request.

## 5. Delegation of Authority

### 5.1. Delegation Constraints

AZTP allows services to specify constraints on how their tokens may be used in downstream services. Constraints are specified in the `aztp_constraints` claim and may include:

1. **`max_depth`**: The maximum number of additional services that may be added to the chain.
2. **`allowed_services`**: A list of SPIFFE IDs that are allowed to use this token.
3. **`forbidden_services`**: A list of SPIFFE IDs that are not allowed to use this token.
4. **`expiration`**: A timestamp after which the token becomes invalid (may be earlier than the JWT `exp` claim).
5. **`purpose`**: A string or array describing the intended purpose of the delegation.

Constraints MUST be enforced by each service in the chain. A service MUST NOT accept a token if it violates any constraints specified in the token chain.

### 5.2. Capability Attenuation

A key principle of AZTP is that services can attenuate capabilities as tokens are passed through the chain. Each service can reduce (but never expand) the capabilities granted by the previous token.

The `aztp_capabilities` claim specifies what actions the token authorizes. When creating a new token that includes a previous token, a service MUST ensure that the capabilities it grants are a subset of those granted by the previous token.

Capability attenuation ensures that even if a downstream service is compromised, it cannot escalate its privileges beyond what was explicitly delegated to it.

## 6. Security Considerations

### 6.1. Attack Vectors

AZTP addresses several common attack vectors:

1. **Token Forgery**: By using cryptographic signatures, AZTP ensures that tokens cannot be forged.

2. **Token Replay**: Proper use of the `exp` and audience claims mitigates replay attacks.

3. **Man-in-the-Middle Attacks**: Direct connections using mTLS prevent MITM attacks.

4. **Capability Escalation**: The constraint and capability attenuation mechanisms prevent escalation of privileges.

5. **Token Tampering**: The nested token structure ensures that any modification to the token chain will invalidate the signatures.

### 6.1.1. MCP-Specific Security Considerations

When using AZTP with the Model Context Protocol (MCP), additional security considerations include:

1. **Tool Identity Verification**: Each MCP tool MUST have a verifiable SPIFFE identity, enabling strong authentication and authorization decisions.

2. **Tool Invocation Authorization**: Tool calls MUST be authorized based on the capabilities in the AZTP token chain, preventing unauthorized tool access.

3. **Cross-Boundary Tool Call Protection**: When MCP tools call other tools across trust domain boundaries, the AZTP token chain MUST be propagated to maintain the chain of trust.

4. **MCP Content Protection**: Sensitive content returned by MCP tools MUST be protected according to the capabilities granted in the AZTP token chain.

5. **LLM Access Control**: AZTP tokens SHOULD specify what types of LLM operations tools are authorized to perform through the MCP protocol.

### 6.2. Mitigations

To further enhance security, AZTP implementations SHOULD:

1. Use short-lived tokens with aggressive expiration times
2. Implement rate limiting to prevent brute force attacks
3. Monitor and log all token validation failures
4. Regularly rotate signing keys
5. Implement strict network policies to limit direct connections to authorized services only
6. Use distributed tracing in conjunction with AZTP to detect abnormal request patterns

## 7. Implementation Guidelines

### 7.0. Cross-Boundary OAuth 2.1 Integration

AZTP extends traditional OAuth 2.1 to support secure cross-boundary authentication with chained trust. Implementations MUST support the following:

1. **OAuth 2.1 Compatibility**: AZTP tokens MUST be compatible with OAuth 2.1 flows while extending the standard with token chaining capabilities.

2. **Token Chain Propagation**: When an OAuth 2.1 token is obtained via AZTP, the entire token chain MUST be maintained and verifiable across boundaries.

3. **Chain Verification in Token Introspection**: OAuth 2.1 token introspection endpoints MUST be extended to support verification of the entire AZTP token chain.

4. **Discovery Integration**: OAuth 2.1's Authorization Server Metadata (RFC 8414) MUST be extended to indicate AZTP support, allowing clients to discover AZTP-compatible authorization servers.

5. **Client Registration Extensions**: OAuth 2.1 Dynamic Client Registration Protocol (RFC 7591) SHOULD be extended to support registration of clients with AZTP capabilities.

6. **Cross-Domain Authorization**: Resources in one trust domain MUST be able to validate AZTP-enhanced OAuth 2.1 tokens from another trust domain through the established trust relationships.

7. **Human and Non-Human Identities**: The authorization flow MUST support both human users and autonomous agents, with appropriate consent and authorization mechanisms for each.

### 7.1. Trust Domain Configuration

Each trust domain participating in AZTP MUST:

1. Implement a SPIFFE identity provider capable of issuing X.509 and JWT SVIDs
2. Configure trust domain federation with all other trust domains it needs to communicate with
3. Maintain and distribute up-to-date CA bundles for validating SVIDs from federated domains
4. Define clear policies for what capabilities can be delegated to external services

### 7.2. Agent Integration

Services implementing AZTP MUST:

1. Obtain their X.509 SVID from the SPIFFE Workload API
2. Implement mTLS for all direct connections
3. Validate incoming AZTP tokens according to the validation procedures in section 4.3
4. Create properly nested tokens when calling downstream services
5. Enforce all constraints and capability attenuations
6. Implement proper error handling for token validation failures

### 7.3. Service Integration

To integrate existing services with AZTP:

1. **Sidecar Pattern**: Use a sidecar proxy to handle AZTP authentication on behalf of the service
2. **Library Integration**: Incorporate AZTP client libraries directly into the service
3. **API Gateway**: Use an API gateway that implements AZTP to authenticate incoming requests

All integration approaches MUST ensure that the service has access to the validated SPIFFE IDs of all services in the chain to make proper authorization decisions.

### 7.4. MCP Tool Integration

To integrate Model Context Protocol (MCP) tools with AZTP:

1. **Tool Identity**: Each MCP tool MUST be assigned a SPIFFE ID that identifies it within its trust domain.

2. **Tool Authentication**:
- Direct tool-to-client connections MUST use X.509 SVIDs for mTLS authentication
- Cross-boundary tool chains MUST use AZTP token chains for authorization

3. **Tool Authorization**:
- Tool capabilities MUST be expressed in the `aztp_capabilities` claim
- Tools MUST verify that requesters have appropriate capabilities before executing operations
- Authorization decisions MUST consider the entire token chain

4. **OAuth-MCP Bridge**:
- MCP tools SHOULD leverage AZTP's OAuth 2.1 extensions for authorization server discovery and token exchange
- OAuth scopes SHOULD be mapped to AZTP capabilities for consistent authorization

5. **LLM Access Control**:
- AZTP tokens MUST specify which LLM operations are permitted
- Access to sensitive LLM features MUST be controlled through capability attenuation
- Sampling operations initiated by MCP servers MUST be authorized through the AZTP token chain

## 8. Conclusion

The Agentic Zero Trust Protocol (AZTP) provides a standardized framework for authenticating and authorizing multiple agents and tools across trust boundaries. By leveraging SPIFFE for identity and extending it with token chaining mechanisms, AZTP enables secure service function chaining while maintaining zero trust principles.

AZTP is particularly valuable for AI agent ecosystems, microservice architectures that span multiple trust domains, and any system where authentication needs to be maintained across multiple service hops.

The protocol's integration with the Model Context Protocol (MCP) adds robust security for AI agent tool communication, ensuring that all tool invocations across organizational boundaries maintain a verifiable chain of trust. By extending OAuth 2.1 with token chaining capabilities, AZTP also provides a standards-based approach for cross-boundary authentication that works with existing identity infrastructure.

By implementing AZTP, organizations can enable secure collaboration between autonomous agents while maintaining control over what actions those agents can perform and which services they can access, regardless of organizational or trust boundaries.

## Appendix A. AZTP JWT Claims Reference

| Claim | Type | Required | Description |
|-------|------|----------|-------------|
| `aztp_version` | string | Yes | AZTP protocol version (e.g., "1.0") |
| `aztp_prev_token` | string | No* | The entire JWT token from the previous service (required for all but the first service in a chain) |
| `aztp_path` | array of strings | Yes | Ordered array of SPIFFE IDs representing the path of the request |
| `aztp_capabilities` | object | Yes | Object describing the capabilities granted by this token |
| `aztp_constraints` | object | No | Object describing constraints on the use of this token |

In addition to these AZTP-specific claims, all the required claims from the JWT SVID specification MUST also be included:
- `sub`: The SPIFFE ID of the service issuing the token
- `aud`: The intended audience(s) for the token
- `exp`: The expiration time of the token

## Appendix B. Example Implementation

Below is a simplified example of how a token chain might be created and validated in an implementation:

### Creating a Token Chain

Service A creates the initial token:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-id-a"
}
{
  "sub": "spiffe://domain-a/service-a",
  "aud": "spiffe://domain-b/service-b",
  "exp": 1632128000,
  "aztp_version": "1.0",
  "aztp_path": ["spiffe://domain-a/service-a"],
  "aztp_capabilities": {
    "read": ["resource1", "resource2"],
    "write": ["resource1"]
  }
}

Service B validates the token from A, then creates a new token to send to C:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-id-b"
}
{
  "sub": "spiffe://domain-b/service-b",
  "aud": "spiffe://domain-c/service-c",
  "exp": 1632127900,
  "aztp_version": "1.0",
  "aztp_prev_token": "eyJhbGci...[full token from A]",
  "aztp_path": ["spiffe://domain-a/service-a", "spiffe://domain-b/service-b"],
  "aztp_capabilities": {
    "read": ["resource1"],
    "write": []
  },
  "aztp_constraints": {
    "max_depth": 1,
    "purpose": "data-processing"
  }
}

Service C validates the entire chain before processing the request.

### Validating a Token Chain

1. Service C validates the token from B using B's public key
2. Service C extracts the `aztp_prev_token` claim from B's token
3. Service C validates the token from A using A's public key
4. Service C verifies that the `aztp_path` is consistent across all tokens
5. Service C checks that all constraints are satisfied
6. If all validations pass, Service C processes the request with the capabilities specified in B's token

## Appendix C. Protocol Limitations

While AZTP provides a robust solution for agentic authentication across trust boundaries, implementers should be aware of its limitations:

1. **Performance Impact**: The nested token structure increases token size with each hop, which may impact performance for very long chains.

2. **Implementation Complexity**: Proper implementation requires careful handling of token validation, capability attenuation, and error cases.

3. **Trust Domain Federation**: For AZTP to work across organizational boundaries, trust domain federation must be properly configured.

4. **Token Size Limits**: Some systems may impose limits on header sizes, which could be exceeded by deeply nested tokens.

5. **Key Management**: Proper key rotation and distribution is essential for security but adds operational complexity.

Implementers should carefully consider these limitations and design their systems accordingly, possibly using token compression, partial chain validation, or other optimizations for specific use cases.