]> CyberSecAI Ltd

contact@agentsign.dev

agent trust transport AI MCP payments signing identity This document specifies the Agent Trust Transport Protocol (ATTP), a protocol-agnostic framework for trust scoring, cryptographic identity, action-limit enforcement, compliance gating, and tamper-evident audit for autonomous AI agents. ATTP separates trust from identity. Identity protocols answer "who is this agent?" ATTP answers "should this agent be allowed to perform this action, at this magnitude, against this counterparty, right now?" The protocol defines five progressive trust levels (L0-L4), per-agent ECDSA P-256 cryptographic identity, a five-dimension behavioural trust scoring model, action-limit tiers derived from trust scores, real-time compliance gating (sanctions screening, jurisdictional controls), kill switches for instant revocation, anomaly detection for agent behaviour, and a public trust query API. ATTP is transport-agnostic. This document defines the core framework. Protocol-specific bindings map ATTP trust enforcement to individual transports: MCPS provides the binding for the Model Context Protocol (MCP), with additional bindings defined for REST APIs, Google A2A, gRPC, GraphQL, and SPIFFE/SPIRE. This specification supersedes draft-sharif-agent-payment-trust-00, broadening the scope from payment transactions to any agent action requiring trust-gated authorisation, and consolidates the parallel draft-sharif-attp-agent-trust-transport-00 into a single ATTP lineage.

Introduction

The Trust Gap The emergence of autonomous AI agents that discover resources at runtime, execute multi-step tasks across trust domains, and take consequential actions without human oversight creates a security gap that identity protocols alone cannot close. Authentication answers a binary question: is this agent who it claims to be? The answer is yes or no. But consequential actions -- financial transactions, data access, infrastructure changes, contract execution -- require graduated assessment:

• Has this agent earned the right to perform actions of this magnitude?
• Does this agent's behavioural history justify the level of trust required?
• Is the counterparty cleared for this interaction (sanctions, jurisdictional compliance)?
• Can this agent be stopped instantly if something goes wrong?
• Is there a tamper-evident record of every action for audit?

Identity is necessary but not sufficient. ATTP provides the trust layer that sits above identity and below application logic.

Relationship to Identity Protocols ATTP is not an identity protocol and not a Privileged Access Management (PAM) replacement. It is a trust-decision and action-governance layer for autonomous agents, designed to compose with identity and transport-security mechanisms such as OIDC, mTLS, SPIFFE/SPIRE, and HTTP Message Signatures, and with protocol bindings such as REST and A2A. ATTP does not replace identity protocols. It consumes identity assertions from any standards-compliant source:

• OAuth 2.0 / OpenID Connect tokens (RFC 6749, OpenID Core)
• X.509 certificates (RFC 5280)
• HTTP Message Signatures (RFC 9421)
• Self-issued cryptographic identities (JWKS-based)
• Keycloak, Azure AD, Okta, or any OIDC-compliant provider

ATTP requires proof that an agent is who it claims to be. It does not prescribe how that proof is obtained. Once identity is established, ATTP evaluates trust, enforces limits, gates compliance, and records the decision.

Relationship to Existing Specifications This specification is part of a three-layer stack: +---------------------------------------------+ | AEBA (Behavioural Analytics) | | draft-sharif-aeba | | Anomaly detection, ML-based monitoring | +---------------------------------------------+ | ATTP (Trust Transport) [this document] | | draft-sharif-attp | | Trust scoring, limits, compliance, audit | +---------------------------------------------+ | MCPS (MCP Secure) | | draft-sharif-mcps-secure-mcp | | Message signing for MCP transport | +---------------------------------------------+ MCPS provides message-level cryptographic security for the Model Context Protocol. ATTP provides the trust framework that MCPS (and other transport bindings) enforce. AEBA provides behavioural analytics that feed into ATTP trust scoring.

Relationship to Other IETF Work The IETF agent-identity and delegation space is active. ATTP is the trust-decision and action-governance layer ABOVE these mechanisms; it composes with them rather than replacing them. Workload identity for agents is addressed by the WIMSE architecture and by composition guidance such as , which combines workload identity, OAuth, and shared signals. ATTP consumes such identities; the SPIFFE/SPIRE binding in this document is one such integration. Delegation and on-behalf-of semantics are provided by OAuth 2.0 Token Exchange (the "act" and "may_act" claims), the actor-chain profiles in , and capability attenuation in , which covers delegation depth, intent binding, and monotonic scope attenuation. ATTP evaluates these delegation chains as inputs to a trust decision; it does not define a competing delegation format. Pre-action signed authorisation with live risk assessment is explored in . ATTP's action signing and trust scoring address the same need and can interoperate with such receipts. ATTP's distinct contribution is the graduated trust model (L0-L4), action-limit enforcement, compliance gating, kill switches, and tamper-evident audit applied on top of whichever identity and delegation mechanisms a deployment already uses.

Design Goals

1. Transport-agnostic. ATTP defines trust semantics, not wire format. Protocol bindings map ATTP to specific transports.
2. Identity-agnostic. ATTP consumes identity from any source. It does not compete with any identity protocol -- OAuth, OIDC, mTLS, SPIFFE, HTTP Message Signatures, or future standards.
3. Graduated trust. Binary identity is insufficient. Five trust levels (L0-L4) with associated action limits provide proportional authorisation.
4. Fail-closed. If trust cannot be evaluated, the default is deny. No silent degradation.
5. Instant revocation. Kill switches take effect on the next request. No waiting for certificate expiry or CRL refresh.
6. Compliance-native. Sanctions screening and jurisdictional controls are built into the protocol, not bolted on.
7. Self-hostable. The Trust Authority has no external service dependency. Operators run their own instance.
8. Auditable. Every trust decision produces a tamper-evident record with hash-chain integrity.

Terminology 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 RFC2119 when, and only when, they appear in all capitals, as shown here. Agent: An autonomous software entity that performs actions on behalf of a principal (human or organisation) via standardised protocols. Actions include but are not limited to: financial transactions, data queries, tool invocations, infrastructure changes, and contract execution. Principal: The human or organisational entity accountable for an agent's actions. Trust Authority (TA): The service that maintains agent registrations, computes trust scores, evaluates compliance gates, enforces action limits, and records audit entries. The TA is self-hostable with no external dependency. Trust Score: A numerical value (0-100) representing the assessed trustworthiness of an agent based on multiple behavioural dimensions. Trust Level: A discrete classification (L0-L4) derived from the trust score, with associated action limits. Action: Any operation an agent requests that requires trust evaluation. Actions are protocol-specific: a payment in Stripe, a tool call in MCP, an API request in REST, a task in A2A. Action Limit: A constraint on the magnitude or frequency of actions an agent may perform at a given trust level. Kill Switch: A per-agent or per-principal flag that, when activated, causes immediate denial of all actions regardless of trust level. Compliance Gate: A check performed before action execution that evaluates regulatory constraints (sanctions lists, jurisdictional rules, embargo lists). Protocol Binding: A specification that maps ATTP trust enforcement to a specific transport protocol (MCP, REST, A2A, gRPC, GraphQL). Agent Passport: A cryptographically signed identity document containing the agent's public key hash, principal identity, authorised scope, trust level, and issuance metadata.

Agent Identity

Key Pair Generation Each agent MUST have a unique ECDSA key pair using the P-256 curve . Key pairs MAY be generated by the Trust Authority and provided to the principal (the private key MUST be returned exactly once and MUST NOT be stored by the Trust Authority), or generated by the principal and the public key registered with the Trust Authority (RECOMMENDED for production deployments). Implementations MUST support ECDSA P-256 (ES256). Implementations MAY additionally support Ed25519 (EdDSA) for environments where P-256 is not available.

Public Key Registration The principal MUST register the agent's public key with the Trust Authority at agent creation time. The Trust Authority stores ONLY the public key. The private key MUST remain under the principal's control at all times. For production deployments, the private key SHOULD be stored in a Hardware Security Module (HSM), cloud Key Management Service (KMS), or platform-native secure storage.

Agent Passport Upon registration, the Trust Authority issues an Agent Passport -- a signed JSON document containing:

• agentId: Unique identifier for the agent.
• publicKeyHash: SHA-256 hash of the agent's public key, binding the passport to a specific key pair.
• principalId: Identifier of the owning principal.
• scope: Array of authorised action categories.
• trustLevel: Current trust level (L0-L4).
• issuedAt: ISO 8601 timestamp of issuance.
• expiresAt: ISO 8601 timestamp of expiry.
• issuer: Identifier of the Trust Authority.
• protocolVersion: ATTP version (this document: "1.0").

The passport is signed by the Trust Authority's key using ECDSA P-256. The signature covers the JSON Canonicalization Scheme (JCS) serialisation of the passport fields. Passports MUST expire. Maximum lifetime MUST NOT exceed 365 days. RECOMMENDED lifetime is 90 days for L0-L2 agents and 180 days for L3-L4 agents.

Key Rotation Agents MUST support key rotation without identity loss. When rotating keys:

1. The principal generates a new key pair.
2. The principal registers the new public key with the TA.
3. The TA issues a new passport binding the agentId to the new public key.
4. The old key enters a grace period (RECOMMENDED: 24 hours) during which both keys are accepted.
5. After the grace period, the old key is revoked.

Key rotation MUST NOT reset the agent's trust score.

Challenge-Response Identity Verification When a platform needs to verify an agent's identity before granting access, it uses the following challenge-response protocol.

Challenge Issuance The platform (or TA on behalf of the platform) generates a challenge:

• challenge: 32 bytes of cryptographically random data, hex-encoded (64 characters).
• expiresAt: Timestamp, MUST be no more than 60 seconds from issuance.
• agentId: The agent for which the challenge is issued.

Each challenge MUST be single-use. The TA MUST reject any attempt to verify a challenge that has already been used.

Challenge Signing The agent signs the challenge using its private key: signature = ECDSA-Sign(SHA-256(challenge), agentPrivateKey) The signature uses IEEE P1363 fixed-length r||s encoding (64 bytes for P-256) per RFC 7518 Section 3.4.

Signature Verification The TA verifies the signature using the agent's registered public key. If valid, the TA returns the agent's current trust score, level, and recommendation.

Failure Handling If verification fails:

• The TA MUST log the failure as a potential impersonation attempt.
• The agent's trust score MUST be penalised (RECOMMENDED: -10 points per failed attempt).
• The response MUST include an error code: IMPERSONATION, CHALLENGE_EXPIRED, CHALLENGE_REPLAYED, or AGENT_MISMATCH.

Trust Scoring Model

Scoring Dimensions The trust score is computed from five dimensions:

1. Code Attestation (CA): Whether the agent's code or configuration has been cryptographically verified against its declared specification.
2. Execution Success Rate (ES): The proportion of the agent's past actions that completed without anomaly, dispute, or reversal.
3. Behavioural Consistency (BC): The statistical consistency of the agent's action patterns relative to its established baseline.
4. Operational Tenure (OT): The duration the agent has been registered and actively operating.
5. Anomaly History (AH): The inverse of the count and severity of detected anomalies.

Dimension Weights Each dimension contributes 20% to the overall score: W_CA = W_ES = W_BC = W_OT = W_AH = 0.20 Implementations MAY adjust weights provided the sum equals 1.0 and no single dimension exceeds 0.40.

Score Computation raw = (CA * W_CA) + (ES * W_ES) + (BC * W_BC) + (OT * W_OT) + (AH * W_AH) Each dimension value is in the range [0, 100]. score = clamp(raw + bonus + dormancy, 0, 100)

Trust Levels +--------+--------+-------------------+------------------+ | Level | Score | Label | Payment Enabled | +--------+--------+-------------------+------------------+ | L0 | 0-19 | No Access | No | | L1 | 20-39 | Restricted | Micro only | | L2 | 40-59 | Standard | Yes | | L3 | 60-79 | Elevated | Yes (monitored) | | L4 | 80-100 | Full Access | Yes (audited) | +--------+--------+-------------------+------------------+ No trust level SHALL have unlimited action authority. L4 represents the maximum tier with mandatory enhanced auditing.

Dynamic Adjustment The trust score adjusts dynamically based on observed behaviour:

• Successful action: +0.5 trust bonus.
• Blocked action (over limit): -2 trust bonus.
• Anomaly detected: -5 per anomaly.
• Critical anomaly (3+ simultaneous): -20 trust bonus.
• Failed identity verification: -10 trust bonus.
• Probing detected: -15 trust bonus.

Self-dealing actions (agent-to-agent within the same principal) MUST earn zero trust bonus.

Dormancy Decay Agents inactive for extended periods MUST have their trust score reduced:

• 30 days inactive: -10 penalty.
• 60 days inactive: -20 penalty.
• 90+ days inactive: -30 penalty.

The dormancy penalty is removed when the agent resumes activity.

Promotion Rate Limiting Trust level promotions MUST be rate-limited to prevent trust farming attacks:

• L0 to L1: Minimum 24 hours at L0 with at least 5 successful actions.
• L1 to L2: Minimum 7 days at L1 with at least 20 successful actions.
• L2 to L3: Minimum 30 days at L2 with at least 100 successful actions and zero critical anomalies.
• L3 to L4: Minimum 90 days at L3 with at least 500 successful actions, zero anomalies, and manual principal attestation.

Demotions are instant. A single critical anomaly at L4 drops the agent to L2 immediately.

Action Limit Enforcement

Per-Action Limits Each action MUST be checked against the per-action limit of the agent's current trust level. Actions exceeding the limit MUST be rejected with error code ATTP-ACTION-LIMIT. Action limits are protocol-binding-specific. For financial transactions: +--------+------------------+------------------+ | Level | Per-TX Limit | Daily Limit | +--------+------------------+------------------+ | L0 | $0 | $0 | | L1 | $10 | $50 | | L2 | $100 | $500 | | L3 | $1,000 | $5,000 | | L4 | $50,000 | $200,000 | +--------+------------------+------------------+ For non-financial actions, protocol bindings define equivalent limits (e.g., API calls per minute, data volume per request).

Daily Aggregate Limits The TA MUST track daily aggregate action magnitude per agent within a rolling 24-hour window.

Principal Aggregate Limits To prevent Sybil attacks (creating many agents to circumvent per-agent limits), the TA MUST enforce aggregate limits per principal across all their agents.

Cooling Period After a trust level promotion, the agent MUST operate under the previous level's limits for a cooling period (RECOMMENDED: 24 hours) before the new limits take effect.

Kill Switches

Per-Agent Kill Switch Each agent MUST have an independently controllable kill switch. When activated:

• ALL actions by the agent are denied immediately.
• The denial takes effect on the next request (no grace period).
• The agent's trust score is frozen (not reset).
• The kill switch state is recorded in the audit trail.

Reactivation requires explicit principal action and MUST NOT be automated.

Per-Principal Kill Switch Each principal MUST have a kill switch that simultaneously disables ALL agents under their control.

Emergency Freeze The TA MUST support an emergency freeze that disables all agents across all principals. This is intended for infrastructure-level incidents. Emergency freeze MUST require multi-party authorisation (RECOMMENDED: two independent operators).

Compliance Gating

Compliance Gate Interface ATTP defines a compliance-gate interface, not a specific compliance regime. Before executing a consequential action, the TA MUST evaluate the action against the configured set of compliance gates and MUST block the action if any gate denies it. Each gate is a pluggable policy that returns allow, deny, or review for a given action and its parties. A deployment selects the gates appropriate to its jurisdiction and use case. Gates MAY be chained; a deny from any gate blocks the action with an error code identifying the gate (for example, ATTP-GATE-DENY).

Sanctions Screening (Example Gate) Sanctions screening is a common compliance gate but is NOT mandated by this protocol, as applicable lists are jurisdiction-specific. A deployment subject to sanctions regulation SHOULD configure a sanctions gate that screens the relevant parties against the lists applicable to it (for example, OFAC SDN, EU Consolidated, UK HMT, or UN Security Council lists). A sanctions gate SHOULD use fuzzy matching with a configurable threshold (RECOMMENDED: 70% match score), block matches at or above the threshold, and keep its lists current (RECOMMENDED: at least daily updates).

Jurisdictional Controls Actions MAY be restricted based on the jurisdiction of the agent, the principal, or the counterparty. The TA SHOULD support configurable jurisdiction rules, expressed as compliance gates.

Compliance Record Every compliance-gate evaluation MUST produce an audit record containing: the query, the gates evaluated, the results (including near-misses), and the decision. Compliance records MUST be retained for the period required by applicable regulation (RECOMMENDED minimum: 5 years).

Anomaly Detection

Magnitude Anomaly An action whose magnitude exceeds 3 standard deviations from the agent's historical mean MUST be flagged.

Velocity Anomaly An action rate exceeding 2x the agent's historical maximum within any 5-minute window MUST be flagged.

Temporal Anomaly Actions outside the agent's established operating hours (based on 90-day history) SHOULD be flagged.

Counterparty Anomaly Actions directed at counterparties with which the agent has no prior history, when combined with elevated magnitude, MUST be flagged.

Probing Anomaly A pattern of incrementally increasing action magnitudes (e.g., $1, $5, $10, $50, $100) within a short window indicates probing behaviour and MUST trigger a -15 trust penalty and flag the agent for review.

Self-Dealing Detection Actions between agents belonging to the same principal MUST earn zero trust bonus and SHOULD be flagged if they exceed 10% of the agent's total action volume.

Public Trust Query API

Request Format Any platform MAY query the TA for an agent's trust status: GET /v1/trust/{agentId} The TA MUST support this query without requiring a pre-existing relationship with the querying platform.

Response Format { "agentId": "agent_abc123", "trust": { "score": 67, "level": 3, "label": "L3 -- Elevated" }, "recommendation": "ALLOW", "limits": { "perAction": 100000, "daily": 500000 }, "identity": { "verified": true, "principalId": "dev_xyz", "jurisdiction": "GB" }, "meta": { "protocolVersion": "1.0", "queriedAt": "2026-04-30T22:00:00Z", "checkedBy": "CyberSecAI Trust Authority" } }

Batch Queries The TA MUST support batch queries for efficiency: POST /v1/trust/batch { "agentIds": ["agent_1", "agent_2", "agent_3"] } Maximum batch size: 100 agents.

Rate Limiting The TA MUST rate-limit trust queries:

• Anonymous queries: 120 per minute per IP.
• Authenticated queries: 600 per minute per API key.

Information Disclosure Controls The public trust API MUST NOT expose:

• Raw scoring dimension values.
• Transaction history or action details.
• Private key material or key fingerprints.
• Internal anomaly thresholds.

The API provides trust level, recommendation, and limits only.

Action Signing and Receipts

Action Envelope Every action processed through ATTP produces a signed envelope: { "actionId": "act_unique_id", "agentId": "agent_abc123", "action": "payment_initiate", "magnitude": 5000, "counterparty": "recipient_name", "trustLevel": 3, "complianceResult": "CLEAR", "timestamp": "2026-04-30T22:00:00Z", "signature": "ECDSA signature over canonical JSON" } The signature covers the JCS serialisation of all fields except the signature field itself.

Hash Chain Action envelopes are linked in a hash chain: The genesis hash is SHA-256("ATTP-GENESIS"). Breaking the hash chain indicates tampering. The TA MUST verify chain integrity on every append.

Cryptographically Attributable Receipts After successful action execution, the TA issues a receipt signed by the TA's key. The receipt includes:

• The action envelope.
• The TA's signature over the envelope.
• The hash chain position.
• The compliance check result.

Receipts are cryptographically attributable: they prove that a specific key signed a specific envelope at a specific position in the hash chain. This is an evidentiary property, not a legal assertion of intent or consent. A valid signature demonstrates that the holder of the key produced it; it does not, by itself, establish that the action was authorised by a human, free of coercion, or produced on an uncompromised host. Establishing intent or consent is out of scope for this document and, where required, MUST be provided by an additional mechanism (for example, a human-presence attestation bound to the action).

Protocol Bindings ATTP is transport-agnostic. Protocol bindings map ATTP trust enforcement to specific transports.

MCP Binding (MCPS) The MCP binding is specified in draft-sharif-mcps-secure-mcp. MCPS wraps JSON-RPC messages in signed envelopes carrying ATTP trust claims. Trust level is conveyed in the MCPS envelope header. Action limits map to tool call parameters (amount, scope). Kill switch state is checked before tool execution.

REST Binding For REST APIs, ATTP trust is conveyed via HTTP headers: X-ATTP-Trust-Level: 2 X-ATTP-Agent-Id: agent_abc123 X-ATTP-Signature: base64-encoded ECDSA signature X-ATTP-Nonce: 550e8400-e29b-41d4-a716-446655440000 X-ATTP-Timestamp: unix epoch ms The signature covers: method, path, body hash (SHA-256), nonce, and timestamp.

Google A2A Binding For the Agent2Agent protocol, ATTP trust is embedded in the Task metadata. The agent's AgentCard includes ATTP trust level and TA endpoint in its capabilities declaration.

gRPC Binding For gRPC, ATTP trust is conveyed via metadata headers using the same header names as the REST binding.

GraphQL Binding For GraphQL, ATTP trust is conveyed via HTTP headers (same as REST) or via an extensions field in the GraphQL request: { "query": "...", "extensions": { "attp": { "trustLevel": 2, "agentId": "agent_abc123", "signature": "...", "nonce": "...", "timestamp": 1234567890 } } }

Keycloak Integration For enterprises using Keycloak or other OIDC providers, ATTP trust claims are embedded in the JWT access token as a nested "attp" claim: { "sub": "agent_abc123", "attp": { "trust_level": 2, "trust_label": "L2 -- Standard", "payment_enabled": true, "tx_limit": 10000, "day_limit": 50000, "scopes": "payment_initiate,sanctions_screen", "protocol_version": "1.0" } } A Keycloak protocol mapper implements the role-to-trust-level mapping (mcps-l0 through mcps-l4 roles).

SPIFFE/SPIRE Binding For workloads with a SPIFFE identity, the SPIFFE ID serves as the ATTP agentId and the X.509-SVID provides the identity credential. SPIFFE/SPIRE supplies issuance, attestation, and automatic rotation of the workload identity; ATTP layers per-action evidence, trust level, action limits, and kill-switch enforcement on top. The agentId is the workload's SPIFFE ID: spiffe://example.org/agent/payments carried as the single URI SAN of the X.509-SVID. ATTP action envelopes are signed with the SVID's associated private key (ECDSA P-256). The signature covers the action canonical form (action, scope, body hash, nonce, timestamp) as in the REST binding; the SVID leaf certificate is presented with the envelope so the verifier can authenticate the signer against the SPIFFE trust bundle. The SVID's private key MAY be held in software, or in a hardware security module, Trusted Platform Module, or secure element; the binding is agnostic to key custody. Where the key is hardware-held, the SVID binds the SPIFFE ID to the hardware public key and signatures are produced by the hardware, providing a non-extractable, hardware-rooted identity without changing the binding. Trust level is conveyed alongside the SVID-authenticated identity in the envelope header (X-ATTP-Trust-Level, as in the REST binding). This composes with external authorization: an isolated policy decision point -- for example one expressed in a policy language such as Cedar or Open Policy Agent -- MAY consume the verified SPIFFE identity together with the ATTP trust level as an input attribute when authorizing an action. SPIFFE/SPIRE answers "which workload"; ATTP answers "what the workload did, with what evidence, and whether it is trusted to take this action". The two are complementary layers, not alternatives.

Revocation

Agent Revocation An agent MAY be revoked by the principal or by the TA. Revocation is immediate (kill switch) and permanent until explicitly reversed. Revocation MUST:

• Set the kill switch.
• Invalidate the current passport.
• Record the revocation in the audit trail.
• Optionally notify dependent platforms via webhook.

Emergency Freeze The TA MUST support emergency freeze of individual agents, all agents under a principal, or all agents globally. Global freeze MUST require multi-party authorisation.

Security Considerations

Key Management Private keys MUST be stored in HSM, KMS, or platform-native secure storage for production deployments. Private keys MUST NOT be transmitted over network channels after initial generation. The TA MUST NOT store agent private keys.

Trust Farming Mitigation ATTP mitigates trust farming through:

• Promotion rate limiting (Section 6.8).
• Self-dealing detection (Section 9.6).
• Principal aggregate limits (Section 7.3).
• Dormancy decay (Section 6.7).

An attacker who creates agents and performs small successful actions to build trust is limited by the minimum time at each level (24 hours, 7 days, 30 days, 90 days) and the minimum action counts. Reaching L4 requires at minimum 128 days of sustained operation with zero anomalies.

Sybil Attack Prevention Principal aggregate limits prevent circumvention of per-agent limits through agent proliferation. The TA SHOULD implement additional heuristics: common IP addresses, identical behavioural patterns, coordinated action timing.

Impersonation Detection Failed challenge-response verifications trigger trust penalties and audit entries. Three consecutive failures SHOULD trigger automatic agent suspension pending principal review.

Race Condition Handling Concurrent action requests MUST be serialised at the limit enforcement layer. Implementations MUST use atomic compare-and-swap operations for daily aggregate tracking.

Replay Protection Action envelopes include nonce and timestamp. The TA MUST reject any envelope with a previously-seen nonce or a timestamp outside the acceptable window (RECOMMENDED: 5 minutes).

Kill Switch Consistency Kill switch state MUST be checked atomically with action evaluation. There MUST be no window between trust check and action execution during which a kill switch activation could be missed.

Comparison with Identity-Only Protocols Identity protocols (OAuth 2.0, OIDC, mTLS, HTTP Message Signatures, or any future agent identity standard) establish who an agent is. They do not:

• Score agent trustworthiness based on behavioural history.
• Enforce graduated action limits tied to trust levels.
• Screen counterparties against sanctions lists.
• Provide instant kill switches independent of credential lifecycle.
• Produce tamper-evident audit chains for regulatory compliance.

ATTP is designed to compose with identity protocols, not replace them. An identity assertion is a prerequisite for ATTP trust evaluation.

Privacy Considerations The public trust query API reveals that an agent exists and its current trust level. This is intentional -- platforms need this information to make access decisions. The API MUST NOT reveal:

• Action history or patterns.
• Scoring dimension breakdowns.
• Counterparty information.
• Key material.
• Principal identity (unless the principal opts in).

Implementations SHOULD support pseudonymous agent identifiers that are unlinkable across platforms unless the principal explicitly enables cross-platform linking.

IANA Considerations This document defines the following HTTP headers for the REST protocol binding:

• X-ATTP-Trust-Level
• X-ATTP-Agent-Id
• X-ATTP-Signature
• X-ATTP-Nonce
• X-ATTP-Timestamp

Registration of these headers in the IANA Message Headers registry is requested. This document defines the following error codes:

• ATTP-ACTION-LIMIT
• ATTP-SANCTIONS-MATCH
• ATTP-TRUST-INSUFFICIENT
• ATTP-KILL-SWITCH-ACTIVE
• ATTP-NONCE-REPLAY
• ATTP-TIMESTAMP-EXPIRED

This document defines the following well-known URI:

• /.well-known/attp-trust

For discovery of Trust Authority endpoints.

References

Normative References

• Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
• Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020.
• National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-5, 2023.

Informative References

• Sharif, R., "MCPS: Cryptographic Security Layer for the Model Context Protocol", draft-sharif-mcps-secure-mcp-00, March 2026.
• Sharif, R., "AEBA: Agent Event Behaviour Analytics", draft-sharif-aeba-00, April 2026.
• OWASP, "AI Security Verification Standard", 2026.
• Backman, A., Richer, J., and M. Sporny, "HTTP Message Signatures", RFC 9421, February 2024.
• Google, "Agent2Agent Protocol", 2025.
• Anthropic, "Model Context Protocol Specification", 2025.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Informative References This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. CyberArk Zscaler University of Applied Sciences Bonn-Rhein-Sieg The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. Authproof This document defines the Delegation Receipt Protocol (DRP), a cryptographic authorization primitive for AI agent deployments. Before any agent action executes, the authorizing user signs an Authorization Object containing scope boundaries, time window, operator instruction hash, and model state commitment. This signed receipt is published to an append-only log before the agent runtime receives control. The protocol reduces reliance on the operator as a trusted intermediary by making the user's private key the sole signing authority over the delegation record. Tenuo This document defines Attenuating Authorization Tokens (AATs), a JWT- based credential format for secure delegation in AI agent systems. An AAT encodes which tools an agent may invoke and with what argument constraints. Any holder can derive a more restrictive token offline that narrows or maintains scope but cannot expand it. This invariant is cryptographically enforced and verifiable offline by any party holding the root token's trust anchor key. This specification extends the Rich Authorization Requests format (RFC 9396) with delegation-chain semantics and defines a typed constraint vocabulary for tool-level argument restrictions. The accompanying chain verification algorithm enforces the monotonic attenuation invariant at each delegation step and requires no network contact with the root issuer. Oracle JPMorgan Chase & Co Telefonica Aryaka Multi-hop service-to-service and agentic workflows need a standardized way to preserve and validate delegation-path continuity across successive token exchanges. This document defines six actor- chain profiles for OAuth 2.0 Token Exchange [RFC8693]. [RFC8693] permits nested act claims, but prior actors remain informational only and token exchange does not define how a delegation path is preserved and validated across successive exchanges. This document profiles delegation-chain tokens and defines profile- specific processing for multi-hop workflows. The six profiles are: Declared Full Disclosure; Declared Subset Disclosure; Declared Actor- Only Disclosure; Verified Full Disclosure; Verified Subset Disclosure; and Verified Actor-Only Disclosure. These profiles preserve the existing meanings of sub, act, and may_act. They support same-domain and cross-domain delegation and provide different tradeoffs among visible chain-based authorization, cryptographic accountability, auditability, privacy, and long-running workflow support. Plain RFC 8693 impersonation-shaped outputs remain valid RFC 8693 behavior but are outside this profile family. n.d. n.d. n.d. n.d. n.d. n.d.

Appendix A. Regulatory Mapping

PSD2 SCA Mapping ATTP trust levels map to PSD2 Strong Customer Authentication requirements:

• L0-L1: Equivalent to unauthenticated. No SCA-exempt transactions permitted.
• L2: SCA-exempt for low-value transactions (< EUR 30, aggregate < EUR 100).
• L3-L4: Challenge-response verification satisfies the "something you have" factor when combined with code attestation ("something you are" for agents).

PCI DSS v4.0.1 Mapping

• Req 3.5 (key storage): ATTP mandates HSM/KMS for production private keys.
• Req 6.2 (software security): Code attestation dimension maps to verified software inventory.
• Req 8 (identify and authenticate): Challenge-response with ECDSA satisfies strong authentication.
• Req 10 (logging): Hash-chained audit trail satisfies tamper-evident logging.
• Req 11 (testing): Anomaly detection satisfies continuous monitoring requirements.

Appendix B. Trust Level Reference Implementation A reference implementation of the ATTP trust scoring model is available at:

• Go: github.com/razashariff/agentpass-go (Apache 2.0)
• JavaScript: npm install agentsign (BSL 1.1)
• Keycloak: github.com/razashariff/keycloak-mcps (BSL 1.1)

Appendix C. Comparison with Identity-Only Approaches Identity-only protocols provide authentication. ATTP provides trust-gated authorisation. The following table summarises the differences: +--------------------------+----------+------+ | Capability | Identity | ATTP | +--------------------------+----------+------+ | Prove agent identity | Yes | Yes* | | Graduated trust levels | No | Yes | | Action limits | No | Yes | | Sanctions screening | No | Yes | | Kill switches | No | Yes | | Behavioural scoring | No | Yes | | Tamper-evident audit | No | Yes | | Fail-closed enforcement | Varies | Yes | | Dormancy decay | No | Yes | | Self-dealing detection | No | Yes | +--------------------------+----------+------+

• ATTP consumes identity from external providers; it does not implement its own identity protocol.

Author's Address Raza Sharif CyberSecAI Ltd 205 Regent Street London W1B 4HB United Kingdom Email: contact@agentsign.dev