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 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 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 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.

// 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.

// 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 execution.

Benchmark results (12-step Pipeline, 5 services, measured on M2 MacBook Pro):

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.

// 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 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)

// 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 (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, you don't need to change anything. ZKCP operates transparently at the execution layer. Your SWITCH files still reference tools by name:

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, CRM, and 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 for how 0nMCP's security model differs from Zapier, n8n, Make, and others.

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.

# 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 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 — Connect your services and start building
• Browse integrations — See all 54 supported services
• Workflow examples — Pre-built SWITCH files to get started
• Community forum — Ask questions, share workflows, get help
• Downloads — Chrome extension and CLI tools

Have questions about ZKCP or want to report a security issue? Visit the forum or email security@0nmcp.com.

0nMCP v2.4.0 — Stop building workflows. Start describing outcomes.