Cryptographic Governance 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 governance evidence gap across all 12 categories and maps how cryptographic governance mechanisms (sealed policy artifacts, signed governance 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: the white paper names no standard mechanism for producing cryptographic proof that the recommended mitigations were continuously applied during operation. Every category recommends controls. No category specifies how to prove those controls were active at the time of every agent decision.
Governance Evidence Across 12 Threat Categories
Each category maps a CoSAI-identified threat to the specific cryptographic mechanism that closes the governance evidence gap.
Improper Authentication and Identity Management
Subject Identifier binding; gateway seals a signed decision per-invocation; SPIFFE/SPIRE complementarity; TTL-based continuous re-attestation
Missing or Improper Access Control
Sealed artifact enumerates approved tools via allowlist; the gateway seals a DENY decision for tools outside the allowlist; blocking before forwarding is a per-deployment property
Input Validation/Sanitization Failures
gateway validates required parameters per sealed policy; phantom execution captures attack sequences
Input/Instruction Boundary Distinction Failure
The gateway sits downstream of the prompt layer: every tool call an injected instruction induces is still evaluated against the sealed allowlist and sealed as a signed PERMITTED or DENIED decision, and the receipt chain preserves a signed record of what a subverted agent attempted at the governed boundary
Inadequate Data Protection and Confidentiality Controls
Payload-blind hashing: receipts carry only a payload_hash; tiered disclosure
Missing Integrity/Verification Controls
Runtime hash comparison against sealed reference on every measurement cycle
Session and Transport Security Failures
Per-session sealed artifacts with TTL; expiry seals a safe-state (deny-by-default) decision, effecting the transition is per-deployment wiring; per-session chains
Network Binding/Isolation Failures
gateway as sole network path; sealed upstream identity validation; admission webhook for Kubernetes
Trust Boundary and Privilege Design Failures
Constrained sub-mandates: derived artifacts with TTL <= parent, scope <= parent
Resource Management/Rate Limiting Absence
Rate limits sealed in artifact; gateway seals a DENY receipt specifying the violated limit; proxy-layer governance is per-deployment wiring
Supply Chain and Lifecycle Security Failures
Continuous runtime binary hash verification extending build-time SBOMs; per-tenant isolation
Insufficient Logging, Monitoring, and Auditability
Hash-linked signed receipt chain; Merkle inclusion proofs; offline evidence bundles
Detailed 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 applied for every individual tool invocation throughout the session.
The sealed Policy Artifact binds the agent's Subject Identifier, comprising cryptographic hashes of normalized bytes and canonicalized metadata, to approved tools, rate limits, and temporal bounds. The gateway 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-level governance (workload-to-intent). Continuous authentication: TTL-based re-attestation renews authorization on a fixed interval; each interval requires fresh attestation.
T4: Input/Instruction Boundary Distinction Failure
CoSAI identifies this as the design limitation behind the entire prompt-injection class: LLMs process trusted instructions and untrusted data in one token stream, so adversary-controllable content (tool responses, schema descriptions, resource content) can alter execution flow. CoSAI recommends input sanitization, guardrails, and context isolation. The gap: none of those controls produce evidence of what a subverted agent actually attempted.
AGA does not operate at the prompt layer and does not claim to prevent injection. The gateway sits downstream of it, at the tool-call boundary: every call an injected instruction induces is still evaluated against the sealed allowlist and sealed as a signed PERMITTED or DENIED decision. An injection that steers the agent toward a tool outside the sealed allowlist produces a signed DENY receipt; refusing the call in path is a per-deployment property of how the gateway is wired.
Forensic value: because receipts are hash-linked and Merkle-committed, the full sequence of tool calls a compromised session attempted at the governed boundary survives as offline-verifiable evidence, whether each call was permitted or denied. That record is what incident response reconstructs after an injection, and it is the evidence the recommended prompt-layer mitigations do not produce.
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 by carrying only hashes of the data. Each receipt records a payload_hash, a SHA-256 of the event, never the payload itself, and the bundle's leaf hashes the canonical receipt. A third-party auditor can verify chain integrity end to end, where any added, altered, reordered, or truncated entry fails verification, without seeing any agent interaction contents. Completeness of capture is bounded by the interception point: the bundle proves the record, not that every action was recorded.
Evidence bundles support tiered disclosure: integrity verification from the hashes alone (shareable with any auditor) and payload confirmation against those hashes (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 applied 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 gateway is deployed as the sole network path between the agent and MCP servers. The sealed artifact specifies the authorized upstream by identity (URL, TLS certificate fingerprint, service mesh identity). The gateway validates upstream identity on every connection. Even if network isolation fails, the gateway seals a DENY decision for any server not matching the sealed reference; refusing that traffic in path is a per-deployment property of how the gateway is wired.
For Kubernetes, when wired as an admission webhook (failurePolicy: Fail), pods are refused without a sealed artifact. Combined with Envoy ext_authz gRPC, the sealed-decision-and-receipt path spans the application layer (gateway) and service mesh layer (sidecar), producing signed receipts at both. These admission-webhook and proxy-layer behaviors are per-deployment wiring.
T12: Logging, Monitoring, and Auditability
The most direct governance 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 governance receipts replace mutable logs with a cryptographic proof structure. Each receipt is signed with Ed25519 over SHA-256 of JCS-canonicalized content. Receipts are hash-linked via SHA-256 of the canonical receipt including its signature. Merkle inclusion proofs detect omissions. Periodic checkpoints via Merkle roots 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. These mechanisms support the objectives these standards describe, without claiming certification.
Algorithm agility: Ed25519 and SHA-256 are the operational defaults and what the live gateway signs. The ML-DSA-65 + Ed25519 composite is specified and reference-verified against the NIST FIPS 204 vectors; it ships in the aga-mcp-server npm package, not in the aga-verify CLI, and it is not what the live gateway signs. The artifact and receipt structures accommodate further schemes (such as SLH-DSA) as drop-in replacements.