Agent Vault Protocol (AVP)

Open standard for AI agent credential security
7 operations · 4 backends · 5 transports · File to hardware · ~500 lines to implement

---

The Problem

Your AI agent stores API keys in plaintext. So does everyone else's.

Framework Storage Method Vulnerability
───────────── ──────────────────────── ──────────────────────────────
OpenClaw ~/.openclaw/keys.json Plaintext JSON, world-readable
ZeroClaw ~/.zeroclaw/credentials ChaCha20, key stored adjacent
PicoClaw Environment variables Visible in /proc to any process
LangChain .env files Plaintext, often committed to git

42,000+ AI agent instances compromised by infostealers in early 2026 (Hudson Rock).
0 open standards exist for AI agent credential management.

The Fix

# ❌ Before — plaintext .env file on diskapi_key=os.environ["ANTHROPIC_API_KEY"]
# ✅ After — AVP vault (same 3 lines, any backend)vault=avp.Vault("avp.toml")
vault.authenticate()
api_key=vault.retrieve("anthropic_api_key")

Same three lines whether your backend is an encrypted file, the OS keychain, a USB secure element, or HashiCorp Vault. Upgrade security without changing agent code.

What is AVP?

AVP is a protocol specification — not a product, not a library, not a SaaS. It defines how an AI agent talks to a credential vault, the same way HTTP defines how a browser talks to a server.

Property	Value
Operations	DISCOVER · AUTHENTICATE · STORE · RETRIEVE · DELETE · LIST · ROTATE
Backends	File (encrypted) · Keychain (OS-native) · Hardware (secure element) · Remote (Vault/AWS/GCP/Azure)
Transports	In-process library · USB serial · Unix socket · HTTP/HTTPS · MCP tools
Hardware Ext.	HW_CHALLENGE (attestation) · HW_SIGN (sign without key export) · HW_ATTEST (compliance proof)
Compliance	SOC 2 · ISO 27001 · FIPS 140-3 Level 3 · PCI DSS 4.0 · GDPR Art. 32 · HIPAA
License	Apache 2.0 — no CLA, no governance committee

Design Principles

1. Backend agnostic — One interface, four security levels. Your agent doesn't know where the secret is stored.
2. Transport agnostic — Same JSON protocol over function calls, USB, sockets, HTTPS, or MCP.
3. Framework agnostic — Works with OpenClaw, ZeroClaw, PicoClaw, LangChain, CrewAI, AutoGen, or your own framework.
4. Graduated security — Start with File, upgrade to Keychain, then Hardware. One migration command per step. Zero code changes.
5. Deliberately simple — 7 operations (vs. PKCS#11's 60+). ~500 lines for a minimal conforming implementation.

Graduated Security Model

┌─────────────────────────────────────────────────────────┐
│ AVP Interface │
│ (same 7 operations, same code) │
├──────────┬──────────┬──────────────┬────────────────────┤
│ File │ Keychain │ Hardware │ Remote │
│ AES-256 │ OS-native│ Secure elem. │ Vault/AWS/GCP │
│ ChaCha20│ Touch ID │ Keys in │ Azure KV │
│ │ DPAPI │ silicon │ │
├──────────┼──────────┼──────────────┼────────────────────┤
│ Basic │ Strong │ Maximum │ Centralized │
│ │ Free │ FIPS 140-3 │ Team mgmt │
└──────────┴──────────┴──────────────┴────────────────────┘
Fallback chain: Hardware → Keychain → File (automatic)

Security Comparison

Threat	File	Keychain	Hardware	Remote
Infostealer malware	✗	✓	✓	✓
Credential phishing	✗	✓	✓	✓
Full host compromise	✗	✗	✓	⚠
Memory dump	✗	✗	✓	⚠
Physical device theft	—	—	✓	—
Supply chain attack	✗	✗	✓	⚠
Insider threat	✗	⚠	✓	⚠

Only hardware protects against all seven threat categories.

Quick Start — 5 Minute Migration

Step 1: Store your existing secret

avp store anthropic_api_key "sk-ant-..." --backend file

Step 2: Migrate to OS keychain (free upgrade, blocks 90% of attacks)

avp migrate --from file --to keychain

Step 3: When ready, migrate to hardware (FIPS 140-3 Level 3)

avp migrate --from keychain --to hardware

Each migration is verifiable — the CLI compares source and destination, and only deletes the source after confirmation.

Specification

📄 Read the full specification →

The spec is written as a normative RFC-style document with:

• RFC 2119 keywords (MUST, SHALL, SHOULD, MAY)
• Formal ABNF syntax for all message formats
• Conformance levels (Core, Standard, Full, Hardware)
• Complete security considerations (Section 11)
• Migration procedures (Section 12)
• Compliance mapping for 7 regulatory frameworks (Section 13)

Repository Structure

avp-protocol/spec
├── README.md ← you are here
├── LICENSE ← Apache 2.0
├── spec/
│ └── avp-spec-v0.1.0.md ← normative specification
├── assets/
│ └── avp-shield.svg ← logo
├── presentations/
│ ├── AVP-Presentation-EN-v0.1.0.pptx
│ └── AVP-Presentation-FR-v0.1.0.pptx
└── briefs/
└── zeroclaw-secretbackend-brief.md

Implementations

Status: Pre-release. Reference implementations are in development.

Language	Repo	Status	Conformance
Rust	avp-protocol/avp-rs	🔨 In progress	Full + Hardware
TypeScript	avp-protocol/avp-ts	📋 Planned	Standard
Python	avp-protocol/avp-py	📋 Planned	Standard
Go	—	Looking for maintainer	—

Want to implement AVP in your language? See Contributing. A conforming AVP Core implementation requires only STORE and RETRIEVE — roughly 500 lines of code.

Framework Integrations

Framework	Integration	Status
ZeroClaw	SecretBackend trait	Brief ready
OpenClaw	Credential provider	Brief in progress
LangChain	Secret manager	Planned
CrewAI	Credential store	Planned
MCP-compatible agents	MCP tool server	Spec complete (Section 8.5)

For CISOs

AVP with the Hardware backend provides:

• SOC 2 Type II — CC6.1 logical access controls ✓
• FIPS 140-3 Level 3 — Tamper-resistant cryptographic module ✓
• PCI DSS 4.0 — Requirement 3 cryptographic key management ✓
• GDPR Article 32 — Appropriate technical measures ✓
• HIPAA — Technical safeguards for ePHI ✓
• HW_ATTEST — Cryptographic proof for auditors (not screenshots) ✓

Contributing

We need:

• 🔍 Reviewers — Read the spec. Open issues. Challenge design choices. Every issue makes the standard stronger.
• ⌨️ Implementors — Pick a language. Implement AVP Core (STORE + RETRIEVE). ~500 lines. We'll list conforming implementations.
• 🔌 Integrators — Maintain an AI agent framework? Implement the AVP trait/interface. We have briefs ready.
• 🛡️ Security auditors — The spec covers crypto, hardware auth, and session management. We need expert eyes on Sections 10 and 11.

How to Contribute

1. Read the specification
2. Open an issue for questions, feedback, or proposals
3. Submit a PR for spec edits (typos, clarifications, normative changes)
4. Discuss in GitHub Discussions for design conversations

No CLA required. No governance committee — for now, it's rough consensus and running code.

Roadmap

• Specification v0.1.0 (draft)
• Presentation deck
• ZeroClaw integration brief
• Rust reference implementation (avp-rs)
• OpenClaw integration brief
• Security audit by independent researcher
• Specification v0.2.0 (incorporating community feedback)
• Hardware reference device announcement
• Conference talks (DEF CON, Black Hat, AI Engineer Summit)
• CNCF / OpenSSF working group proposal

FAQ

Q: How is this different from HashiCorp Vault / AWS Secrets Manager?
A: Those are backends. AVP is the protocol that sits in front of them. AVP can use HashiCorp Vault as a Remote backend while also supporting local encrypted files, OS keychains, and hardware secure elements — all through the same interface.

Q: Do I need special hardware?
A: No. Start with the File backend (backward compatible with existing frameworks) or Keychain backend (free, already on your OS). Hardware is optional and additive.

Q: What about MCP?
A: AVP includes an MCP transport binding (Section 8.5). It exposes 7 MCP tools — one per operation. Any MCP-compatible agent (Claude, ChatGPT with actions, Cursor) can use AVP without a dedicated SDK.

Q: Is this production-ready?
A: The spec is v0.1.0 draft. We're soliciting community review before stabilizing. The protocol design is complete, but normative details may change based on feedback.

Q: Can I use this commercially?
A: Yes. Apache 2.0. No restrictions, no CLA, no royalties.

---

Secrets belong in silicon, not in config files.

Read the Spec · Open an Issue · Discuss