Internet Engineering Task Force R. Sharif Internet-Draft CyberSecAI Ltd Intended status: Standards Track 1 May 2026 Expires: 1 November 2026 ATTP: Agent Trust Transport Protocol draft-sharif-attp-00 Abstract 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, and GraphQL. This specification supersedes draft-sharif-agent-payment-trust-00, broadening the scope from payment transactions to any agent action requiring trust-gated authorisation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 1.1. The Trust Gap 1.2. Relationship to Identity Protocols 1.3. Relationship to Existing Specifications 1.4. Design Goals 2. Terminology 3. Agent Identity 3.1. Key Pair Generation 3.2. Public Key Registration 3.3. Agent Passport 3.4. Key Rotation 4. Challenge-Response Identity Verification 4.1. Challenge Issuance 4.2. Challenge Signing 4.3. Signature Verification 4.4. Failure Handling 5. Trust Scoring Model 5.1. Scoring Dimensions 5.2. Dimension Weights 5.3. Score Computation 5.4. Trust Levels 5.5. Dynamic Adjustment 5.6. Dormancy Decay 5.7. Promotion Rate Limiting 6. Action Limit Enforcement 6.1. Per-Action Limits 6.2. Daily Aggregate Limits 6.3. Principal Aggregate Limits 6.4. Cooling Period 7. Kill Switches 7.1. Per-Agent Kill Switch 7.2. Per-Principal Kill Switch 7.3. Emergency Freeze 8. Compliance Gating 8.1. Sanctions Screening 8.2. Jurisdictional Controls 8.3. Compliance Record 9. Anomaly Detection 9.1. Magnitude Anomaly 9.2. Velocity Anomaly 9.3. Temporal Anomaly 9.4. Counterparty Anomaly 9.5. Probing Anomaly 9.6. Self-Dealing Detection 10. Public Trust Query API 10.1. Request Format 10.2. Response Format 10.3. Batch Queries 10.4. Rate Limiting 10.5. Information Disclosure Controls 11. Action Signing and Receipts 11.1. Action Envelope 11.2. Hash Chain 11.3. Non-Repudiable Receipts 12. Protocol Bindings 12.1. MCP Binding (MCPS) 12.2. REST Binding 12.3. Google A2A Binding 12.4. gRPC Binding 12.5. GraphQL Binding 12.6. Keycloak Integration 13. Revocation 13.1. Agent Revocation 13.2. Emergency Freeze 14. Security Considerations 14.1. Key Management 14.2. Trust Farming Mitigation 14.3. Sybil Attack Prevention 14.4. Impersonation Detection 14.5. Race Condition Handling 14.6. Replay Protection 14.7. Kill Switch Consistency 14.8. Comparison with Identity-Only Protocols 15. Privacy Considerations 16. IANA Considerations 17. References 17.1. Normative References 17.2. Informative References Appendix A. Regulatory Mapping A.1. PSD2 SCA Mapping A.2. PCI DSS v4.0.1 Mapping Appendix B. Trust Level Reference Implementation Appendix C. Comparison with Identity-Only Approaches Author's Address 1. Introduction 1.1. 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: o Has this agent earned the right to perform actions of this magnitude? o Does this agent's behavioural history justify the level of trust required? o Is the counterparty cleared for this interaction (sanctions, jurisdictional compliance)? o Can this agent be stopped instantly if something goes wrong? o 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. 1.2. Relationship to Identity Protocols ATTP does not replace identity protocols. It consumes identity assertions from any standards-compliant source: o OAuth 2.0 / OpenID Connect tokens (RFC 6749, OpenID Core) o X.509 certificates (RFC 5280) o HTTP Message Signatures (RFC 9421) o Self-issued cryptographic identities (JWKS-based) o Any OIDC-compliant provider (Keycloak, Azure AD, Okta, etc.) 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. 1.3. 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. 1.4. 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. 2. 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] [RFC8174] 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. 3. Agent Identity 3.1. Key Pair Generation Each agent MUST have a unique ECDSA key pair using the P-256 curve [FIPS186-5]. 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. 3.2. 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. 3.3. Agent Passport Upon registration, the Trust Authority issues an Agent Passport -- a signed JSON document containing: o agentId: Unique identifier for the agent. o publicKeyHash: SHA-256 hash of the agent's public key, binding the passport to a specific key pair. o principalId: Identifier of the owning principal. o scope: Array of authorised action categories. o trustLevel: Current trust level (L0-L4). o issuedAt: ISO 8601 timestamp of issuance. o expiresAt: ISO 8601 timestamp of expiry. o issuer: Identifier of the Trust Authority. o 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) [RFC8785] 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. 3.4. 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. 4. Challenge-Response Identity Verification When a platform needs to verify an agent's identity before granting access, it uses the following challenge-response protocol. 4.1. Challenge Issuance The platform (or TA on behalf of the platform) generates a challenge: o challenge: 32 bytes of cryptographically random data, hex-encoded (64 characters). o expiresAt: Timestamp, MUST be no more than 60 seconds from issuance. o 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. 4.2. 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. 4.3. 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. 4.4. Failure Handling If verification fails: o The TA MUST log the failure as a potential impersonation attempt. o The agent's trust score MUST be penalised (RECOMMENDED: -10 points per failed attempt). o The response MUST include an error code: IMPERSONATION, CHALLENGE_EXPIRED, CHALLENGE_REPLAYED, or AGENT_MISMATCH. 5. Trust Scoring Model 5.1. 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. 5.2. 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. 5.3. 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) 5.4. 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. 5.5. Dynamic Adjustment The trust score adjusts dynamically based on observed behaviour: o Successful action: +0.5 trust bonus. o Blocked action (over limit): -2 trust bonus. o Anomaly detected: -5 per anomaly. o Critical anomaly (3+ simultaneous): -20 trust bonus. o Failed identity verification: -10 trust bonus. o Probing detected: -15 trust bonus. Self-dealing actions (agent-to-agent within the same principal) MUST earn zero trust bonus. 5.6. Dormancy Decay Agents inactive for extended periods MUST have their trust score reduced: o 30 days inactive: -10 penalty. o 60 days inactive: -20 penalty. o 90+ days inactive: -30 penalty. The dormancy penalty is removed when the agent resumes activity. 5.7. Promotion Rate Limiting Trust level promotions MUST be rate-limited to prevent trust farming attacks: o L0 to L1: Minimum 24 hours at L0 with at least 5 successful actions. o L1 to L2: Minimum 7 days at L1 with at least 20 successful actions. o L2 to L3: Minimum 30 days at L2 with at least 100 successful actions and zero critical anomalies. o 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. 6. Action Limit Enforcement 6.1. 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). 6.2. Daily Aggregate Limits The TA MUST track daily aggregate action magnitude per agent within a rolling 24-hour window. 6.3. 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. 6.4. 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. 7. Kill Switches 7.1. Per-Agent Kill Switch Each agent MUST have an independently controllable kill switch. When activated: o ALL actions by the agent are denied immediately. o The denial takes effect on the next request (no grace period). o The agent's trust score is frozen (not reset). o The kill switch state is recorded in the audit trail. Reactivation requires explicit principal action and MUST NOT be automated. 7.2. Per-Principal Kill Switch Each principal MUST have a kill switch that simultaneously disables ALL agents under their control. 7.3. 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). 8. Compliance Gating 8.1. Sanctions Screening Before executing any financial action, the TA MUST screen the counterparty against applicable sanctions lists: o OFAC SDN (US) o EU Consolidated Sanctions o UK HMT Sanctions o UN Security Council Sanctions Screening MUST use fuzzy matching with a configurable threshold (RECOMMENDED: 70% match score). Matches above the threshold MUST block the action with error code ATTP-SANCTIONS-MATCH. Sanctions lists MUST be updated at least daily. 8.2. Jurisdictional Controls Actions MAY be restricted based on the jurisdiction of the agent, the principal, or the counterparty. The TA MUST support configurable jurisdiction rules. 8.3. Compliance Record Every compliance check MUST produce an audit record containing: the query, the lists checked, the match results (including near-misses), and the decision. Compliance records MUST be retained for the period required by applicable regulation (RECOMMENDED minimum: 5 years). 9. Anomaly Detection 9.1. Magnitude Anomaly An action whose magnitude exceeds 3 standard deviations from the agent's historical mean MUST be flagged. 9.2. Velocity Anomaly An action rate exceeding 2x the agent's historical maximum within any 5-minute window MUST be flagged. 9.3. Temporal Anomaly Actions outside the agent's established operating hours (based on 90-day history) SHOULD be flagged. 9.4. Counterparty Anomaly Actions directed at counterparties with which the agent has no prior history, when combined with elevated magnitude, MUST be flagged. 9.5. 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. 9.6. 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. 10. Public Trust Query API 10.1. 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. 10.2. 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-05-01T00:00:00Z", "checkedBy": "ATTP Trust Authority" } } 10.3. 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. 10.4. Rate Limiting The TA MUST rate-limit trust queries: o Anonymous queries: 120 per minute per IP. o Authenticated queries: 600 per minute per API key. 10.5. Information Disclosure Controls The public trust API MUST NOT expose: o Raw scoring dimension values. o Action history or details. o Private key material or key fingerprints. o Internal anomaly thresholds. The API provides trust level, recommendation, and limits only. 11. Action Signing and Receipts 11.1. 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-05-01T00:00:00Z", "signature": "" } The signature covers the JCS [RFC8785] serialisation of all fields except the signature field itself. 11.2. Hash Chain Action envelopes are linked in a hash chain: hash_n = SHA-256(hash_{n-1} || JCS(envelope_n)) The genesis hash is SHA-256("ATTP-GENESIS"). Breaking the hash chain indicates tampering. The TA MUST verify chain integrity on every append. 11.3. Non-Repudiable Receipts After successful action execution, the TA issues a receipt signed by the TA's key. The receipt includes: o The action envelope. o The TA's signature over the envelope. o The hash chain position. o The compliance check result. Receipts are non-repudiable: the agent cannot deny the action, and the TA cannot deny the trust decision. 12. Protocol Bindings ATTP is transport-agnostic. Protocol bindings map ATTP trust enforcement to specific transports. 12.1. MCP Binding (MCPS) The MCP binding is specified in draft-sharif-mcps-secure-mcp [MCPS]. 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. 12.2. 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: X-ATTP-Nonce: X-ATTP-Timestamp: The signature covers: method, path, body hash (SHA-256), nonce, and timestamp. 12.3. Google A2A Binding For the Agent2Agent protocol [GOOGLE-A2A], ATTP trust is embedded in the Task metadata. The agent's AgentCard includes ATTP trust level and TA endpoint in its capabilities declaration. 12.4. gRPC Binding For gRPC, ATTP trust is conveyed via metadata headers using the same header names as the REST binding. 12.5. 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 } } } 12.6. 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 (attp-l0 through attp-l4 roles). 13. Revocation 13.1. 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: o Set the kill switch. o Invalidate the current passport. o Record the revocation in the audit trail. o Optionally notify dependent platforms via webhook. 13.2. 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. 14. Security Considerations 14.1. 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. 14.2. Trust Farming Mitigation ATTP mitigates trust farming through: o Promotion rate limiting (Section 5.7). o Self-dealing detection (Section 9.6). o Principal aggregate limits (Section 6.3). o Dormancy decay (Section 5.6). 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. 14.3. 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. 14.4. Impersonation Detection Failed challenge-response verifications trigger trust penalties and audit entries. Three consecutive failures SHOULD trigger automatic agent suspension pending principal review. 14.5. 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. 14.6. 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). 14.7. 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. 14.8. 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: o Score agent trustworthiness based on behavioural history. o Enforce graduated action limits tied to trust levels. o Screen counterparties against sanctions lists. o Provide instant kill switches independent of credential lifecycle. o 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. 15. 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: o Action history or patterns. o Scoring dimension breakdowns. o Counterparty information. o Key material. o 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. 16. IANA Considerations This document defines the following HTTP headers for the REST protocol binding: o X-ATTP-Trust-Level o X-ATTP-Agent-Id o X-ATTP-Signature o X-ATTP-Nonce o X-ATTP-Timestamp Registration of these headers in the IANA Message Headers registry is requested. This document defines the following error codes: o ATTP-ACTION-LIMIT o ATTP-SANCTIONS-MATCH o ATTP-TRUST-INSUFFICIENT o ATTP-KILL-SWITCH-ACTIVE o ATTP-NONCE-REPLAY o ATTP-TIMESTAMP-EXPIRED This document defines the following well-known URI: o /.well-known/attp-trust For discovery of Trust Authority endpoints. 17. References 17.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020. [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015. [FIPS186-5] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-5, February 2023. 17.2. Informative References [MCPS] Sharif, R., "MCPS: Cryptographic Security Layer for the Model Context Protocol", draft-sharif-mcps-secure-mcp-00, March 2026. [AEBA] Sharif, R., "AEBA: Agent Event Behaviour Analytics", draft-sharif-aeba-00, April 2026. [OWASP-AISVS] OWASP, "AI Security Verification Standard", 2026. [RFC9421] Backman, A., Richer, J., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024. [GOOGLE-A2A] Google, "Agent2Agent Protocol", . [MCP] Anthropic, "Model Context Protocol Specification", . Appendix A. Regulatory Mapping A.1. PSD2 SCA Mapping ATTP trust levels map to PSD2 Strong Customer Authentication requirements: o L0-L1: Equivalent to unauthenticated. No SCA-exempt transactions permitted. o L2: SCA-exempt for low-value transactions (< EUR 30, aggregate < EUR 100). o L3-L4: Challenge-response verification satisfies the "something you have" factor when combined with code attestation ("something you are" for agents). A.2. PCI DSS v4.0.1 Mapping o Req 3.5 (key storage): ATTP mandates HSM/KMS for production private keys. o Req 6.2 (software security): Code attestation dimension maps to verified software inventory. o Req 8 (identify and authenticate): Challenge-response with ECDSA satisfies strong authentication. o Req 10 (logging): Hash-chained audit trail satisfies tamper-evident logging. o 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: o Go: github.com/razashariff/agentpass-go (Apache 2.0) o JavaScript: npm install agentsign (BSL 1.1) o 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