SwiftAPI Attestation Protocol Specification (Version 1.0.0)

SwiftAPI Attestation Protocol Specification Version 1.0.0 – Proposed Standard December 21, 2025 1 Abstract The SwiftAPI Attestation Protocol (SAP) establishes a cryptographic standard for authorizing autonomous agent interactions and side-effects. The protocol decouples intent from authority by mandating signed, verifiable attestations for high-privilege operations. This effective separation of concerns creates a fail-closed governance layer specifically designed for non-deterministic automated systems, mitigating risks associated with untrusted execution environments and semantic injection attacks. 2 Threat Model The SwiftAPI architecture addresses specific vulnerabilities inherent to autonomous agent deployment: •Unauthorized Execution: Prevention of agents accessing protected resources (e.g., database schemas, financial gateways) without explicit, scoped authorization. •Semantic Injection: Mitigation of prompt injection attacks by enforcing cryptographic checks at the execution layer. Logic coercion of the model becomes ineffective against protected actions that require external signing. •Replay Attacks: Prevention of unauthorized re-execution of valid attestations via nonce-based verification (JTI). •Credential Compromise: Support for rapid key rotation and targeted revocation without requiring redeployment of agent logic. 3 Protocol Flow The authorization sequence consists of five distinct phases: 1. Request Phase: The Actor (Agent) transmits a structured request to the Authority service. • Payload: Action,Intent,Context,ActorID • Authentication: X-SwiftAPI-Authority header 2. Policy Evaluation: The Authority validates the request against active Policy Definitions. • Logic includes scope validation, rate limiting, and context-aware rules. 3. Issuance: Upon successful evaluation, the Authority generates an Attestation Token. • Cryptographic Primitive: Ed25519 Signature 4. Verification: The Enforcement Point (SDK or Gateway) validates the Token prior to execution. • Validation 1: Signature Integrity (Ed25519) • Validation 2: Time-to-Live (TTL) • Validation 3: JTI Revocation Status 5. Execution: The protected function is executed only after all validation checks return positive. 1 4 Data Structures 4.1 Attestation Token Schema The token is a JSON object containing the following claims: 1{ 2" ver ": "1.0" , 3" iss ": " swiftapi . ai", 4" iat ": 1703184000 , 5" exp ": 1703184300 , 6" jti ": "550 e8400 -e29b -41 d4 -a716 -446655440000" , 7" act ": { 8"type": "database_write", 9"hash": "sha256_of_payload_or_params", 10 " rsrc ": " prod_db_users " 11 }, 12 " scp ": [" database : write ", " payment : authorize "] , 13 "sig": "base64_encoded_ed25519_signature" 14 } Listing 1: Attestation Token (JSON) •ver: Protocol version identifier. •iss: Issuer identifier (SwiftAPI Authority). •jti: Unique Token Identifier (Nonce) for replay protection. •act: Action descriptor including type, target resource, and integrity hash. •sig: Base64-encoded Ed25519 signature of the canonicalized payload. 4.2 Cryptographic Standards •Signature Algorithm: Ed25519 (EdDSA) •Curve: Curve25519 •Canonicalization: Deterministic JSON field ordering is required prior to signing (RFC 8785 or equivalent). 5 Verification Logic Implementations must adhere to the following verification procedure: 1def verify_attestation (token , public_key , revocation_list ): 2# 1. Integrity Verification 3if not ed25519_verify ( token . payload , token .sig , public_key ): 4raise SignatureInvalidError(" Cryptographic signature verification failed") 5# 2. Expiration Verification 6if current_timestamp () > token . exp : 7raise TokenExpiredError(" Attestation token has expired ") 8# 3. Revocation Check 9if token . jti in revocation_list : 10 raise TokenRevokedError(" Attestation token has been revoked ") 11 # 4. Scope Validation 12 if protected_action . scope not in token . scp : 13 raise InsufficientScopeError(" Authorized scope does not match requested action") 14 return True Listing 2: Verification Psuedo-Code 2 6 Key Management •Authority Keys: Managed securely by the SwiftAPI Service via HSM/KMS. •Agent Keys: Distributed to clients for request authentication only; these keys cannot sign attestations. •Rotation: Support for root key rotation. Attestations signed by previous keys are invalidated upon public key update distribution. 7 Compliance and Standards The protocol aligns with NIST SP 800-207 (Zero Trust Architecture) principles: •Dynamic Authorization: Access is granted on a per-request basis. •Implicit Trust Elimination: Network location or code proximity does not confer execution privileges. •Continuous Validation: All privileged actions undergo cryptographic verification. Copyright © 2025 SwiftAPI. All Rights Reserved. 3