# Competitive Landscape — AI Agent Credential Security (March 2026)

> Research conducted 2026-03-26. Referenced from LEDGER.md.

## The three security models

The industry is converging on three distinct models. kv uses Model 2.

**Model 1: SDK Retrieval** — agent gets the plaintext secret
- 1Password SDK: `secrets.resolve()` returns the actual API key to agent memory
- HashiCorp Vault: agent retrieves credential, holds in memory
- Doppler: injects env vars, agent has plaintext access
- **Weakness:** Once the agent has the key, it's in memory. One prompt injection
  and the key is compromised. "Traditional vaults protect credentials at rest,
  but once an agent retrieves a credential, the vault's protection ends."

**Model 2: Proxy/Daemon** — agent never possesses the key
- **kv-secrets** (`kv_api`): Unix socket daemon makes HTTP call, key stays in daemon
- **AgentSecrets** (Go): HTTP proxy on localhost:8765, injection headers
- **OneCLI** (Rust): HTTP gateway swaps placeholder keys for real keys
- **Security property:** The key value never enters agent memory, never appears
  in chat logs, never touches the filesystem. The agent operates the key, it
  doesn't consume it.

**Model 3: Signing-only** — key can only perform one operation
- ssh-agent: private key can only sign messages, never be exported
- gpg-agent: same model for GPG operations
- **kv_api is this model applied to API calls.** The daemon can only make HTTP
  calls to known providers. It can't export the key value.

## kv_api IS the ssh-agent model for API keys

ssh-agent's security comes from:
1. Keys held in memory only (never written to disk in plaintext) — kv does this
2. Keys can never be exported, only used for signing — kv_api: key never leaves daemon
3. PR_SET_DUMPABLE prevents process memory reads — kv does this
4. Destination constraints restrict which hosts a key can auth to — kv's provider registry

kv_api implements exactly the ssh-agent security model, applied to API credentials
instead of SSH keys. The industry validated this independently.

## Why kv_run exists (and competitors don't have it)

kv_api handles HTTP API calls — the key is just an HTTP header, the daemon can
make the call, the process never needs the key.

But some processes genuinely need the credential value in their environment:
- **Database connections** — Postgres, MySQL, Redis, MongoDB use their own wire
  protocols. The client library needs the password in memory to authenticate.
- **Cloud SDKs** — AWS boto3, GCP, Azure SDKs read env vars like AWS_SECRET_ACCESS_KEY
  and handle auth internally.
- **Non-HTTP protocols** — SMTP, AMQP, FTP, custom TCP.
- **Legacy apps** — apps that read env vars directly and can't be modified.

AgentSecrets and OneCLI are proxy-only — they can't help with these cases.
kv_run exists for this reason. It's the fallback for when the process genuinely
needs the credential, with sandbox layers to mitigate the risk.

**Product hierarchy:**
- kv_api = primary path (true isolation, key never leaves daemon)
- kv_run = when the process genuinely needs the credential (databases, SDKs, legacy)

## Direct competitors

| Feature | kv-secrets | AgentSecrets | OneCLI |
|---------|-----------|--------------|--------|
| Language | Python | Go | Rust |
| Proxy type | Unix socket daemon | HTTP proxy (localhost:8765) | HTTP gateway |
| Key storage | Encrypted file vault (.enc) | OS keychain | AES-256-GCM file + dashboard |
| Encryption | ChaCha20-Poly1305 | X25519 + AES-256-GCM | AES-256-GCM |
| Auth providers | 5 hardcoded | 6 auth styles (dynamic) | Host/path pattern matching |
| MCP support | **Native** (MCP server) | Yes (`agentsecrets mcp`) | No |
| Subprocess execution | Yes (`kv_run`) | No (proxy only) | No (proxy only) |
| Passphrase/2FA | Yes (PBKDF2 + TOTP) | No (OS keychain) | No |
| SSRF protection | **No** | Yes (blocks private IPs) | Unknown |
| Audit logging | **No** | Yes (JSONL, key names only) | Yes (via dashboard) |
| Claude Code hooks | Yes | No | No |
| Cloud sync | Planned (zero-knowledge) | Yes (zero-knowledge) | Via PostgreSQL |
| Team features | Planned | Yes (encrypted sharing) | Via dashboard |
| Dependencies | cryptography (1 dep) | Go stdlib | Rust + PGlite/Postgres |

## Where kv wins

1. **MCP-first.** Built for MCP from day one. Native to Claude Code and Cursor.
2. **Interface barrier.** Passphrase + TOTP — vault can't unlock without human interaction.
3. **kv_run.** Only tool that supports non-HTTP protocols (databases, SDKs, legacy).
4. **Zero dependencies.** One Python dep. Works on Chromebooks, minimal VMs, CI.
5. **First mover.** Built before this category existed as a category.

## Where kv needs to catch up

1. **No SSRF protection.** Fragile if custom providers are added later.
2. **No audit logging.** Every competitor has structured audit trails.
3. **Hardcoded provider registry.** Need config-based provider definitions.
4. **No OS keychain integration.** Tradeoff: portability vs. system integration.
5. **Cloud sync not shipped.** Client code exists but no server.

## Strategic implications

1. **kv_api IS the product.** Lead with it. kv_run is the migration path.
2. **MCP is the moat.** HTTP proxies require routing gymnastics. MCP is native.
3. **Dynamic providers are table stakes.** Config-based, not code changes.
4. **Audit logging is expected.** Every competitor has it.

## Sources

- [SSH Agent Explained](https://smallstep.com/blog/ssh-agent-explained/)
- [OpenSSH agent restriction](https://www.openssh.org/agent-restrict.html)
- [1Password SDK AI Agent Tutorial](https://developer.1password.com/docs/sdks/ai-agent/)
- [1Password Unified Access Launch](https://1password.com/press/2026/mar/1password-unified-access)
- [How 1Password secures agent architectures](https://1password.com/blog/secure-ai-agent-architectures)
- [AgentSecrets — Zero-Knowledge Secrets for AI Agents](https://agentsecrets.theseventeen.co/)
- [AgentSecrets GitHub](https://github.com/The-17/agentsecrets)
- [OneCLI GitHub](https://github.com/onecli/onecli)
- [Agentic Secrets Infrastructure: The Missing Layer](https://dev.to/the_seventeen/agentic-secrets-infrastructure-the-missing-layer-in-every-ai-agent-stack-42li)
- [HashiCorp Vault AI Agent Identity](https://developer.hashicorp.com/validated-patterns/vault/ai-agent-identity-with-hashicorp-vault)
- [The pitfalls of using ssh-agent](https://rabexc.org/posts/pitfalls-of-ssh-agents)
