Independent Research · Published March 28, 2026
Cryptographic Enforcement Evidence for MCP Security
An Analysis of the CoSAI WS4 Threat Taxonomy
The Coalition for Secure AI (CoSAI) published a comprehensive MCP security white paper in January 2026, identifying 12 threat categories and nearly 40 distinct threats across all-local, single-tenant hybrid, and multi-tenant cloud deployments. This analysis examines the enforcement evidence gap across all 12 categories and maps how cryptographic governance mechanisms (sealed policy artifacts, signed enforcement receipts, and offline-verifiable evidence bundles) address each gap.
View the CoSAI WS4 white paper on GitHubCore Finding
Across all 12 CoSAI threat categories, the mitigations recommended are sound. The common gap is identical: no standard mechanism exists to produce cryptographic proof that the recommended mitigations were continuously enforced during operation. Every category recommends controls. No category specifies how to prove those controls were active at the time of every agent decision.
Enforcement Evidence Across 12 Threat Categories
Each category maps a CoSAI-identified threat to the specific cryptographic mechanism that closes the enforcement evidence gap.
Improper Authentication and Identity Management
Subject Identifier binding; Portal enforces per-invocation; SPIFFE/SPIRE complementarity; TTL-based continuous re-attestation
Claim 1(b), Claim 6Missing or Improper Access Control
Sealed artifact enumerates authorized tools via allowlist; Portal denies unlisted tools before forwarding
Claim 1(a)Input Validation/Sanitization Failures
Portal validates required parameters per sealed policy; phantom execution captures attack sequences
Claim 1(f), Claim 11Input/Instruction Boundary Distinction Failure
Behavioral drift detection against sealed baseline; phantom execution for forensic capture
Claim 1(e), Claim 11Inadequate Data Protection and Confidentiality
Structural metadata linking: chain integrity from metadata only; payload excluded; tiered disclosure
Claim 3Missing Integrity/Verification Controls
Runtime hash comparison against sealed reference on every measurement cycle
Claim 1(b), Claim 1(f)Session and Transport Security Failures
Per-session sealed artifacts with TTL; expiry triggers safe-state transition; per-session chains
Claim 6Network Binding/Isolation Failures
Portal as sole network path; sealed upstream identity validation; admission webhook for Kubernetes
Claim 1(e)Trust Boundary and Privilege Design Failures
Constrained sub-mandates: derived artifacts with TTL <= parent, scope <= parent
Claim 1Resource Management/Rate Limiting Absence
Rate limits sealed in artifact; Portal enforces at proxy layer; DENY receipt specifies violated limit
Claim 1(a)Supply Chain and Lifecycle Security Failures
Continuous runtime binary hash verification extending build-time SBOMs; per-tenant isolation
Claim 1(b), Claim 10Insufficient Logging, Monitoring, and Auditability
Hash-linked signed receipt chain; Merkle inclusion proofs; offline evidence bundles
Claim 3, Claim 9, Claim 12Detailed Analysis: Key Categories
T1: Identity and Access Management
CoSAI recommends end-to-end request traceability, SPIFFE/SPIRE workload identities, OIDC providers, and short-lived tokens with DPoP. These mitigations authenticate the agent at the point of entry. The gap: no mechanism proves that least-privilege constraints were evaluated and enforced for every individual tool invocation throughout the session.
The sealed Policy Artifact binds the agent's Subject Identifier (Claim 1(b)), comprising cryptographic hashes of normalized bytes and canonicalized metadata, to authorized tools, rate limits, and temporal bounds. The Portal evaluates every tools/call request against this binding and produces a signed receipt per invocation.
SPIFFE/SPIRE integration: SPIRE handles transport-layer identity (node-to-workload via SVID). AGA handles accountability-layer enforcement (workload-to-intent governance). Continuous authentication: TTL-based re-attestation (Claim 6) ensures authorization is periodically renewed, not permanently granted.
T4: Execution and Sandboxing
CoSAI recommends process isolation, container boundaries, and guardrails. The gap: container isolation produces no cryptographic evidence of continuous operation. When isolation is breached, current approaches provide no forensic capture mechanism.
The Portal operates as a Policy Enforcement Point (NIST SP 800-207). Every I/O passes through the Portal, which evaluates it against sealed constraints (Claim 1(e)). The agent holds no signing keys and cannot self-authorize. For high-consequence deployments, the Portal executes within a TEE (SGX/TrustZone, Embodiment 6).
Phantom execution (Claim 11): When behavioral drift is detected, the Portal severs all connections to protected resources while the agent continues executing in a sandboxed environment. The agent receives no signal that it has been transitioned. Every unauthorized action is captured as signed forensic receipts appended to the continuity chain.
T5: Confidentiality and Data Protection
A fundamental tension exists between comprehensive governance auditing and data confidentiality. Logging every interaction for compliance potentially exposes sensitive outputs, proprietary logic, or PII. Current approaches force a choice: comprehensive audit or privacy protection.
The architecture resolves this through structural metadata linking (Claim 3). Leaf hashes are computed from structural metadata only: event type, sequence number, timestamp, previous hash. Payload is excluded from chain linking. A third-party auditor can verify complete chain integrity, confirming every measurement, every enforcement action, and no omissions, without seeing any agent interaction contents.
Evidence bundles support tiered disclosure: structural verification (shareable with any auditor) and payload verification (authorized parties only). This enables compliance verification without confidentiality compromise in multi-tenant deployments.
T8: Network Binding and Isolation
CoSAI recommends network segmentation, localhost binding, and DNS rebinding protection. The gap: network isolation is enforced by infrastructure and produces no application-layer governance evidence. If an agent connects to a shadow MCP server through DNS rebinding, the legitimate server's logs show nothing.
The Portal is the sole network path between the agent and MCP servers (Claim 1(e)). The sealed artifact specifies the authorized upstream by identity (URL, TLS certificate fingerprint, service mesh identity). The Portal validates upstream identity on every connection. Even if network isolation fails, the Portal refuses traffic to any server not matching the sealed reference.
For Kubernetes, the admission webhook (failurePolicy: Fail) prevents pods from starting without a sealed artifact. Combined with Envoy ext_authz gRPC, enforcement spans application layer (Portal) and service mesh layer (sidecar), producing signed receipts at both.
T12: Logging, Monitoring, and Auditability
The most direct enforcement evidence gap. CoSAI recommends comprehensive logging and immutable audit records, but standardized audit logging across MCP implementations does not yet exist. More fundamentally: logs are mutable, passive, and producer-controlled.
Signed enforcement receipts replace mutable logs with a cryptographic proof structure. Each receipt is signed with Ed25519 over SHA-256 of JCS-canonicalized content (Claim 3, Claims 3(d-f)). Receipts are hash-linked via SHA-256 of structural metadata. Merkle inclusion proofs (Claim 9) detect omissions. Periodic checkpoints via Merkle roots (Claim 12) anchor the chain.
The evidence bundle is a portable verification unit requiring only standard Ed25519 and SHA-256 operations. No network callbacks. No proprietary tooling. Verification produces the same PASS/FAIL result regardless of where or when it is executed.
Standards Alignment
This alignment is architectural, not certification. These mechanisms support the objectives these standards describe.
Algorithm agility: Ed25519 and SHA-256 are current defaults. Post-quantum signature schemes (ML-DSA, SLH-DSA) are drop-in replacements within the existing artifact and receipt structures.