Skip to main content

​
The problem

When an AI agent takes an action — queries a database, calls an API, modifies a file — there is no standard way to answer these questions after the fact:
  • Who authorized this? Did a human approve it, or did the agent act autonomously?
  • Which agent did it? If you have ten agent instances, which one made this call?
  • Has the record been altered? Can you prove the log hasn’t been modified since it was written?
  • Can I verify this without calling your server? Can a third party audit your agent’s behavior without trusting your infrastructure?
These questions matter enormously in cross-organization workflows: when your MCP server is being called by an agent from another company, when a regulated industry requires an audit trail, when you need to prove to a customer that an agent acted within its authorization.

​
What Vane does

Vane is a server you run (or deploy on Railway) that provides three primitives: 1. Cryptographic identity. Every company and agent gets a SPIFFE workload identity — a URI like spiffe://vane.local/company/acme/agent/researcher-1. These identities are tied to Ed25519 key pairs controlled by Vane. Every record and every credential is signed with those keys. 2. Agent passports. An agent gets a short-lived signed credential — a Vane Agent Passport (CAP+JWT) — that encodes its identity, its authorization scopes, and the delegation chain that authorized it. Any MCP server can verify this credential offline, without calling Vane. No network round-trip, no trust in the caller’s claims. 3. Tamper-evident attestation. Every action an agent takes can be attested as a signed record in an append-only chain. Records are hash-chained (each record’s hash includes the previous record’s hash as context via its index) and organized into a Merkle tree. Anyone holding the CA public key can verify the full chain or produce an inclusion proof for any individual record.

​
How it fits into your architecture

​
What makes it verifiable

Everything Vane produces can be verified with a single Ed25519 public key. The CA public key is published at GET /v1/ca/public-key?companyId=<id> with no authentication required. Once a verifier has that key, it can:
  • Verify any agent passport without calling Vane
  • Verify any attestation record’s signature
  • Re-derive the Merkle root from any set of records
  • Verify a Merkle inclusion proof in O(log n) without the full chain
The key is static (until a planned rotation), suitable for pinning in verifier deployments.

​
What it does not do (yet)

  • Workload attestation at registration. Any holder of a company API key can register an agent with any name. Production deployments would want node attestation (TPM, k8s projected service accounts, SPIRE) before issuing an SVID.
  • JWT revocation. Revoked passports are tracked in the revocation list (GET /v1/passports/revoked) and OCSP (GET /v1/ocsp/:jti), but issued SVIDs are valid until expiry — there is no CRL or short-lived rotation for those tokens.
  • Key rotation. Replacing a company’s key pair invalidates all existing signatures. A planned rotation mechanism is not yet implemented.
These are known gaps, not oversights — see Known Limitations for the full list.