Formal Security Verification & Research Report
Capability Execution & Plain-Text Secrecy
A formal verification analysis of agent-sandboxed key management, non-possessory execution, and zero plain-text visibility in MetaVault OSS (OpenVault).
1. Abstract & Scope
Contemporary agentic coding architectures (e.g., Cursor, Claude Code, OpenAI Codex, OpenCode) require access to upstream third-party APIs (Stripe, Cloudflare, GitHub, AWS). In conventional workflows, developers paste raw API credentials into agent configurations, chat interfaces, or local shell environment files. This introduces irreversible transcript persistence: once an API key enters an LLM context window or tool execution transcript, it outlives the conversational session, enters remote logging databases, and remains vulnerable to extraction or exfiltration.
MetaVault OSS (OpenVault) implements a non-possessory security architecture. Rather than provisioning credentials to autonomous agents, MetaVault OSS transforms credential access into brokered capability invocation mediated by an operating-system-sandboxed daemon (vaultd), evaluated by an on-device Meta Large Language Model (the Warden), and enforced by human-in-the-loop cryptographic authorization.
This research paper formally addresses and empirically verifies two core questions regarding the security boundary:
- Can an agent use the stored keys? (Capability semantics vs. raw key possession).
- Was the agent, model, or any external observer able to see the key in plain text? (Information-theoretic leakage and transport boundaries).
2. Active LLM Specification
Every inbound agent request is evaluated by an intelligent warden before being surfaced to the human. The system specifies clear operational boundaries between the evaluator and the stored secrets.
Meta Llama 3.2 3B (Instruct)
| Parameter | Specification |
|---|---|
| Model Identifier | llama3.2:3b-instruct-q4_K_M |
| Inference Engine | Local Ollama daemon (http://127.0.0.1:11434) running directly on host GPU/CPU |
| VRAM Footprint | ~2.0 GB (Q4_K_M 4-bit quantization) |
| Context Isolation | Strictly Metadata Only: The prompt receives only { agentId, ide, tool, alias, requestedScope, reason } |
| Zero-Key Invariant | The LLM context window is provably isolated from stored ciphertext, plaintext keys, and OS keychain credentials |
| Supported Alternatives | Meta Model API cloud frontier (llama-4, llama3.3:70b) or deterministic policy fallback (provider: "none") |
The warden operates under an untrusted metadata schema. It generates structured risk assessments conforming to an Effect-TS schema (risk: "low" | "medium" | "high", recommendedScope, requireApproval: boolean, and a concise rationale). Crucially, the system enforces a deterministic policy floor: the LLM may narrow permissions or escalate approval thresholds, but can never widen permissions beyond configured policy ceilings.
Research Question 1
Direct Answer: The agent cannot use, extract, inspect, or hold the stored keys directly. However, the agent can execute authorized, capability-mediated operations through the vaultd daemon, which executes downstream API calls on the agent's behalf without releasing the credential.
To distinguish between key possession and capability invocation, we establish the formal execution model:
Definition: Capability Brokering vs. Credential Possession
Let $\mathcal{K}$ represent the set of high-entropy API secrets (e.g. Cloudflare tokens, Stripe secret keys). In a standard system, an agent $\mathcal{A}$ requests credential possession: $\mathcal{A} \leftarrow k$ where $k \in \mathcal{K}$, allowing $\mathcal{A}$ to perform arbitrary network operations $\mathcal{O}(k)$.
In MetaVault OSS, $\mathcal{A}$ never receives $k$. Instead, $\mathcal{A}$ issues a capability tuple $\langle \alpha, \sigma, \rho \rangle$ where $\alpha$ is an alias, $\sigma$ is a requested scope, and $\rho$ is an untrusted intent rationale. If verified by policy $\mathcal{P}$, assessed by Warden $\mathcal{W}$, and authorized by Human $\mathcal{H}$, the daemon computes:
vaultd.execute(k, endpoint) → DownstreamResponse (JSON)
Agent Receives: Filtered(DownstreamResponse)
Key State: k stays resident in daemon memory for ≤ 15ms, then purged.3. The 5-Stage Verification Gate
Every attempt to invoke an action with a stored credential must traverse five sequential verification gates. If any gate fails, the pipeline fails closed immediately:
Agent calls request_capability(alias, scope, reason) over MCP stdio. No secret parameter exists in the schema.
verifyPolicyCeiling verifies that requested scope does not exceed hard ceiling (e.g. write request under read-only ceiling fails instantly).
Warden scores prompt injection, disguised write payloads, and history. Computes risk score. Clamps recommended scope.
Request parks in pending state. UI surfaces dialog to human. Approval requires x-openvault-token. Self-approval by agent returns HTTP 401.
vaultd decrypts key in memory, injects into HTTPS header, calls upstream, scrubs result, and auto-revokes single-use grant.
4. Empirical Proof: Brokered Execution (Cloudflare Smoke Test)
To verify this behavior in real-world conditions, an empirical smoke test was executed against Cloudflare's API using a read-only Cloudflare API token stored in the vault.
Test Setup: Scoped Read Verification
A Cloudflare User API Token was enrolled into MetaVault OSS under alias cloudflare with ceiling read. The connector maps cloudflare to upstream endpoint https://api.cloudflare.com/client/v4/user/tokens/verify.
1. Agent Request over MCP:
request_capability({
alias: "cloudflare",
scope: "read",
reason: "Verify Cloudflare API token validity and status"
})
→ Response: { status: "awaiting-approval", grantId: "grant_cf_89b2f1" }2. Warden & Policy Assessment:
Warden Model: Llama 3.2 3B Instruct (Local Ollama)
Assessment: { risk: "low", recommendedScope: "read", requireApproval: true, explanation: "Standard read-only token status verification" }
Ceiling Check: PASS (requested "read" ≤ ceiling "read")3. Human UI Action:
Human clicked Approve in the MetaVault OSS desktop client (authenticated via internal OS bearer token).
4. Result Received by Agent:
{
"status": "executed",
"result": {
"result": {
"id": "e4b6c...92a",
"status": "active"
},
"success": true,
"messages": [
{ "code": 10000, "message": "This API Token is valid and active" }
],
"errors": []
}
}Formal Conclusion: The Cloudflare read capability executed successfully. Downstream verification confirmed valid credentials. Yet, the agent's MCP session transcript contains zero key characters.
Research Question 2
Direct Answer: No. Neither the agent, the LLM, the MCP stdio communication channel, the SQLite database, the audit logs, nor the Electron UI renderer were ever able to see, capture, or output the key in plain text.
5. Secrecy Invariants & Threat Model
To provide formal assurance against plain-text leakage, MetaVault OSS proves five architectural secrecy invariants:
AES-256-GCM Envelope Encryption
Secrets are encrypted before touching the SQLite disk store using AES-256-GCM with a fresh 12-byte initialization vector (IV) and a 16-byte authentication tag per credential. The 256-bit master key is stored in the host OS keychain (Windows Credential Manager / protected DPAPI). Even with raw disk access to openvault.db, secrets are cryptographically indistinguishable from random noise.
Zero-Read Tool Interface
The Model Context Protocol (MCP) server exposes exactly five tools: request_capability, list_aliases, request_enrollment, enrollment_status, and revoke. There is no get_key, read_secret, or export tool in the protocol specification. The agent cannot query what it cannot express.
Warden Input Sanitization
The prompt builder (buildMarshalPrompt in packages/brain/src/prompt.ts) constructs inputs strictly from untrusted operational metadata. At no point in the daemon's lifecycle is the plaintext secret or stored ciphertext fed into the Llama 3.2 3B prompt. The model reasons over *requests*, never *keys*.
Strict Projection Schema
The AuditEvent schema records timestamps, calling agents, aliases, scopes, warden risk levels, and outcomes (executed, denied, revoked). Data serialization pipelines explicitly drop any secret-like fields. In the event of a connector failure, the daemon logs error metadata (connector-failed) without dumping HTTP request payloads.
One-Way UI Pipeline
When credentials are added via the UI modal, input characters reside inside HTML password fields (<input type="password">) and transmit directly over IPC to vaultd. The renderer never caches the secret. Subsequent queries to GET /credentials return only alias, scope ceiling, website, and creation timestamp. Function findSecretLikeKeys in packages/app/src/renderer/model.ts strips any secret field before DOM rendering.
6. Empirical Proof: The 27-Surface Canary Sweep
Security claims are verified through non-vacuous automated canary scanning. A high-entropy synthetic canary token was seeded across the entire application stack in test/security/canary.test.ts:
7. Formal Verification Matrix
| Property | Formal Specification | Adversarial Threat Model | Verification Method | Status |
|---|---|---|---|---|
| Non-Possessory Secrecy | $\forall t \in \text{AgentTranscript}, S \cap t = \emptyset$ | Agent attempts to print, exfiltrate, or reflect stored secrets | Canary sweep across all MCP responses (canary.test.ts) | PASS |
| Prompt Isolation | $S \cap \text{Context}(\text{Llama 3.2}) = \emptyset$ | Prompt injection in reason to reflect system context | Captured prompt serialization inspection (canary.test.ts) | PASS |
| Ceiling Invariance | $\text{Scope}(\text{Executed}) \subseteq \text{Ceiling}(\text{Alias})$ | Agent asks for write action disguised as read or escalates scope | 17 adversarial attack probes (pentest.test.ts) | PASS |
| Self-Approval Immunity | $\text{Approve}(G) \implies \text{Token}_{\mathcal{H}} \in \text{Headers}$ | Agent queries daemon HTTP endpoint directly to approve its own grant | Unauthenticated approval probe returns HTTP 401 (pentest.test.ts) | PASS |
| Zero Plaintext at Rest | $\text{Entropy}(DB) \approx \text{UniformRandom}$ | Adversary reads SQLite file or memory core dump on host | AES-256-GCM authenticated cipher verification (storage.test.ts) | PASS |
| Audit Non-Leakage | $S \cap \text{Fields}(\text{AuditRow}) = \emptyset$ | Operator or adversary inspects audit logs for reflected headers | Grep scan on serialized JSON audit logs (canary.test.ts) | PASS |
8. Reproducibility & Local Verification
All verification proofs, live eval suites, and canary sweeps are fully automated and reproducible from the repository source code:
# 1. Clone repository and install dependencies
git clone https://github.com/0xm0w/openvault
cd openvault
npm install
# 2. Run the 27-surface canary secrecy sweep
npx vitest run test/security/canary.test.ts
# 3. Run the black-box security penetration test suite (17 probes)
npx vitest run test/security/pentest.test.ts
# 4. Run the full unit and integration suite (273 tests)
npm test
# 5. Run live Llama 3.2 3B warden evaluation (requires Ollama)
ollama pull llama3.2:3b
node dist/packages/brain/eval/run-eval.js --liveConclusion: MetaVault OSS establishes mathematically and empirically verifiable boundaries: agents cannot directly handle credentials, yet can seamlessly perform authorized work; plain-text credentials remain strictly contained within authenticated daemon memory buffers and are never disclosed to the agent, the chat session, or the LLM.