01 — Executive Summary

02 — The Problem: AI Agents & the God Key

The AI agent ecosystem is exploding. Gartner projects that 40% of enterprise applications will embed task-specific AI agents by end of 2026, up from less than 5% in 2025. These agents need credentials—API keys, database passwords, OAuth tokens—to do their jobs.

Today, the default approach is terrifying:

1. Paste the API key into an environment variable and hope nothing leaks it
2. Give the agent full access—there's no mechanism for scoped, temporary permissions
3. Zero audit trail—no record of which agent used which credential, when, or why
4. No rotation—keys sit unchanged for months or years because rotation is painful
5. No revocation—if an agent is compromised, there's no kill switch

The Five Critical Gaps

03 — Market Landscape

The AI agent security market is nascent but rapidly forming. Analysts project the agentic AI economy at $2.6–4.4 trillion, and security is the critical infrastructure layer beneath all of it.

Existing Players

04 — The Davy.Locker Solution

Davy.Locker is a credential security runtime—not a password manager. The difference is fundamental:

The Nine Pillars

05 — Architecture: The Bank Model

To understand Davy.Locker, think of it as a bank—not metaphorically, but structurally. Every component in the system maps directly to how a physical bank secures, transports, and monitors access to valuables. This model governs the architecture, the product tiers, and the security protocols.

The Building: Component Map

The Armored Truck: Escorted Credential Delivery

This is the core of what makes Davy.Locker different from a password manager. Credentials aren't handed to agents—they're escorted. Like an armored truck service, the credential is loaded into a secure transport, driven to the destination, used under supervision, and then destroyed on the return trip. The agent never holds the credential in memory.

The Lockdown: Bank Robbery Response

When something goes wrong—an agent starts behaving erratically, an unusual volume of requests hits a credential, or an unauthorized access attempt is detected—the bank goes into lockdown. The Kraken initiates the emergency protocol:

Changing the Vault Combination

A real bank doesn't keep the same vault combination for months. The combination changes regularly—and if there's any hint of a breach, it changes immediately. Davy.Locker works the same way.

Because the proxy is the single injection point for all credentials, rotating a key requires zero changes anywhere else. No config files to update, no servers to redeploy, no agents to reconfigure. The vault combination changes, and every authorized agent automatically gets the new key on their next request.

Your Branch vs. Headquarters: The Business Model

The bank model extends naturally to the product tiers. The distinction isn't between a worse bank and a better bank—it's between running your own branch and having access to the full banking network with a headquarters watching over it.

Your Own Branch (Free Tier)

You build your own bank on your own property. You hire the tellers, install the vault, mount the security cameras, and set the rules. It's fully operational—same vault, same locks, same armored trucks as any bank in the world. The only difference: you're a single branch. You see what happens inside your four walls, and you manage it yourself.

• The vault: Full bank-grade encryption (AES-256-GCM, Argon2id)—identical to what the largest banks use
• The teller: Complete USE_ONLY proxy—agents get served without ever going behind the counter
• The cameras: Full audit log on this branch—every transaction recorded and searchable
• The safe deposit boxes: Unlimited credentials, unlimited agents, all four types (API keys, logins, secure notes, files)
• The property: Runs on your infrastructure—laptop, VPS, AWS, Docker, Kubernetes—wherever your agents live
• The overhead: No account required. No cloud dependency. No monthly fee. You own it.

This is a real, fully operational bank. Not a demo, not a trial, not a limited version. Your credentials are as secure here as they would be in any configuration.

The Banking Network & Headquarters (Paid Tier — Mission Control)

Your operation grows. You've got branches in multiple locations—credentials on your dev laptop, a staging server, two production servers, and your co-founder's machine. Each branch runs its own vault, its own proxy, its own audit log. But now you need something no single branch can provide: a headquarters that sees everything.

• Central command: One dashboard connecting every branch. See all vaults, all grants, all agents—everywhere—from one screen
• The Kraken at HQ: AI security monitoring doesn't just watch one branch—it correlates patterns across all branches. An anomaly at Branch A + an unusual request at Branch B might mean nothing alone, but together they tell a story
• Cross-branch management: Rotate a credential once at HQ, every branch gets the new key instantly
• Staffing (team access): Invite team members, assign roles, share vaults with per-person permissions. Your co-founder gets access to the deploy keys; the intern doesn't
• Auto-rotation: Scheduled key changes across all branches simultaneously. Kraken-triggered emergency rotation that locks down every branch in seconds
• The alert system: Suspicious activity at any branch triggers Slack, email, or webhook notifications to the right people immediately
• Compliance & reporting: Consolidated audit trail across the entire network. One-click export for compliance evidence

Daily Operations: A Day at the Bank

To understand how Davy.Locker works in practice, walk through a full day at the bank—from the moment the doors open to close of business and beyond.

Opening: The Developer Unlocks the Vault

The bank doesn't operate 24/7 without supervision. When the developer starts their session, they unlock the vault with their master password. This derives the encryption key via Argon2id and loads the vault into memory. The bank is now open for business. Tellers are at their windows. Cameras are rolling.

The Regular Customer: A Trusted Agent

A trusted agent—say, a deployment bot—walks through the front door. It's been here before.

1. ID check at the door. The agent presents its session token. The bank verifies: yes, this is deploy-bot, authenticated and recognized.
2. Walks up to the teller. "I need to deploy to Vercel." The teller checks the ledger: deploy-bot has a persistent USE_ONLY grant for the Vercel token. Risk tier: medium. It was approved last week and set to persist.
3. The teller retrieves the credential. Goes to the vault, pulls the Vercel token from Safe Deposit Box "Deploy Keys." The agent waits at the window—it never goes behind the counter, never sees the vault.
4. Armored truck dispatched. The teller doesn't hand the key to the agent. Instead, the proxy loads the credential into the outbound HTTP request—injecting the Authorization: Bearer header directly. The agent's request goes to Vercel fully authenticated.
5. Delivery confirmed. Vercel processes the deployment and returns a response. The response passes through the lens—in this case, a "Deploy Only" lens that shows deployment status but filters out team billing data and admin settings.
6. Transaction logged. The security camera captures: "10:23 AM — deploy-bot — USE_ONLY — Vercel token — POST /v1/deployments — 200 OK."
7. Agent leaves. The credential was never in its hands. The truck returned empty. The lobby is clear.

The New Customer: A First-Time Agent

A new agent shows up—one that's never accessed this credential before. This is a code analysis agent that wants to query the GitHub API.

1. ID check at the door. The agent authenticates with a fresh session token. The bank recognizes the agent identity but sees no existing grant for any GitHub credentials.
2. The teller escalates. This requires approval. A notification goes to the developer: "research-agent wants to use your GitHub token (USE_ONLY, session-scoped)."
3. The developer approves. One tap: [Allow This Session]. A session-scoped grant is created—it will auto-expire when the agent's session ends.
4. The system learns. After the session, the bank asks: "Always allow research-agent to access GitHub (read-only)?" If the developer says yes, next time it's automatic. Just like how your phone stops asking about Bluetooth after the third time.

The VIP Transaction: A High-Risk Credential

An agent needs to process a payment through Stripe. This credential is tagged Critical risk tier.

1. The teller sees the red flag. Critical-tier credentials always require explicit approval, regardless of any previous grants. No auto-approve. No "remember this." Every single time.
2. Full verification. The developer gets a detailed prompt: "payment-agent wants to use your Stripe secret key (USE_ONLY). This is a CRITICAL credential. Approve for this request only?"
3. The developer reviews and approves. The transaction proceeds through the armored truck model. The response lens filters the Stripe response to show transaction confirmation but redact full card numbers and bank account details.
4. Double-logged. Critical transactions get enhanced audit entries: full request/response metadata, the specific approval timestamp, and the developer who approved it.

The Restricted Customer: A Blocked Agent

An agent requests access to the AWS root credential. Its grant is set to BLOCKED.

1. The teller says no. Immediately. No escalation, no notification, no negotiation. The agent receives an access-denied response.
2. Still logged. The attempt is recorded: "11:47 AM — analytics-bot — BLOCKED — AWS root — Access denied." Even denied transactions are on camera.
3. Pattern watched. If the same agent repeatedly hits BLOCKED credentials, the Kraken flags it: "analytics-bot has attempted to access 3 restricted credentials in the last hour. Investigate?"

After Hours: The Kraken's Patrol

The bank closes for the night (the developer locks the vault or the session ends). But the Kraken doesn't sleep. On the paid tier, it continues monitoring:

• Reviewing the day's tapes. Scanning the full audit log for patterns: unusual access times, request volume anomalies, credential access outside established baselines.
• Checking the safe deposit boxes. Are any credentials approaching rotation age? Has any API key been unchanged for 90+ days? Are there grants that haven't been used in months?
• Cross-branch analysis. If you're on Mission Control, the Kraken correlates patterns across all your branches. A spike at one location plus an unusual request at another might be coincidence—or it might be a coordinated probe.
• Morning briefing. When the developer opens up the next day, the Kraken has a summary ready: "All clear. 3 credentials due for rotation. 1 grant unused for 60 days—consider revoking. Security score: A-."

06 — The Credential Security Runtime

Permission Model

Grant Scopes

Risk Tiers

Every credential is assigned a risk tier—either automatically from the service catalog or manually by the user:

Response Lenses

Lenses filter API responses before they reach the agent—not just "can you access this service" but "what can you see inside it."

07 — The Least-Context Principle

Davy.Locker applies the principle of least privilege to credentials—agents only get the specific key they need, scoped to the exact action. But the same principle applies to something even more fundamental: the information agents are given to work with.

Context Is an Attack Surface

When an AI agent starts a task, it's typically loaded with context: conversation histories, memory files, project documentation, architectural notes, and credentials. The more context an agent has, the more information it could accidentally expose, misinterpret, or leak.

This isn't hypothetical. As AI workflows scale, developers routinely feed agents context from dozens of past sessions, multiple project architectures, and unrelated operational knowledge. The agent doesn't know what's relevant. It processes everything—and that creates two distinct problems:

Less Context, Better Agents

This is counterintuitive. The instinct is to give agents more context so they have everything they might need. But the evidence points the other way:

This maps directly to Davy.Locker's architecture:

Scoped Knowledge Grants

Davy.Locker's Portable AI Context Vault (Pillar 8) implements this as scoped knowledge grants—the same permission model used for credentials, applied to information:

• Task declaration: When an objective is set ("deploy the webinar worker to Railway"), Davy.Locker determines the minimum context required: Railway config, Dockerfile, queue setup, and the relevant deployment SOP. Nothing else loads.
• Knowledge scoping: Context files are organized in the vault the same way credentials are—by project, by domain, by sensitivity level. Agents receive grants to specific knowledge scopes, not blanket access to everything.
• Automatic exclusion: Proprietary frameworks, client data, unrelated project architectures, and completed experiment histories stay locked in the vault unless explicitly granted. The agent's context window stays clean.
• Session isolation: Each agent session starts with a clean context tailored to its objective. When the session ends, that context evaporates. No cross-contamination between tasks.

08 — The Kraken: AI-Powered Security Officer

The Kraken is Davy.Locker's built-in AI Chief Security Officer. It continuously monitors audit logs, credential health, and agent behavior to detect threats before they become breaches.

Core Capabilities

09 — Auto-Rotation & Lockdown Protocol

Credential rotation is the most neglected security practice because it's painful. Davy.Locker makes it automatic.

Why Rotation Is Trivial With a Proxy

Because agents never hold raw credentials, rotating a key requires zero changes to any agent, config file, or deployment. The proxy is the single injection point:

Three Rotation Modes

The Lockdown Protocol

When the Kraken detects a breach, the lockdown sequence executes automatically:

1. Slam the windows — Revoke the compromised agent's grant immediately
2. Re-roll the vault keys — Auto-rotate the affected credential via provider API
3. Quarantine the suspect — Flag the agent, block its session token
4. Update the innocents — All other agents get the new key automatically through the proxy
5. File the report — Full incident timeline, audit log, and response summary

10 — Product Tiers: Credit Union vs. Mission Control

The Free Tier: "The Credit Union"

Small, local, yours. Full security, no compromise. The complete credential security runtime running on your own infrastructure. No account required, no cloud dependency, no tracking.

• Full AES-256-GCM encrypted vault with all credential types
• USE_ONLY proxy with scoped grants and response lenses
• Complete audit log (local)
• Unlimited agents, unlimited credentials
• Self-hosted: laptop, VPS, AWS, Docker—anywhere
• Open-source SDK (@davy/agent-auth)

The Paid Tier: "Mission Control"

The international bank. One command center for your entire agent fleet across every server, every project, every team member.

• Everything in Free, plus:
• Cloud dashboard—one pane of glass for all instances
• Multi-server sync—connect all self-hosted nodes into one view
• The Kraken—AI security monitoring, anomaly detection, auto-response
• Auto-rotation—scheduled, triggered, and one-click
• Team sharing—shared vaults, role-based access, invite members
• Security score—real-time posture grade with recommendations
• Alert system—Slack, email, and webhook notifications
• Usage analytics—which agents use what, how often, when
• Compliance export—one-click audit reports

11 — Feature Comparison

12 — Security & Cryptography

Cryptographic Foundations

Zero-Knowledge Architecture

• Master password never leaves the device. It derives the encryption key locally via Argon2id, then is discarded.
• Vault data is encrypted at rest. The file on disk is AES-256-GCM ciphertext. Without the master password, it's indistinguishable from random noise.
• No telemetry, no cloud sync (free tier). The application runs entirely locally with no outbound connections.
• Open-source cryptography. All crypto libraries are well-audited, NIST-approved, open-source implementations. No proprietary cryptographic code.

Threat Model

13 — Compliance & Liability

Zero-Knowledge = Minimal Compliance Burden

Because Davy.Locker's free tier is entirely self-hosted with zero-knowledge encryption, the compliance burden falls on the infrastructure operator (the developer), not on Davy.Locker as a company. This is the same model used by KeePass, Bitwarden self-hosted, and Signal.

14 — Roadmap

15 — Competitive Position

The Security Spectrum: Where Everyone Banks

Using the bank model, it's easy to see where each approach to credential security falls on the spectrum—and how far most developers have to travel to reach real security:

Feature Comparison