Independent Submission K. Nyantakyi Internet-Draft Vorim AI Intended status: Standards Track April 2026 Expires: 11 October 2026 Vorim Agent Identity Protocol (VAIP) draft-nyantakyi-vaip-agent-identity-00 Abstract This document defines the Vorim Agent Identity Protocol (VAIP), a standard for establishing verifiable cryptographic identity, fine- grained permissions, trust scoring, and tamper-evident audit trails for autonomous AI agents. As AI agents increasingly perform actions autonomously in enterprise systems, existing identity protocols designed for human users or static services are insufficient. VAIP addresses this gap by providing cryptographic primitives and data structures for issuing, verifying, and managing agent identities in multi-tenant environments. The protocol uses Ed25519 for agent identity, SHA-256 for audit integrity, and defines seven hierarchical permission scopes with time-bounded grants and rate limiting. 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 3 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Nyantakyi Expires 11 October 2026 [Page 1] Internet-Draft VAIP April 2026 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Agent Identity . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Identity Format . . . . . . . . . . . . . . . . . . . . . 4 2.2. Keypair Generation . . . . . . . . . . . . . . . . . . . 5 2.3. Key Fingerprint . . . . . . . . . . . . . . . . . . . . . 5 2.4. Agent Lifecycle . . . . . . . . . . . . . . . . . . . . . 6 2.5. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 6 3. Permission Model . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Permission Grants . . . . . . . . . . . . . . . . . . . . 7 3.3. Rate Limits . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Permission Check Flow . . . . . . . . . . . . . . . . . . 8 4. Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Event Schema . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Hash Format . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Event Signatures . . . . . . . . . . . . . . . . . . . . 9 4.4. Immutability . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Signed Audit Bundles . . . . . . . . . . . . . . . . . . 9 5. Trust Scoring . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Scoring Algorithm . . . . . . . . . . . . . . . . . . . . 9 5.3. Trust Verification . . . . . . . . . . . . . . . . . . . 10 5.4. Trust Badges . . . . . . . . . . . . . . . . . . . . . . 10 6. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7.1. Cryptographic Choices . . . . . . . . . . . . . . . . . . 11 7.2. Private Key Handling . . . . . . . . . . . . . . . . . . 11 7.3. Multi-Tenant Isolation . . . . . . . . . . . . . . . . . 11 7.4. Transport Security . . . . . . . . . . . . . . . . . . . 11 7.5. Threat Model . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Nyantakyi Expires 11 October 2026 [Page 2] Internet-Draft VAIP April 2026 Appendix A. Reference Implementation . . . . . . . . . . . . . . 13 Appendix B. Relationship to Existing Standards . . . . . . . . . 13 Appendix C. Regulatory Alignment . . . . . . . . . . . . . . . . 14 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction 1.1. Problem Statement Autonomous AI agents are increasingly deployed to perform real-world tasks: executing code, sending messages, making financial transactions, and accessing sensitive resources. Unlike human users, agents lack a standardised identity layer. There is no widely adopted protocol for answering fundamental questions about an agent: * Who is this agent? (Identity) * What is it allowed to do? (Permissions) * What has it done? (Audit) * Should I trust it? (Trust) Existing identity systems (OAuth 2.0, API keys, X.509 certificates) were designed for human users or static services. They do not address the unique requirements of autonomous agents that act independently, accumulate behavioural history, and require dynamic trust assessment. Non-human identities outnumber human identities by approximately 50:1 in the average enterprise, yet no standardised infrastructure exists for managing them. 1.2. Design Principles 1. Cryptographic verifiability: Every identity claim MUST be verifiable through public key cryptography without relying on a central authority at verification time. 2. Minimal trust: Private keys are generated once and never stored by the issuing system. The agent or its operator is the sole custodian of its private key. 3. Auditability: Every action performed by an agent MUST be logged in a tamper-evident ledger. Audit records MUST support independent integrity verification. Nyantakyi Expires 11 October 2026 [Page 3] Internet-Draft VAIP April 2026 4. Interoperability: The protocol uses widely supported cryptographic standards (Ed25519, SHA-256) and data formats (JSON, PEM) to enable cross-platform verification. 5. Multi-tenancy: All identities, permissions, and audit records are scoped to an organisation. No data leaks across tenants. 1.3. 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 an organisation. Organisation A tenant entity that owns and manages agents. Operator A human user who registers and configures agents within an organisation. Scope A named permission that authorises a specific category of action. Trust Score A numeric assessment (0-100) of an agent's reliability based on behavioural history. Audit Event An immutable record of an action performed by or on behalf of an agent. 2. Agent Identity 2.1. Identity Format Every agent MUST be assigned a unique agent identifier upon registration. The identifier follows this format: agid_{org_slug}_{random} Where: * "agid_" is a fixed prefix identifying the string as a VAIP agent identifier * {org_slug} is a truncated (up to 8 characters) alphanumeric slug identifying the owning organisation Nyantakyi Expires 11 October 2026 [Page 4] Internet-Draft VAIP April 2026 * {random} is a cryptographically random string (8 characters, derived from UUID v4) Example: agid_acme_a1b2c3d4 Agent identifiers MUST be globally unique and MUST NOT be reused after revocation. 2.2. Keypair Generation Each agent MUST be assigned an Ed25519 [RFC8032] keypair at registration time. Ed25519 was chosen for the following properties: * 128-bit security level * Fast key generation, signing, and verification * Small key and signature sizes (32-byte public keys, 64-byte signatures) * Deterministic signatures (no nonce reuse vulnerabilities) * Resistance to timing attacks The keypair MUST be generated as follows: 1. Generate an Ed25519 keypair using the system's cryptographic random number generator 2. Encode the public key in SPKI/PEM format 3. Encode the private key in PKCS#8/PEM format 4. Compute the key fingerprint 5. Return the private key to the operator exactly once 6. Store the public key and fingerprint; never store the private key 2.3. Key Fingerprint A key fingerprint is a SHA-256 [RFC6234] hash of the PEM-encoded public key, represented as a hexadecimal string (64 characters): fingerprint = SHA-256(public_key_pem)[0:64] Nyantakyi Expires 11 October 2026 [Page 5] Internet-Draft VAIP April 2026 The fingerprint serves as a compact, verifiable reference to an agent's identity. It MUST be included in trust verification responses and MAY be used for identity comparison without transmitting the full public key. 2.4. Agent Lifecycle An agent MUST exist in exactly one of the following states at any time: * pending: Registered but not yet activated * active: Fully operational, permissions enforceable * suspended: Temporarily disabled, can be reactivated * revoked: Permanently disabled, cannot be reactivated * expired: Past its expiration timestamp A revoked agent MUST NOT be reactivated. Its identifier MUST NOT be reused. 2.5. Key Rotation An agent's keypair MAY be rotated by revoking the current agent and registering a new agent with the same metadata. The new agent MUST receive a new agent_id and keypair. 3. Permission Model 3.1. Scopes VAIP defines seven permission scopes. Each scope authorises a category of agent actions: Nyantakyi Expires 11 October 2026 [Page 6] Internet-Draft VAIP April 2026 +=============+===================+============+ | Scope | Identifier | Risk Level | +=============+===================+============+ | Read | agent:read | Low | +-------------+-------------------+------------+ | Write | agent:write | Medium | +-------------+-------------------+------------+ | Execute | agent:execute | Medium | +-------------+-------------------+------------+ | Transact | agent:transact | High | +-------------+-------------------+------------+ | Communicate | agent:communicate | Medium | +-------------+-------------------+------------+ | Delegate | agent:delegate | High | +-------------+-------------------+------------+ | Elevate | agent:elevate | Critical | +-------------+-------------------+------------+ Table 1 Scopes are not hierarchical by default. Possessing agent:write does not imply agent:read. Each scope MUST be granted independently. 3.2. Permission Grants A permission grant binds a scope to an agent with optional constraints including: * valid_from: When the grant becomes effective * valid_until: Optional expiration time * rate_limit: Maximum uses within a time window * conditions: Additional constraints (e.g., IP allowlists) 3.3. Rate Limits A rate limit constrains how frequently a scope can be exercised: { "max": 1000, "window": "1h" } Supported windows: "1m" (minute), "1h" (hour), "1d" (day). When an agent exceeds its rate limit, permission checks MUST return denied with reason RATE_LIMIT_EXCEEDED. Nyantakyi Expires 11 October 2026 [Page 7] Internet-Draft VAIP April 2026 3.4. Permission Check Flow When an agent requests to perform an action, the system MUST: 1. Validate agent_id exists and status is active 2. Check cache for recent permission decision 3. If cache miss: query grants, filter by validity and revocation, evaluate rate limits and conditions 4. Cache the decision (RECOMMENDED TTL: 300 seconds) 5. Return the permission check result Valid denial reasons: AGENT_NOT_FOUND, AGENT_NOT_ACTIVE, SCOPE_NOT_GRANTED, GRANT_EXPIRED, RATE_LIMIT_EXCEEDED, CONDITION_NOT_MET. 4. Audit Trail 4.1. Event Schema Every auditable action MUST produce an audit event including: * event_id: Unique, time-sortable identifier (e.g., ULID) * agent_id: Agent that performed the action * org_id: Organisation context * event_type: Category (tool_call, api_request, message_sent, permission_change, status_change, key_rotation) * action: Specific action performed * result: Outcome (success, denied, error) * timestamp: ISO 8601 timestamp Optional fields include resource, input_hash, output_hash, permission, latency_ms, error_code, signature, and metadata. 4.2. Hash Format All hashes in audit events MUST use the format: sha256:{hex_digest} Nyantakyi Expires 11 October 2026 [Page 8] Internet-Draft VAIP April 2026 Where {hex_digest} is the lowercase hexadecimal representation of the SHA-256 hash. 4.3. Event Signatures Audit events MAY be signed by the agent that produced them. When present, the signature field MUST contain an Ed25519 signature of the canonical JSON [RFC8259] representation of the event (excluding the signature field itself), encoded as: ed25519:{base64_signature} 4.4. Immutability Audit events MUST be append-only. Once written, an event MUST NOT be modified or deleted except by automated retention policies. 4.5. Signed Audit Bundles Conforming systems MUST support exporting audit events as signed bundles. A bundle contains the events array, event count, time range, organisation identifier, and a manifest field containing a SHA-256 hash of the JSON-serialised events array. Any modification to any event produces a different manifest hash, making tampering detectable. 5. Trust Scoring 5.1. Overview Trust scoring provides a quantitative assessment of an agent's reliability. The score is a number from 0 to 100, computed from multiple behavioural and configuration factors. Trust scores are dynamic, public, and composite. 5.2. Scoring Algorithm The trust score is computed as: score = base_score + status_factor + age_factor + success_rate_factor - denial_penalty - scope_breadth_penalty Nyantakyi Expires 11 October 2026 [Page 9] Internet-Draft VAIP April 2026 Base score: 50. Status factor: active (+10), suspended (-20), revoked (score fixed at 0). Age factor: >90 days (+15), >30 days (+10), >7 days (+5). Success rate factor: round(success_rate * 15) over trailing 30-day window. Denial penalty: -10 if denied_count exceeds 10% of total events. Scope breadth penalty: -5 if agent holds more than 5 active scopes. Final score clamped to [0, 100]. 5.3. Trust Verification Conforming implementations MUST provide a public, unauthenticated endpoint for trust verification. The response includes agent_id, verification status, trust score, active scopes, key fingerprint, and revocation status. 5.4. Trust Badges Conforming implementations SHOULD provide embeddable SVG trust badges displaying protocol name, verification status, and trust score with colour coding: green (80-100), amber (50-79), red (0-49). 6. Conformance Levels Implementations MAY conform to one or more levels: Level 1 - Identity Agent registration with Ed25519 keypairs, key fingerprints, lifecycle management. Level 2 - Permissions Level 1 plus seven permission scopes, time- bounded grants, rate limiting, cached permission checks. Level 3 - Audit Level 2 plus audit event ingestion, schema compliance, SHA-256 hashing, event query with filtering. Level 4 - Trust Level 3 plus trust score computation, public verification endpoint, embeddable trust badges. Level 5 - Full Conformance Level 4 plus signed audit bundle export, Ed25519 event signatures, multi-format export, API key management. 7. Security Considerations Nyantakyi Expires 11 October 2026 [Page 10] Internet-Draft VAIP April 2026 7.1. Cryptographic Choices +================+===========+========================+ | Primitive | Algorithm | Rationale | +================+===========+========================+ | Agent identity | Ed25519 | Fast, compact, timing- | | | | attack resistant | +----------------+-----------+------------------------+ | Fingerprints | SHA-256 | Widely supported, | | | | collision resistant | +----------------+-----------+------------------------+ | Audit | SHA-256 | Industry standard for | | integrity | | data integrity | +----------------+-----------+------------------------+ | Password | bcrypt | Memory-hard, | | hashing | (cost 12) | adjustable work factor | +----------------+-----------+------------------------+ | API key | SHA-256 | One-way hashing for | | storage | | stored secrets | +----------------+-----------+------------------------+ Table 2 7.2. Private Key Handling Conforming implementations: * MUST generate private keys server-side using a cryptographic random number generator * MUST return the private key to the operator exactly once * MUST NOT store, log, or persist the private key after returning it * MUST NOT transmit private keys over unencrypted channels 7.3. Multi-Tenant Isolation All database queries MUST be scoped to the authenticated organisation's identifier. No agent, permission, or audit record from one organisation may be accessible by another. 7.4. Transport Security All API communications MUST use TLS 1.2 or higher. TLS 1.3 is RECOMMENDED. Nyantakyi Expires 11 October 2026 [Page 11] Internet-Draft VAIP April 2026 7.5. Threat Model +=====================+========================================+ | Threat | Mitigation | +=====================+========================================+ | Key compromise | Immediate revocation, new registration | +---------------------+----------------------------------------+ | Audit tampering | SHA-256 manifest, append-only storage | +---------------------+----------------------------------------+ | Cross-tenant access | Organisation-scoped queries | +---------------------+----------------------------------------+ | Replay attacks | Time-sortable event IDs, timestamp | | | validation | +---------------------+----------------------------------------+ | Brute-force auth | bcrypt hashing, API key entropy (192 | | | bits) | +---------------------+----------------------------------------+ | Trust manipulation | Score from audited behaviour, not | | | self-reported | +---------------------+----------------------------------------+ Table 3 8. IANA Considerations This document requests the registration of the following media type: Type name application Subtype name vaip+json Required parameters none Optional parameters none Encoding considerations binary (UTF-8 JSON) Security considerations See the Security Considerations section of this document. Interoperability considerations Implementations MUST support JSON encoding as defined in RFC 8259. Published specification This document. Applications that use this media type AI agent identity management systems, audit trail systems, trust verification services. Nyantakyi Expires 11 October 2026 [Page 12] Internet-Draft VAIP April 2026 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, December 2017, . 9.2. Informative References [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, . Appendix A. Reference Implementation A reference implementation of VAIP is available at: * TypeScript SDK: https://www.npmjs.com/package/@vorim/sdk * Python SDK: https://pypi.org/project/vorim/ * Protocol specification: https://github.com/Kzino/vorim-protocol * MCP Server: https://www.npmjs.com/package/@vorim/mcp-server Appendix B. Relationship to Existing Standards VAIP is designed to complement, not replace, existing identity and security standards: Nyantakyi Expires 11 October 2026 [Page 13] Internet-Draft VAIP April 2026 OAuth 2.0 (RFC 6749) OAuth focuses on delegated authorisation for human users. VAIP extends the concept to autonomous agents that act independently without human-in-the-loop authorisation. W3C Decentralized Identifiers (DID) VAIP agent identifiers could be extended to DID format for decentralised resolution. The current format prioritises simplicity and readability. SPIFFE SPIFFE provides workload identity attestation. VAIP adds trust scoring, audit trails, and permission models beyond identity. X.509 (RFC 5280) VAIP uses Ed25519 directly rather than certificate chains, prioritising simplicity and agent-specific semantics over PKI hierarchies. Appendix C. Regulatory Alignment VAIP's identity, permission, and audit features support compliance with emerging AI governance frameworks including: * EU AI Act (enforced August 2025): Traceability and audit trail requirements for high-risk AI systems. * US Executive Order on AI (EO 14110): Risk management, transparency, and accountability for AI systems. * Colorado AI Act: Automated decision-making documentation requirements. * NIST AI Risk Management Framework: AI system governance and accountability controls. Appendix D. Acknowledgements The author thanks the open-source community and early adopters of the Vorim Agent Identity Protocol for their feedback and contributions to this specification. Author's Address Kwame Nyantakyi Vorim AI Email: kwame@vorim.ai URI: https://vorim.ai Nyantakyi Expires 11 October 2026 [Page 14]