Zero-Knowledge Capability Proxy: Performance and Security Updates in v2.4

# Zero-Knowledge Capability Proxy: Performance and Security Updates in v2.4 When we shipped the Zero-Knowledge Capability Proxy (ZKCP) as part of 0nMCP v2.4.0, the goal was straightforward: let AI agents invoke any of our 870+ tools without ever exposing raw credentials to the model context. The proxy sits between the agent and the service, resolving capabilities at execution time rather than planning time. This release cycle, we focused on making ZKCP faster, more auditable, and harder to abuse. Here's what changed, why it matters, and how it works under the hood. --- ## What Is the Zero-Knowledge Capability Proxy? If you're new to 0nMCP, a quick primer. Traditional [AI orchestration](/glossary/ai-orchestration) platforms pass API keys directly into the model's tool-calling context. The model sees your Stripe secret key, your database connection string, your CRM bearer token — all of it. That's a problem for two reasons: 1. **Prompt injection attacks** can extract credentials from context. 2. **Model providers** may log tool inputs for training or debugging. ZKCP eliminates both risks. When an agent calls a tool like `stripe_create_customer`, the proxy resolves the credential from your [0nVault](/security/vault) at execution time. The model never sees the key. It only sees a capability token — a short-lived, scoped reference that proves the agent is authorized to perform that specific action. Think of it like a valet key for your car. The valet can drive it, but they can't open the trunk or the glove box. ZKCP gives the AI agent a valet key for each tool invocation. --- ## Performance: 3x Faster Capability Resolution The biggest complaint about v2.3's ZKCP was latency. Every tool call required a full vault lookup, capability token generation, and cryptographic verification. For a [Pipeline execution](/glossary/mcp-protocol) chaining 12 tools, that added 800-1200ms of overhead. We attacked this from three angles. ### 1. Capability Token Caching with Sliding Windows Previously, every invocation generated a fresh capability token. Now, ZKCP maintains a sliding-window cache keyed on `(agent_id, tool_name, scope_hash)`. If an agent calls `supabase_query` three times in the same Pipeline run with the same scope, the second and third calls reuse the cached token. ```javascript // Capability cache entry structure { key: 'a3f8c1_supabase_query_7b2e9d', token: 'cap_v2_...signed...', created: 1710842400000, ttl: 30000, // 30-second sliding window uses: 1, maxUses: 10, // Burst limit per window scopeHash: '7b2e9d' // SHA-256 of granted permissions } ``` The sliding window resets on each use, so active Pipelines keep their tokens warm. Idle tokens expire in 30 seconds. This alone cut median resolution time from 47ms to 11ms per tool call. ### 2. Vault Pre-Warming on Pipeline Entry When a Pipeline starts, ZKCP now inspects the execution plan and pre-fetches all required credentials from the vault in a single batch operation. Previously, credentials were fetched lazily — one at a time, as each tool was invoked. ```javascript // Before: lazy fetch (v2.3) async function resolveCapability(toolName) { const cred = await vault.unseal(toolName); // 35-50ms each const token = await generateCapToken(cred, scope); return token; } // After: batch pre-warm (v2.4) async function warmPipeline(executionPlan) { const toolNames = executionPlan.steps.map(s => s.tool); const unique = [...new Set(toolNames)]; const creds = await vault.unsealBatch(unique); // Single operation capabilityCache.prime(creds); } ``` For a 12-step Pipeline hitting 5 unique services, this reduces vault operations from 12 sequential unseals to 1 batch unseal. The improvement scales linearly with Pipeline length. ### 3. HMAC Verification Short-Circuit Capability tokens are HMAC-SHA256 signed. In v2.3, verification recomputed the HMAC on every use. Now, verified tokens carry a `verified` flag in the cache, and re-verification only happens if the token's TTL has crossed a midpoint threshold (15 seconds for a 30-second TTL). This cuts cryptographic operations by roughly 60% in burst scenarios like [Radial Burst](/glossary/ai-orchestration) execution. **Benchmark results** (12-step Pipeline, 5 services, measured on M2 MacBook Pro): | Metric | v2.3 | v2.4 | Improvement | |--------|------|------|-------------| | Median resolution | 47ms/tool | 11ms/tool | 4.3x | | P99 resolution | 128ms/tool | 38ms/tool | 3.4x | | Total Pipeline overhead | 1,140ms | 340ms | 3.4x | | Vault operations | 12 | 1 | 12x | | HMAC computations | 24 | 9 | 2.7x | --- ## Security: Tighter Cryptographic Bindings Faster is good. But not at the cost of weaker security. We made several hardening changes alongside the performance work. ### Scope Binding with Content Addressing Capability tokens in v2.3 were scoped to a tool name and a set of permissions. In v2.4, they're additionally bound to a **content-addressed scope hash** — a SHA-256 digest of the exact parameters the agent is authorized to pass. This means if an agent receives a capability token for `stripe_create_customer` with scope `{ email: true, name: true }`, it cannot use that same token to pass `{ email: true, name: true, metadata: { admin: true } }`. The scope hash won't match, and the proxy rejects the call. ```javascript // Scope hash computation function computeScopeHash(toolName, grantedParams) { const canonical = JSON.stringify( Object.keys(grantedParams).sort().reduce((acc, key) => { acc[key] = grantedParams[key]; return acc; }, {}) ); return crypto .createHash('sha256') .update(`${toolName}:${canonical}`) .digest('hex') .slice(0, 12); } ``` This is particularly important for our 245 CRM tools and 594 catalog tools, where a single service might expose dozens of endpoints with varying sensitivity levels. A token scoped for `contacts_list` cannot be replayed against `contacts_delete`. ### Agent Identity Pinning Capability tokens are now pinned to the originating agent's identity hash. In multi-agent scenarios — say, a Pipeline that delegates subtasks to specialized agents — each agent gets its own token lineage. Agent A's tokens cannot be forwarded to Agent B, even if both have access to the same tools. This closes a theoretical escalation path where a compromised sub-agent could accumulate capabilities from its parent. With identity pinning, the blast radius of any single agent compromise is limited to that agent's granted scope. ### Audit Trail Integration Every capability token lifecycle event is now logged to the [0nVault](/security/vault) audit trail: - `cap.issued` — token created, with scope hash and TTL - `cap.used` — token presented for tool execution - `cap.cached` — token served from cache (vs. fresh generation) - `cap.expired` — token TTL elapsed without renewal - `cap.rejected` — token failed verification (scope mismatch, identity mismatch, expired) ```javascript // Audit entry example { event: 'cap.rejected', timestamp: '2026-03-19T14:22:08.441Z', agentId: 'agent_7f3a2c', tool: 'crm_contacts_delete', reason: 'scope_hash_mismatch', expected: 'a3f8c1d2e4b6', received: '9c7e1b3d5a8f', pipelineId: 'pipe_882ec4' } ``` This ties directly into our patent-pending [0nVault Container System](https://0nmcp.com/security/vault) (US #63/990,046), where the audit trail is stored as a sealed, content-addressed layer inside the `.0nv` container. You can verify the integrity of the audit log independently of the system that generated it — useful for compliance reviews and incident response. --- ## What This Means for .0n SWITCH Files If you're building workflows with [.0n SWITCH files](/0n-standard), you don't need to change anything. ZKCP operates transparently at the execution layer. Your SWITCH files still reference tools by name: ```yaml name: onboard-customer version: 1.0.0 steps: - tool: stripe_create_customer inputs: email: "{{inputs.email}}" name: "{{inputs.name}}" - tool: crm_contacts_create inputs: email: "{{inputs.email}}" firstName: "{{inputs.name}}" - tool: sendgrid_send_email inputs: to: "{{inputs.email}}" template: welcome ``` Behind the scenes, the Pipeline executor now calls `warmPipeline()` before step 1, pre-fetching [Stripe](/turn-it-on/stripe), CRM, and [SendGrid](/turn-it-on/sendgrid) credentials in one vault operation. Each step gets a scoped capability token. The agent never sees a raw API key. --- ## Comparison: How ZKCP Stacks Up Most orchestration platforms take one of two approaches to credential management: 1. **Plaintext injection** — keys passed directly into model context (Zapier, Make) 2. **OAuth proxy** — platform holds keys and proxies requests, but the platform itself is a trust boundary (n8n self-hosted) ZKCP is a third approach: **zero-knowledge capability delegation**. The orchestrator never exposes credentials to the model, and capability tokens are cryptographically bound to specific actions, agents, and time windows. See our [detailed comparison pages](/compare) for how 0nMCP's security model differs from Zapier, n8n, Make, and others. | Feature | Plaintext | OAuth Proxy | ZKCP | |---------|-----------|-------------|------| | Model sees raw keys | Yes | No | No | | Platform sees raw keys | N/A | Yes | Yes (vault) | | Scoped to specific action | No | Partial | Yes | | Time-bounded | No | Session | 30s sliding | | Agent-pinned | No | No | Yes | | Content-addressed scope | No | No | Yes | | Audit trail | Varies | Varies | Built-in | --- ## Migration Notes If you're upgrading from v2.3: - **No breaking changes.** ZKCP v2.4 is backward-compatible with all existing SWITCH files and vault configurations. - **Cache warming is automatic.** Pipelines, Assembly Lines, and Radial Bursts all benefit without configuration changes. - **Audit logging is opt-in.** Set `ZKCP_AUDIT=true` in your environment or add `"audit": true` to your vault container config to enable detailed capability logging. - **Token TTL is configurable.** Default remains 30 seconds. Adjust via `ZKCP_TOKEN_TTL_MS` for long-running Pipelines. ```bash # Upgrade npm install -g 0nmcp@latest # Verify 0nmcp engine verify # Enable audit logging export ZKCP_AUDIT=true 0nmcp serve --port 3077 ``` --- ## What's Next We're working on two follow-ups for v2.5: 1. **Capability delegation chains** — allowing a parent agent to issue sub-scoped tokens to child agents, creating a verifiable chain of custody for multi-agent Pipelines. 2. **Hardware-bound capability tokens** — tying tokens to the [vault fingerprint](/security/vault) so they can't be exfiltrated and replayed on a different machine. Both build on the patent-pending Three-Level Execution model (Pipeline > Assembly Line > Radial Burst) and the 0nVault Container System. --- ## Try It Now ZKCP v2.4 ships with 0nMCP v2.4.0. All 870+ tools across 54 services benefit from the performance and security improvements immediately. - **[Turn It 0n](/turn-it-on)** — Connect your services and start building - **[Browse integrations](/integrations)** — See all 54 supported services - **[Workflow examples](/examples)** — Pre-built SWITCH files to get started - **[Community forum](/forum)** — Ask questions, share workflows, get help - **[Downloads](/downloads)** — Chrome extension and CLI tools Have questions about ZKCP or want to report a security issue? Visit the [forum](/forum) or email security@0nmcp.com. --- *0nMCP v2.4.0 — Stop building workflows. Start describing outcomes.*