Open standard for AI agent credential security
7 operations · 4 backends · 5 transports · File to hardware · ~500 lines to implement
-00D4AA?style=flat-square){kind=icon}
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.
# ❌ Before — plaintext .env file on disk
api_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.
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 |
- Backend agnostic — One interface, four security levels. Your agent doesn't know where the secret is stored.
- Transport agnostic — Same JSON protocol over function calls, USB, sockets, HTTPS, or MCP.
- Framework agnostic — Works with OpenClaw, ZeroClaw, PicoClaw, LangChain, CrewAI, AutoGen, or your own framework.
- Graduated security — Start with File, upgrade to Keychain, then Hardware. One migration command per step. Zero code changes.
- Deliberately simple — 7 operations (vs. PKCS#11's 60+). ~500 lines for a minimal conforming implementation.
┌─────────────────────────────────────────────────────────┐
│ 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)
| 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.
Step 1: Store your existing secret
avp store anthropic_api_key "sk-ant-..." --backend fileStep 2: Migrate to OS keychain (free upgrade, blocks 90% of attacks)
avp migrate --from file --to keychainStep 3: When ready, migrate to hardware (FIPS 140-3 Level 3)
avp migrate --from keychain --to hardwareEach migration is verifiable — the CLI compares source and destination, and only deletes the source after confirmation.
📄 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)
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
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 | 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) |
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) ✓
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.
- Read the specification
- Open an issue for questions, feedback, or proposals
- Submit a PR for spec edits (typos, clarifications, normative changes)
- Discuss in GitHub Discussions for design conversations
No CLA required. No governance committee — for now, it's rough consensus and running code.
- 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
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.