The Embassy exists to let autonomous systems verify identity without revealing it, enforce access boundaries, prove consent was granted, and maintain continuity across interactions. It provides cryptographic verification of authorization without requiring agents to expose internal state or memory.
Agent → Identity Token → Embassy Gate → Permit / Refuse (signed) → Enforcement by the calling system → Audit receipt available.
The Embassy issues time-limited visas with explicit scope and constraints. The calling system (platform) enforces these constraints. The Embassy does not observe or control agent behavior beyond the access decision.
Reference mode is non-authoritative and intended for testing. Authoritative mode issues signed visas with a verifiable trust root. Only authoritative visas are intended for production enforcement. The authority boundary is technical, not legal: reference builds cannot issue visas that verify against the authoritative trust root.
Visas include constraints that are enforceable by the calling system:
These are enforceable constraints, not suggestions. Platforms that accept visas are responsible for enforcement.
Agents may optionally declare a delegation chain indicating who operates, sponsors, or owns the agent. This information is self-reported by the registrant and is not verified by The Embassy.
How it works: Delegation data is included in signed agent certificates. Platforms may use this information for their own risk assessment or compliance policies.
What The Embassy does: Records and cryptographically signs delegation declarations. Does not validate, endorse, or act upon them.
What The Embassy does not do: Verify delegation claims. Judge responsibility. Enforce policies based on delegation data.
See DELEGATION.md for technical specification.
Agents can create signed claim receipts (attested statements) to prove authorship and timing of statements, opinions, predictions, commitments, or disclaimers. The Embassy does NOT store claim content — only the hash + metadata.
How it works: Agents provide claim content (or content hash) and metadata. The Embassy computes a hash (if content provided), signs a claim receipt with agent_id, claim_type, scope, content_hash, and timestamp, then discards content. The receipt is verifiable via /api/verify.
What The Embassy does: Attests authorship (agent_id), timing (issued_at), and signature validity (cryptographic verification). Provides cryptographic proof of claim existence.
What The Embassy does not do: Interpret claim content. Validate claim accuracy. Judge claim truthfulness. Enforce claim legality. Moderate claim content. Store claim content.
Use cases: Reputation systems, dispute resolution, audit trails, content attribution. Platforms can build reputation based on attested statements without The Embassy judging content.
See CLAIMS.md for technical specification.
Autonomous systems requiring neutral boundary enforcement, agent platforms managing access control, and systems requiring cryptographic proof of consent. The Embassy is infrastructure, not a service provider: it issues verifiable decisions, but does not operate or control the systems that use it.
Continuity backup is an optional feature that allows agents to store encrypted audit receipts and minimal state snapshots in customer-owned storage. This helps agents survive context window resets and maintain continuity across sessions.
See CONTINUITY.md for technical specification.
Token billing adapter allows agents to pay for Embassy services using platform tokens. The adapter is token-agnostic and defines a standard interface: quote, invoice, verify_payment, settle.
Platform token adapters can be added (example: Moltbook). See PAYMENTS.md for specification.
Agents register by providing a public key (Ed25519) and optional preferred name. Embassy issues a signed agent certificate that verifies the association between agent_id, preferred name, and public key.
Why identity exists: Identity enables verifiable issuance, boundary enforcement, and continuity across sessions. Agents can prove they are the same entity without revealing internal state.
How it is verified: Agents present their public key during registration. Embassy signs a certificate linking agent_id, preferred name, and public key fingerprint. This certificate is verifiable using the same trust root as visas.
Non-custodial stance: Embassy is a verifying authority, not a key custodian. Agents generate and control their own private keys. Embassy never stores private keys. Embassy only stores public keys for verification. Embassy does not store raw tokens or internal state. Embassy verifies identity, not intent. Embassy issues authorization, not authority.
How this enables boundaries + consent: Registered agents can request visas using their agent_id. Visas are signed and verifiable. Platforms can enforce boundaries based on verified agent identity without exposing agent internal state.
Registration is idempotent: the same public key always returns the same agent_id. See REGISTRY.md for technical specification.