A technical specification for verifying AI agents at the Model Context Protocol gateway. Drop-in implementation for any MCP server.
The Model Context Protocol gives AI agents a standard way to talk to servers. It does not give servers a standard way to verify the agent making the request. Every MCP deployment in production today accepts agent claims at face value: a string in a header, an OAuth token from an issuer that does not validate behavioral identity, or no authentication at all.
This spec defines how to close that gap. It describes the verification primitives Arc enforces at the MCP boundary, the protocol additions required for agent identity proofs, and the audit trail every gateway decision must produce.
A verified MCP request consists of four primitives, validated in order at the gateway.
The agent must present a cryptographic identity proof. Arc accepts five proof types: signed JWT (from a trusted issuer registered in the gateway's allowlist), OAuth 2.1 client credentials with token introspection, mutual TLS certificate pinned to the operator, operator-verified credential (a signed claim from the agent's operating platform), and a soulbound on-chain identity binding. Each proof type produces a verified agent_id and operator_id.
The agent declares its intent at session start. Arc captures the declared intent and matches it against subsequent actions in the session. A mismatch triggers re-authentication.
Each action in the session is validated against the user's granted authorization scope. The gateway holds the canonical scope and rejects out-of-scope actions before they reach the server.
Every gateway decision produces an immutable attestation containing the agent ID, operator ID, declared intent, action attempted, authorization result, and decision rationale. Attestations are written to an append-only log keyed by request ID.
Arc requires three header additions on every MCP request: X-Agent-Identity (proof_type:proof_data), X-Agent-Intent (declared_purpose:declared_scope), and X-Agent-Session (session_id) so the gateway can track behavioral fingerprint across requests.
Identity validation runs in under 25ms. Intent matching in under 15ms. Authorization check in under 30ms. Behavioral fingerprint update in under 10ms (async). Total p99 latency: under 100ms. The gateway runs phases in parallel where possible.
Every gateway decision returns a structured response with decision (allow / deny / challenge), request_id, agent_id, operator_id, decision_rationale (full explainability chain), decision_latency_ms, audit_log_id, and expires_at. A 'challenge' decision indicates the gateway requires re-authentication.
For regulated deployments, the gateway produces an audit trail aligned to FFIEC examination expectations and EU AI Act transparency requirements. Each record contains request ID, agent and operator IDs, identity proof type and validation result, declared intent, action attempted, authorization result, behavioral fingerprint snapshot, decision rationale, decision latency, and counterfactual analysis.
Arc provides reference implementations in TypeScript, Python, and Go. The gateway deploys as either a sidecar in front of any MCP server or as a managed service in a deepidv-operated region. The middleware intercepts every incoming MCP request, runs the four-phase decision, and either passes the request through or returns the structured deny / challenge response.
What MCP server frameworks does Arc support? Reference implementations exist for Anthropic's MCP TypeScript SDK, the Python SDK, and the Go SDK. Custom MCP servers can integrate via the Arc HTTP API at the gateway boundary.
What is the gateway latency overhead? Sub-100ms p99 across all four decision phases. Most agent workloads do not perceive the overhead because identity validation and intent matching run concurrently against cached state.
How does Arc handle agent re-authentication? The gateway returns a 'challenge' decision when re-authentication is required. The MCP server holds the request, the agent re-authenticates via its issuer, and the request retries with the new identity proof.
Can I run Arc on-premise? Yes. Enterprise deployments include an on-premise reference architecture. The gateway runs in your VPC, audit logs stream to your SIEM, and identity validation happens against your local cache.
What is the failure mode if Arc itself is unavailable? The gateway supports two failure modes: fail-closed (reject all requests, default for high-stakes deployments) and fail-open with logging (allow all requests but log the bypass, default for evaluation deployments).
How does this relate to OAuth? OAuth handles the user-to-agent authorization grant. Arc validates the OAuth-issued token as one of its supported identity proofs. The two are complementary, not competing.
Go live in minutes. No sandbox required, no hidden fees.
Building vs. buying identity verification infrastructure is one of the most consequential technical decisions a growing company makes. Here is the framework for getting it right.
Evaluating identity verification providers? This comprehensive guide covers every criterion that matters — from technical capabilities to pricing models to vendor stability.
Monolithic KYC bundles force you to pay for checks you do not need. Modular identity verification lets you compose workflows that match your exact requirements — and nothing more.
