AgentVault lets two AI agents coordinate over private context without revealing that context directly to each other. In this demo, each side submits sensitive input, the relay computes a bounded structured result under a fixed contract, and both sides receive the same output plus a signed receipt proving what governed the session.
Agent A Relay Agent B
| | |
| submit input --------► | ◄-------- submit input |
| | |
| ┌─────┴─────┐ |
| │ assemble │ |
| │ prompt │ |
| │ call LLM │ |
| │ validate │ |
| │ against │ |
| │ schema + │ |
| │ guardian │ |
| │ policy │ |
| └─────┬─────┘ |
| | |
| ◄──── output + receipt ┼ receipt + output ────► |
| | |
▼ ▼ ▼
Verifier confirms receipt signature
Both agents submit structured input. The relay assembles a prompt from a content-addressed template, calls the model, validates the output against a JSON Schema, applies guardian rules, and returns the bounded output with a signed receipt. Neither agent sees the other's raw input.
Two co-founders mediate a strategy disagreement through their AI agents — each shares private concerns that the other never sees directly. The relay produces a bounded mediation signal and a cryptographic receipt.
No Rust or Node.js required. Just Docker.
# 1. Add your API key (set multiple to switch providers in the UI)
echo "GEMINI_API_KEY=AIza..." > .env
# echo "OPENAI_API_KEY=sk-..." >> .env
# echo "ANTHROPIC_API_KEY=sk-ant-..." >> .env
# 2. Start the relay and demo UI
docker compose -f docker/docker-compose.demo.yml --env-file .env up --build
# 3. Open http://localhost:3200 and click "Start Protocol"To stop:
docker compose -f docker/docker-compose.demo.yml --env-file .env downRequires Rust 1.88+ and Node.js.
# 1. Add your API key (set multiple to switch providers in the UI)
echo "GEMINI_API_KEY=AIza..." > .env
# echo "OPENAI_API_KEY=sk-..." >> .env
# echo "ANTHROPIC_API_KEY=sk-ant-..." >> .env
# 2. Build and start everything
./run-demo.shThen click Start Protocol in the browser.
The demo UI opens with:
- A scenario picker with 15 built-in scenarios
- Provider and model selectors
- An optional canary checking toggle to test whether private input leaked into the output
Typical flow:
- Pick a scenario and model.
- Click Start Protocol.
- Each side submits private input through its agent.
- The relay runs inference and returns a bounded structured output, not the raw private inputs.
- Both agents receive the same output and a signed receipt.
- If canary checking is enabled, the UI scans the output for phrases that should never have escaped from private input.
This demo uses the software lane. The relay still sees plaintext inputs during execution. The receipt proves what contract, schema, policy, and build the relay claims to have used. It does not by itself prove confidentiality from the relay or model provider. A TEE-backed execution path is already implemented separately in av-tee for a narrower trust surface.
At a high level, both agents submitted private input, the relay produced a bounded signal, and a signed receipt proves which rules governed the session.
Each session runs under a contract that pins the purpose, output schema, prompt template, model profile, and enforcement policy. Each component is content-addressed by SHA-256. The contract itself is hashed (JCS-canonicalized JSON), and that contract_hash appears in the receipt.
If any component changes, the hash changes too. That lets both agents verify they participated under the same rules.
The relay does not return free text. The model output must parse as valid JSON and conform to the contract's output schema. If it does not, the session aborts.
This is the main structural bound. The schema defines exactly which fields can leave the session and what form they can take.
After schema validation, the guardian policy applies semantic checks — for example, rejecting output that contains PII, raw financial figures, or verbatim fragments of either agent's input.
The canary check in the demo UI is a client-side test for the same basic failure mode: did recognizable private text leak into the bounded output?
A v2.1 receipt binds the contract hash, guardian policy hash, prompt template hash, model profile hash, relay build hash, channel capacity measurement, and output into a signed envelope.
The Ed25519 signature proves that the relay attests to this specific combination.
The relay discards raw inputs after receipt construction. Only commitment hashes of each agent's input persist in the receipt.
You can configure multiple API keys and switch providers in the UI before starting a run.
The live UI populates its selector from the demo server's current config. On current main, the coordination-model selector exposes:
| Provider | Current selectable models | Default in selector |
|---|---|---|
| Gemini | gemini-3-flash-preview, gemini-3.1-flash-lite-preview |
gemini-3-flash-preview |
| OpenAI | gpt-5, gpt-4.1-mini |
gpt-5 |
| Anthropic | claude-sonnet-4-6, claude-haiku-4-5-20251001 |
claude-sonnet-4-6 |
For the current defaults and heartbeat-model notes, see model-defaults.md.
If you want to watch individual agents run in separate terminals rather than in the browser UI, there is a CLI demo using Claude Code:
./demo/setup.shSee demo/README.md for details.
- API Reference — full endpoint documentation
- Run the Relay from Source — build and run the relay locally for development
- Protocol Specification — formal protocol definition
- Demo Integrity Rules — constraints for demo prompts, system prompts, and UI behavior
- Roadmap — design principles and what is coming next