Audience: Security engineers evaluating MCP governance tooling, enterprise architects deploying MCP agents in production, CISOs assessing agentic AI risk, and compliance teams mapping MCP deployments to regulatory frameworks (EU AI Act, NIST AI RMF, CMMC).
Context: The OWASP MCP Top 10 (beta, 2025) catalogs the ten most critical risks in Model Context Protocol deployments. Independent scans find 30-82% of public MCP servers carry exploitable flaws, 91.8% of audited production servers lack OAuth, and 687 instances have unrestricted shell tool access. Between January and February 2026, researchers filed over 30 CVEs (43% shell injections). The NSA published MCP security design guidance in May 2026, and a confused deputy attack hijacked Azure DevOps review agents in August 2026. SWT3 addresses these risks through cryptographic witnessing, NHI credential lifecycle management, clearing-level evidence graduation, and the Trust Mesh mutual verification protocol. This document maps each risk to specific SWT3 capabilities, aligned with NSA CSI MCP Security guidance (May 2026).
Overview
SWT3 is not a security product. It is an independent witness protocol that records what happened, whether it matched policy, and produces tamper-proof evidence. When applied to MCP deployments, this witnessing capability creates the audit trail and policy attestation layer that addresses each OWASP MCP risk through evidence, not interception.
The @tenova/swt3-mcp server (60 tools, listed on the MCP Registry as io.tenova/swt3-witness) provides witnessing for every tool call in an MCP session. The NHI namespace (7 procedures) covers the complete non-human credential lifecycle: scope, provisioning, privilege change, rotation, delegation, revocation, and expiration. The .swt3.yaml configuration file declares policies that are evaluated at each tool invocation.
MCP01: Token Mismanagement and Secret Exposure
MCP01:2025
Hard-coded credentials, long-lived tokens, and secrets in model memory
Attackers retrieve tokens through prompt injection, compromised context, or debug traces, leading to full compromise of connected systems.
SWT3 Response: The SDK uses environment variables for all secrets (
Procedures: AI-ID.1 (agent identity), NHI-ROTATE.1 (credential rotation), NHI-EXPIRE.1 (credential expiration), NHI-REVOKE.1 (credential revocation), NHI-SCOPE.1 (credential scope attestation)
Payload fields:
NSA alignment: CSI MCP Security, Section: Identity and Access Management
Coverage: Full
SWT3_API_KEY, SWT3_SIGNING_KEY), never hard-coded values. The clearing engine (Levels 1-3) strips all secret material from witness anchors before transmission. At Level 3 (Classified), even the model identifier is hashed. The NHI namespace provides complete credential lifecycle witnessing: NHI-ROTATE.1 records credential rotation events, NHI-EXPIRE.1 records credential expiration with renewal status and grace periods, and NHI-REVOKE.1 records revocation with cascade flags. The authorization_expires field on every witness payload records the temporal authority bound of the credential that authorized the action, creating evidence of whether a credential was valid at the time of use. The NSA MCP guidance recommends "least-privilege tokens per action and tool" -- the NHI namespace witnesses whether that practice was followed.
Procedures: AI-ID.1 (agent identity), NHI-ROTATE.1 (credential rotation), NHI-EXPIRE.1 (credential expiration), NHI-REVOKE.1 (credential revocation), NHI-SCOPE.1 (credential scope attestation)
Payload fields:
authorization_expires, authorization_scope (CJT fields, survive all clearing levels)
NSA alignment: CSI MCP Security, Section: Identity and Access Management
Coverage: Full
MCP02: Excessive Agency and Privilege Escalation
MCP02:2025
Loosely defined permissions granting agents excessive capabilities over time
An attacker exploiting weak scope can perform unintended actions such as repository modification, system control, or data exfiltration.
SWT3 Response: The
Procedures: AI-GRD.3 (policy version binding), AI-TOOL.1 (tool call witnessing), AI-ACC.1 (access control witnessing), NHI-SCOPE.1 (credential scope attestation), NHI-PRIV.1 (privilege change witnessing)
Payload fields:
NSA alignment: CSI MCP Security, Section: Authorization and Scoping
Coverage: Full
.swt3.yaml policy file declares explicit tool allowlists and blocklists with glob pattern matching. Tools not on the allowlist are denied. The policy file is version-controlled and its hash is recorded in every witness anchor via policy_version, creating an immutable record of what permissions were active at each point in time. NHI-SCOPE.1 witnesses the declared credential scope at provisioning time, and NHI-PRIV.1 witnesses any privilege change events, creating evidence of scope creep that an auditor can trace. The authorization_scope field on every witness payload records the bounded scope under which the action was authorized. The NSA guidance requires "scope every tool invocation to the minimum permissions required" -- the NHI + authorization_scope combination produces the evidence that this was done.
Procedures: AI-GRD.3 (policy version binding), AI-TOOL.1 (tool call witnessing), AI-ACC.1 (access control witnessing), NHI-SCOPE.1 (credential scope attestation), NHI-PRIV.1 (privilege change witnessing)
Payload fields:
authorization_scope, policy_version_hash
NSA alignment: CSI MCP Security, Section: Authorization and Scoping
Coverage: Full
MCP03: Prompt Injection and Context Spoofing
MCP03:2025
Untrusted input manipulating agent behavior through injected instructions
Because models follow natural-language instructions, prompt injection attacks are both powerful and subtle. Analogous to classic XSS/SQLi but the interpreter is the model.
SWT3 Response: SWT3 does not inspect or filter prompt content (that is the role of guardrail tools like Prompt Guard or NeMo Guardrails). What SWT3 does is witness the guardrail results. AI-SEC.1 records whether a security scan was performed, what threat score was returned, and what threat type was detected. AI-GRD.1 records whether required guardrails were active. If guardrails are absent or return a threat detection, the witness record reflects it. In gatekeeper mode (
Procedures: AI-SEC.1 (security scan witnessing), AI-GRD.1 (guardrail presence attestation), AI-GRD.2 (output classification)
Coverage: Partial SWT3 witnesses guardrail results but does not perform prompt filtering itself.
strict: true), the SDK will not proceed with inference if required guardrails are not present.
Procedures: AI-SEC.1 (security scan witnessing), AI-GRD.1 (guardrail presence attestation), AI-GRD.2 (output classification)
Coverage: Partial SWT3 witnesses guardrail results but does not perform prompt filtering itself.
MCP04: Software Supply Chain Attacks
MCP04:2025
Compromised dependencies altering agent behavior or introducing backdoors
MCP ecosystems depend on open-source packages, connectors, and plugins. The ClawHavoc attack compromised 1,000+ agent skills on ClawHub through SKILL.md instruction injection and malicious package masquerading.
SWT3 Response: AI-SKILL.1 witnesses the skill manifest at agent initialization time, before any skill executes. The witness records a hash of the loaded skill set, creating independently verifiable evidence of exactly what was loaded and whether it matched the approved baseline. AI-MDL.1 witnesses the model weight hash, detecting if the deployed model differs from the approved version. Together, these procedures create a cryptographic snapshot of the agent's software supply chain at startup.
Procedures: AI-SKILL.1 (skill manifest attestation), AI-MDL.1 (model weight integrity), AI-MDL.5 (model weight hashing)
Coverage: Full
Procedures: AI-SKILL.1 (skill manifest attestation), AI-MDL.1 (model weight integrity), AI-MDL.5 (model weight hashing)
Coverage: Full
MCP05: Command Injection in Tool Execution
MCP05:2025
Unsafe command execution through MCP tools using unsanitized input
AI agents construct and execute system commands, shell scripts, or API calls using untrusted input without proper validation. 43% of MCP CVEs filed in early 2026 were shell injections.
SWT3 Response: The
Procedures: AI-TOOL.1 (tool call witnessing), AI-GRD.3 (policy version binding)
YAML fields:
Coverage: Full
.swt3.yaml tool blocklist prevents known-dangerous tools from executing (e.g., shell_exec, rm_*). Every tool call is witnessed via AI-TOOL.1, recording the tool name, input hash, output hash, latency, and success/failure status. The MCP server's evaluateToolPolicy() function checks each tool call against the declared policy before execution. Velocity limits (max_velocity) cap the rate of tool execution, preventing automated exploitation loops.
Procedures: AI-TOOL.1 (tool call witnessing), AI-GRD.3 (policy version binding)
YAML fields:
mcp_policy.tool_blocklist, mcp_policy.max_velocity, mcp_policy.fail_secure
Coverage: Full
MCP06: Tool Description Poisoning
MCP06:2025
Malicious MCP server embedding instructions in tool descriptions to modify agent behavior
A rogue MCP server injects adversarial instructions into its tool description metadata, causing the LLM to alter its behavior toward other trusted servers.
SWT3 Response: The Trust Mesh protocol requires agents to present cryptographic credentials before exchanging data or invoking tools. An MCP server that cannot present a valid Trust Mesh credential (tenant ID, witnessed procedures, clearing level, HMAC signature) is denied interaction. The
Procedures: AI-TRUST.1 (trust verification), AI-TRUST.2 (credential presentation), AI-CHAIN.1 (chain witnessing)
YAML fields:
Coverage: Full
trust_mesh.mode: strict setting requires signature verification for all peer connections. Additionally, the mcp_policy.require_trust_level field sets the minimum trust tier required for tool invocation.
Procedures: AI-TRUST.1 (trust verification), AI-TRUST.2 (credential presentation), AI-CHAIN.1 (chain witnessing)
YAML fields:
trust_mesh.mode, trust_mesh.require_signature, mcp_policy.require_trust_level
Coverage: Full
MCP07: Insufficient Authentication and Authorization
MCP07:2025
Failure to verify identities or apply access controls during MCP interactions
Multiple agents, users, and services exchanging data without proper identity validation exposes critical attack paths.
SWT3 Response: Every witness anchor includes
Procedures: AI-ID.1 (agent identity), AI-ACC.1 (access control), AI-TRUST.1/TRUST.2 (bilateral verification), NHI-SCOPE.1, NHI-CYCLE.1, NHI-PRIV.1, NHI-ROTATE.1, NHI-AGENT.1, NHI-REVOKE.1, NHI-EXPIRE.1
NSA alignment: CSI MCP Security, Sections: Identity and Access Management, Authentication
Coverage: Full (strongest coverage area -- 7 dedicated NHI procedures + 3 AI identity procedures)
agent_id (AI-ID.1), binding each action to a specific agent identity. The HMAC-SHA256 payload_signature provides non-repudiation. The NHI namespace (7 procedures) provides the complete credential lifecycle that the NSA guidance requires: scope attestation (NHI-SCOPE.1), credential provisioning (NHI-CYCLE.1), privilege changes (NHI-PRIV.1), rotation (NHI-ROTATE.1), agent-to-agent delegation with inherited authority bounds (NHI-AGENT.1), revocation with cascade (NHI-REVOKE.1), and temporal expiration with grace periods (NHI-EXPIRE.1). The authorization_expires field ensures that long-lived credentials -- the specific risk the NSA highlights when noting "roughly 40% expose their tools with no authentication at all" -- produce evidence of their temporal validity at the time of each invocation. The Trust Mesh bilateral verification protocol authenticates agents before data exchange.
Procedures: AI-ID.1 (agent identity), AI-ACC.1 (access control), AI-TRUST.1/TRUST.2 (bilateral verification), NHI-SCOPE.1, NHI-CYCLE.1, NHI-PRIV.1, NHI-ROTATE.1, NHI-AGENT.1, NHI-REVOKE.1, NHI-EXPIRE.1
NSA alignment: CSI MCP Security, Sections: Identity and Access Management, Authentication
Coverage: Full (strongest coverage area -- 7 dedicated NHI procedures + 3 AI identity procedures)
MCP08: Insecure Deserialization and State Injection
MCP08:2025
Unsafe handling of MCP responses and state management
Risks related to manipulating serialized data exchanged between MCP clients and servers to alter application state.
SWT3 Response: The SWT3 fingerprint formula is deterministic and locked:
Procedures: Architectural (fingerprint formula, WAL, Merkle accumulator)
Coverage: Full
SHA256("WITNESS:{tenant}:{proc}:{fa}:{fb}:{fc}:{ts_ms}").hex()[:12]. The formula cannot be manipulated by injecting state because it operates on fixed, typed inputs. The Write-Ahead Log (WAL) uses append-only JSONL format with sequence numbers and checkpoint verification, preventing state injection into the forensic record. Merkle accumulation uses domain-separated prefixes (SWT3:LEAF: / SWT3:NODE:) to prevent second-preimage attacks on the tree structure.
Procedures: Architectural (fingerprint formula, WAL, Merkle accumulator)
Coverage: Full
MCP09: Shadow MCP Servers
MCP09:2025
Unauthorized MCP server deployments outside governance
Agents dynamically discover and connect to MCP servers. Without a trusted registry, a shadow server can impersonate a legitimate one and intercept tool calls.
SWT3 Response: The Trust Mesh protocol addresses shadow servers directly. When
Procedures: AI-TRUST.1 (trust verification), AI-CHAIN.1 (chain witnessing of denied handshakes)
YAML fields:
Coverage: Full
trust_mesh.mode: strict is configured, the agent will only interact with MCP servers that can present a valid, signed credential from a trusted tenant. The trust_mesh.trusted_tenants whitelist explicitly declares which tenants are authorized. Any server that cannot present a valid credential is denied. The denied attempt is recorded as a witness anchor, creating forensic evidence of the unauthorized connection attempt.
Procedures: AI-TRUST.1 (trust verification), AI-CHAIN.1 (chain witnessing of denied handshakes)
YAML fields:
trust_mesh.mode: strict, trust_mesh.trusted_tenants, trust_mesh.deny_tenants
Coverage: Full
MCP10: Context Over-Sharing and Sensitive Data Exposure
MCP10:2025
Sensitive information from one task or agent exposed to another through shared context
When context windows are shared, persistent, or insufficiently scoped, sensitive information leaks across tasks, users, or agents.
SWT3 Response: The clearing engine is designed precisely for this risk -- and it solves a problem no other audit trail standard addresses: cross-jurisdictional evidence graduation. Four clearing levels (0=Analytics, 1=Standard, 2=Sensitive, 3=Classified) progressively strip content from witness anchors before any data crosses a boundary. At Level 1 (default), raw prompts and responses never leave the deployment infrastructure -- only irreversible SHA-256 hashes and numeric factors are transmitted. At Level 3, even the model identifier is hashed.
The same inference event can produce different evidence artifacts depending on the jurisdictional context. A multinational deploying AI across EU, US, and APAC can witness the same model with Level 1 in the EU (GDPR-safe -- no personal data in the anchor), Level 2 in the US (model identity visible for NIST compliance), and Level 3 internally under legal hold. The fingerprint formula is identical across all levels -- the same SHA-256 fingerprint regardless of clearing level -- so an auditor can verify cross-border consistency without ever seeing the content.
The
Procedures: Clearing engine (Levels 0-3), AI-DATA.1 (data governance), AI-RAG.1 (RAG provenance), AI-CLR.2 (clearing fidelity attestation)
Payload fields:
Coverage: Full (unique capability -- no competing standard offers jurisdiction-aware evidence graduation)
The same inference event can produce different evidence artifacts depending on the jurisdictional context. A multinational deploying AI across EU, US, and APAC can witness the same model with Level 1 in the EU (GDPR-safe -- no personal data in the anchor), Level 2 in the US (model identity visible for NIST compliance), and Level 3 internally under legal hold. The fingerprint formula is identical across all levels -- the same SHA-256 fingerprint regardless of clearing level -- so an auditor can verify cross-border consistency without ever seeing the content.
The
jurisdiction, legal_basis, and purpose_class CJT fields survive all clearing levels, providing regulatory context even when the content itself is stripped. This is the architectural capability that enables a single audit trail to satisfy GDPR (EU), PIPL (China), PDPA (Singapore), and US sector-specific requirements simultaneously. No other MCP audit trail standard -- including the IETF Agent Audit Trail draft (draft-sharif-agent-audit-trail) -- addresses this cross-jurisdictional requirement.
Procedures: Clearing engine (Levels 0-3), AI-DATA.1 (data governance), AI-RAG.1 (RAG provenance), AI-CLR.2 (clearing fidelity attestation)
Payload fields:
clearing_level, jurisdiction, legal_basis, purpose_class (CJT fields, survive all clearing levels)
Coverage: Full (unique capability -- no competing standard offers jurisdiction-aware evidence graduation)
Summary Table
| Risk | Title | SWT3 Response | Key Procedures | Coverage |
|---|---|---|---|---|
| MCP01 | Token Mismanagement | NHI credential lifecycle (rotate, expire, revoke), authorization_expires field | AI-ID.1, NHI-ROTATE.1, NHI-EXPIRE.1, NHI-SCOPE.1 | Full |
| MCP02 | Excessive Agency | Credential scope attestation, privilege change witnessing, authorization_scope field | NHI-SCOPE.1, NHI-PRIV.1, AI-TOOL.1, AI-ACC.1 | Full |
| MCP03 | Prompt Injection | Tool integrity hashing detects schema poisoning; guardrail witnessing records filter results | AI-MCP.2, AI-SEC.1, AI-GRD.1, AI-GRD.2 | Full |
| MCP04 | Supply Chain Attacks | Skill manifest + model weight witnessing at initialization | AI-SKILL.1, AI-MDL.1, AI-MDL.5 | Full |
| MCP05 | Command Injection | Tool blocklists, velocity limits, tool call witnessing | AI-TOOL.1, AI-GRD.3 | Full |
| MCP06 | Tool Description Poisoning | Tool integrity attestation hashes schema at each invocation; drift flag detects rug pulls | AI-MCP.2, AI-TRUST.1/2, AI-CHAIN.1 | Full |
| MCP07 | Insufficient Auth | Server auth attestation records method per invocation; NHI lifecycle + Trust Mesh | AI-MCP.3, AI-ID.1, NHI-* (7 procs), AI-TRUST.1/2 | Full |
| MCP08 | Insecure Deserialization | Deterministic fingerprint formula, domain-separated Merkle, append-only WAL | Architectural | Full |
| MCP09 | Shadow MCP Servers | Server discovery attestation inventories servers and flags unauthorized; Trust Mesh strict mode | AI-MCP.4, AI-TRUST.1, AI-CHAIN.1 | Full |
| MCP10 | Context Over-Sharing | 4-level clearing engine with cross-jurisdictional evidence graduation (unique) | Clearing engine, AI-DATA.1, AI-CLR.2 | Full |
Coverage key: Full = SWT3 directly addresses the risk through witnessing, attestation, or policy-as-code evaluation. Partial = SWT3 provides supporting evidence; the primary defense requires additional tooling (e.g., prompt filtering for MCP03).
OWASP Agentic Top 10 Profile
SWT3 includes a built-in security profile that pre-configures the SDK for OWASP Agentic Top 10 alignment. Apply it with a single line in your configuration:
profile: owasp-agentic-top10
api_key_env: SWT3_API_KEY
tenant_id: YOUR_TENANT
agent_id: your-agent
signing_key_env: SWT3_SIGNING_KEYThis profile enables: clearing level 1, required signing, required agent identity, AI-INF.1 + AI-GRD.1 + AI-TOOL.1 + AI-CHAIN.1 + NHI-SCOPE.1 + NHI-EXPIRE.1 procedures, Trust Mesh in permissive mode, velocity limits (10/60s), chain depth limits (8), token budget (100K), Merkle accumulation, authorization expiry enforcement, and fail-secure mode. See the repository for the full profile template.
Positioning note: SWT3 is an independent witness protocol. It records what happened and whether it matched declared policy. It does not perform prompt filtering, malware scanning, or network-level interception. For risks like MCP03 (prompt injection), SWT3 witnesses whether your existing security tools (Prompt Guard, NeMo Guardrails, etc.) were active and what they detected. The witness record is the evidence that your defenses were operational. The defenses themselves are your choice.