Vorim Agent Identity Protocol (VAIP)

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.¶
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.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¶
• {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]

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.1. Scopes

VAIP defines seven permission scopes. Each scope authorises a category of agent actions:¶

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.¶

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.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}

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.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

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).¶

7.1. Cryptographic Choices

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.¶

7.5. Threat Model