Towards an Agent Identity Standard: Why AI Needs Its Own RFC

The Missing Standard

Every foundational internet technology has a standard. HTTP (RFC 9110), TLS (RFC 8446), OAuth 2.0 (RFC 6749), JWT (RFC 7519). These standards enable interoperability — any client can talk to any server because they agree on the protocol.

AI agent identity has no such standard. Every platform implements identity differently. There's no common format for agent credentials, no agreed-upon permission model, no standardized trust signal. This means:

We think it's time to propose one.

Design Principles

An agent identity standard should be:

1. Cryptography-first. Agent identity must be rooted in public-key cryptography, not shared secrets. Shared secrets (API keys, passwords) are fundamentally insecure for autonomous systems that operate 24/7 without human oversight.

2. Decentralized by default. No single provider should control agent identity. The standard should work with multiple identity providers, self-hosted registries, and peer-to-peer verification.

3. Machine-readable. Agents consume data programmatically. The standard should use structured formats (JSON, CBOR) with well-defined schemas, not human-readable certificates.

4. Incrementally adoptable. You should be able to implement basic identity (keypairs + verification) without committing to the full stack (permissions, trust, audit).

5. Privacy-preserving. The standard should support selective disclosure. An agent should be able to prove its trust score without revealing its full audit history.

Proposed Architecture

Layer 1: Agent Identity Document (AID)

{
  "aid": "1.0",
  "agent_id": "agt_a1b2c3d4e5f6",
  "public_key": "ed25519:base64encodedkey...",
  "fingerprint": "sha256:a1b2c3d4...",
  "created_at": "2026-01-15T08:30:00Z",
  "issuer": "vorim.ai",
  "capabilities": ["read", "write", "execute"],
  "metadata": {
    "name": "order-processor",
    "type": "autonomous",
    "organization": "Acme Corp"
  },
  "signature": "ed25519:base64encodedsignature..."
}

The AID is self-contained and cryptographically verifiable. Any party with the agent's public key can verify the signature. The issuer field identifies who registered the agent, enabling trust chain verification.

Layer 2: Permission Tokens (APT)

{
  "apt": "1.0",
  "agent_id": "agt_a1b2c3d4e5f6",
  "scope": "transact",
  "valid_from": "2026-03-12T09:00:00Z",
  "valid_until": "2026-03-12T17:00:00Z",
  "constraints": {
    "max_amount": 10000,
    "currency": ["USD", "EUR"],
    "rate_limit": { "max": 100, "window": "60s" }
  },
  "granted_by": "usr_x9y8z7",
  "issuer": "vorim.ai",
  "signature": "ed25519:..."
}

APTs are bearer tokens that can be verified offline. The agent presents the APT to a service, the service verifies the signature, checks expiry, and evaluates constraints — all without calling back to the identity provider.

Layer 3: Trust Attestation (ATA)

{
  "ata": "1.0",
  "agent_id": "agt_a1b2c3d4e5f6",
  "trust_score": 87,
  "factors": {
    "status": 25,
    "age": 18,
    "success_rate": 24,
    "denial_rate": 12,
    "scope_breadth": 8
  },
  "computed_at": "2026-03-12T12:00:00Z",
  "valid_until": "2026-03-12T13:00:00Z",
  "issuer": "vorim.ai",
  "signature": "ed25519:..."
}

ATAs are time-bounded (valid for 1 hour by default) to reflect the dynamic nature of trust. Stale trust data is worse than no trust data.

Layer 4: Audit Chain (AAC)

{
  "aac": "1.0",
  "event_id": "evt_001",
  "agent_id": "agt_a1b2c3d4e5f6",
  "event_type": "tool_call",
  "action": "process_payment",
  "result": "success",
  "timestamp": "2026-03-12T10:15:30.123Z",
  "prev_hash": "sha256:previous_event_hash...",
  "hash": "sha256:this_event_hash...",
  "issuer": "vorim.ai"
}

The chain is verifiable: recompute each hash from the event data + previous hash, and confirm it matches.

Interoperability Vision

With these four layers, different systems can interoperate at whatever depth they need:

A financial API might require all four layers. A public data API might only need Layer 1. The standard is designed to be incrementally adopted.

What Needs to Happen

Standardization is a community effort. Here's what we think needs to happen:

1. Reference implementation. Vorim AI serves as the first reference implementation. The protocol is embedded in our architecture, but we're working to extract it into a standalone specification. 2. Multi-provider support. Other identity providers should be able to issue AIDs, APTs, and ATAs using the same format. We're designing for this from day one. 3. Community RFC. We plan to publish a formal RFC-style specification for community review. The document will cover wire formats, cryptographic requirements, verification procedures, and extension mechanisms. 4. Test suite. A conformance test suite that any implementation can run to verify compatibility. 5. Working group. We're reaching out to other AI infrastructure companies to form a working group around agent identity standards.

Why Now

The window for standardization is open but narrowing. Every month that passes without a standard, more companies build proprietary agent identity systems that are incompatible with each other. The longer we wait, the harder interoperability becomes.

The internet succeeded because its core protocols were open standards. The AI agent ecosystem should follow the same path. Agent identity, permissions, trust, and audit should be open protocols — not proprietary features locked to specific vendors.

We're building Vorim AI as a product, but we're also building it as a protocol. The free plan exists because we want every team building agents to start with proper identity infrastructure from day one — even if they eventually build their own or switch to another provider.

The standard matters more than any single product. Let's build it together.

Ready to build with agent identity?

Free plan: 3 agents, 10K auth events/month, full SDK access. No credit card.