How SWT3 AI Witness procedures address the NSA Artificial Intelligence Security Center's recommendations for securing Model Context Protocol deployments.
Audience: ISSMs, C3PAOs, security engineers, and compliance teams evaluating MCP deployments in national security, defense, or critical infrastructure environments. This mapping references NSA AISC CSI U/OO/6030316-26 (May 2026).
On May 21, 2026, the NSA's Artificial Intelligence Security Center (AISC) published "Security Design Considerations for AI-Driven Automation Leveraging the Model Context Protocol" (CSI U/OO/6030316-26). This is the first formal U.S. government cybersecurity guidance addressing MCP deployment risks.
The guidance identifies three systemic risk areas:
The NSA notes that traditional safeguards (authentication, input validation) remain necessary but are insufficient for agentic AI systems, which introduce dynamic tool invocation and implicit trust relationships. The guidance concludes that "MCP-aware security proxies remain limited and are still maturing."
| NSA Recommendation | Coverage | SWT3 Procedures / Controls |
|---|---|---|
| NSA-1: Filtering Outgoing Proxy + DLP | Network Layer | Outside SDK scope. Network-level control. |
| NSA-2: Sandboxing + Tool Execution Constraints | Full | ChainEnforcer: blocklist, allowlist, velocity, depth, token budget |
| NSA-3: Message Integrity + Signing | Full | HMAC-SHA256 signing, epoch timestamps, Merkle accumulator |
| NSA-4: Output Filtering | Full | Clearing levels 0-3, surgical data purge |
| NSA-5: Tool Name Collision + Drift Detection | Full | AI-TOOL.1 witnessing, axiom drift |
| NSA-6: Detailed Audit Logging for SIEM | Full | Witness ledger, OTel exporter, regulatory webhooks |
| NSA-7: Local MCP Server Discovery Scanning | Network Layer | Outside SDK scope. Pre-deployment control. |
| NSA-8: Content Validation + Rate Limiting + Policy | Full | mcp_policy: max_velocity, max_chain_depth, max_tokens_per_session |
| NSA-9: Indirect Prompt Injection Detection | Full | AI-GRD.1/GRD.2 guardrail witnessing, violation anchors |
The NSA recommends tightly pinning resource URLs and access methods for outbound MCP traffic, with data loss prevention (DLP) inspection at the network boundary.
The NSA cites OS-level containment (Linux: Landlock, seccomp, network namespaces) and recommends constraining which tools an agent can invoke, how frequently, and at what depth.
ChainEnforcer class enforces five layers of tool execution constraints, all evaluated in-memory with zero network calls:
| Enforcement Layer | Config Key | Description |
|---|---|---|
| Tool Blocklist | tool_blocklist | Glob patterns for forbidden tools (e.g., shell_*, exec_*) |
| Tool Allowlist | tool_allowlist | Explicit allowlist when defined; all unlisted tools rejected |
| Velocity Limiting | max_velocity | Rate limit (e.g., 10/60s) to prevent tool call flooding |
| Chain Depth | max_chain_depth | Maximum sequential tool invocations per session |
| Token Budget | max_tokens_per_session | Cumulative token ceiling per session; blocks on exceeded |
When fail_secure: true is set, any policy violation blocks the tool call before execution and mints a violation anchor recording the attempted action, the rule that triggered, and the tool name.
Procedures: AI-TOOL.1 (tool call witnessing), AI-CHAIN.1 (exploit chain monitoring)
The NSA notes that MCP does not natively support message signing and recommends that implementations add integrity mechanisms. The guidance calls for signed action receipts, expiration timestamps, and replay detection.
signing_key parameter produces a cryptographic signature on every anchor. The server validates signatures on ingestion and rejects tampered payloads.daily_merkle_rollups.SHA256("WITNESS:{tenant}:{proc}:{fa}:{fb}:{fc}:{ts_ms}").hex()[:12] -- identical across Python, TypeScript, Rust, C#, and Ruby SDKs. 40 cross-language test vectors verify parity.Procedures: Every SWT3 procedure produces a signed anchor. AI-CHAIN.2 (chain integrity) provides cross-agent replay detection via cycle_id linking.
The NSA recommends sanitizing tool outputs to prevent data exfiltration and to control what information flows between MCP components.
| Level | Name | What Gets Purged |
|---|---|---|
| 0 | Analytics | Nothing purged. Full telemetry retained. |
| 1 | Standard | Raw prompt/response text stripped. Factors and verdict retained. |
| 2 | Sensitive | AI context metadata stripped. Only procedure, verdict, and fingerprint remain. |
| 3 | Classified | Surgical purge. Only the cryptographic proof survives. No operational data crosses the boundary. |
The clearing engine is not optional decoration. It is a core protocol mechanism that controls exactly what evidence leaves the enclave boundary. Jurisdiction, legal basis, and purpose class (CJT fields) survive all clearing levels to maintain regulatory traceability even at Classified.
Configuration: clearing_level: 2 in .swt3.yaml or per-call via SDK parameter.
The NSA identifies tool inventory drift as a risk: a tool's name, description, or parameter schema may change between sessions without the operator's knowledge, potentially introducing malicious behavior under a trusted tool name.
wrapTool() / wrap_tool() mints an anchor for every MCP tool invocation. The tool name, latency, and provider are captured in ai_context.axiom drift compares current scan results against a baseline. Tool inventory changes between sessions produce drift events with severity classification.toolPolicyGate() in the MCP server checks every tool call against the witnessed_tools and exempt_tools lists before execution. Unknown tools are blocked when block_on_failure: true.Procedures: AI-TOOL.1 (tool call witnessing), AI-BASE.1 (behavioral baseline)
The NSA recommends comprehensive logging of all MCP interactions with signed action receipts, webhook integration, and bidirectional JSON-RPC scanning with audit trails.
sovereign_witness_ledger. Each anchor includes procedure ID, verdict, three evidence factors, observations (JSONB), fingerprint, and timestamp.swt3.procedure_id, swt3.verdict, swt3.fingerprint, swt3.model_id) to any OTel-compatible collector -- Jaeger, Datadog, Splunk, Elastic.POST /api/v1/webhooks delivers HMAC-signed compliance events to external SIEM/GRC tools in real time. Events include verdict changes, drift detection, and attestation lapses.swt3 audit CLI generates self-contained HTML or JSON reports from WAL data.Procedures: Every SWT3 procedure produces an audit record. AI-INF.1 (inference provenance) is the foundational audit anchor.
The NSA recommends pre-deployment discovery of MCP servers to identify unauthorized or rogue server instances.
swt3 doctor CLI validates the local configuration and connectivity of the intended MCP server.
The NSA recommends length caps, keyword scanning, rate limiting, and application-specific policy enforcement as runtime controls for MCP interactions.
mcp_policy section of .swt3.yaml provides declarative policy enforcement:
# .swt3.yaml
mcp_policy:
witnessed_tools: ["*"]
auto_witness: true
block_on_failure: true
max_velocity: "10/60s" # Max 10 tool calls per 60 seconds
max_chain_depth: 8 # Max 8 sequential invocations
max_tokens_per_session: 25000
tool_blocklist:
- "shell_*"
- "exec_*"
- "delete_*"
fail_secure: true
density_policy:
min_anchors_per_1000_tokens: 2
max_chain_gap_seconds: 300
Policy enforcement is evaluated entirely in-memory by the ChainEnforcer with zero network calls and zero added latency. Seven built-in profiles ship with the SDK, including owasp-agentic-top10 (aligned with OWASP Agentic Top 10) and cost-conscious (token budget governance).
Procedures: AI-GRD.3 (gatekeeper mode), AI-CHAIN.1 (chain monitoring)
The NSA identifies indirect prompt injection as a systemic MCP risk: an attacker embeds instructions in tool output that cause the agent to invoke additional tools or exfiltrate data through unintended channels.
strict: true, the SDK blocks the inference call entirely if the required number of guardrails is not active. No inference runs without safeguards.SWT3 does not perform injection detection itself -- that is the role of the guardrail tooling (Lakera, Rebuff, custom filters). SWT3 witnesses whether the guardrails were present, active, and effective, creating the audit trail that proves the control was operational at the time of the interaction.
A .swt3.yaml configuration addressing all 7 applicable NSA recommendations:
# .swt3.yaml -- NSA AISC MCP Security Alignment
clearing_level: 2 # NSA-4: Output filtering (Sensitive)
policy:
require_signing: true # NSA-3: Message integrity
require_agent_id: true # Agent identity for attribution
min_clearing_level: 1 # Minimum clearing enforcement
required_procedures:
- AI-INF.1 # NSA-6: Audit logging
- AI-GRD.1 # NSA-9: Guardrail presence
- AI-TOOL.1 # NSA-5: Tool witnessing
- AI-CHAIN.1 # NSA-2: Chain monitoring
trust_mesh:
mode: strict # NSA-3: Trust verification
require_signature: true
freshness_window: 1800
mcp_policy:
witnessed_tools: ["*"] # NSA-5: Tool inventory
auto_witness: true
block_on_failure: true # NSA-2: Fail-secure
max_velocity: "10/60s" # NSA-8: Rate limiting
max_chain_depth: 8 # NSA-2: Depth constraint
max_tokens_per_session: 50000
tool_blocklist: # NSA-2: Tool blocklist
- "shell_*"
- "exec_*"
- "run_command"
- "delete_*"
fail_secure: true
density_policy:
min_anchors_per_1000_tokens: 3
max_chain_gap_seconds: 120
require_signing_key: true # NSA-3: Signed receipts
merkle:
enabled: true # NSA-3: Tamper evidence
accumulator_interval: 30