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).
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 (18 tools, listed on the MCP Registry as io.tenova/swt3-witness) provides witnessing for every tool call in an MCP session. The .swt3.yaml configuration file declares policies that are evaluated at each tool invocation.
MCP01: Token Mismanagement and Secret Exposure
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_API_KEY, SWT3_SIGNING_KEY), never hard-coded values. The .swt3.yaml schema supports api_key_env and signing_key_env directives that reference environment variables by name. 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 HMAC-SHA256 signing key is used for non-repudiation but never appears in any anchor payload or log entry.
Procedures: AI-ID.1 (agent identity via signing key, not raw token), AI-INF.1 (hashes only, no raw content)
Coverage: Full
MCP02: Excessive Agency and Privilege Escalation
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.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. The swt3 doctor CLI validates the policy file against the schema and flags misconfigurations before deployment.
Procedures: AI-GRD.3 (policy version binding), AI-TOOL.1 (tool call witnessing), AI-ACC.1 (access control witnessing)
YAML fields:
mcp_policy.tool_allowlist, mcp_policy.tool_blocklist, policy_version
Coverage: Full
MCP03: Prompt Injection and Context Spoofing
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.
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
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.
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
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.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
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.
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
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.
agent_id (AI-ID.1), binding each action to a specific agent identity. The HMAC-SHA256 payload_signature provides non-repudiation -- the anchor proves which SDK instance minted it. The Trust Mesh bilateral verification protocol (presentCredential() / verifyTrust()) authenticates agents before data exchange. Trust levels (Denied, Basic, Verified, Attested, Sovereign) provide tiered authorization. The trust_mesh.deny_agents and trust_mesh.deny_tenants fields provide explicit blocklists.
Procedures: AI-ID.1 (agent identity), AI-ACC.1 (access control), AI-TRUST.1/TRUST.2 (bilateral verification)
YAML fields:
agent_id, signing_key, trust_mesh.trusted_agents, trust_mesh.deny_agents
Coverage: Full
MCP08: Insecure Deserialization and State Injection
Unsafe handling of MCP responses and state management
Risks related to manipulating serialized data exchanged between MCP clients and servers to alter application state.
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
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.
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
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.
Procedures: Clearing engine (Levels 0-3), AI-DATA.1 (data governance), AI-RAG.1 (RAG provenance -- context source tracking)
YAML fields:
clearing_level, jurisdiction, legal_basis, purpose_class
Coverage: Full
Summary Table
| Risk | Title | SWT3 Response | Key Procedures | Coverage |
|---|---|---|---|---|
| MCP01 | Token Mismanagement | Env var secrets, clearing engine strips all sensitive data | AI-ID.1, AI-INF.1 | Full |
| MCP02 | Excessive Agency | Tool allowlists/blocklists, policy version binding | AI-GRD.3, AI-TOOL.1, AI-ACC.1 | Full |
| MCP03 | Prompt Injection | Witnesses guardrail results, gatekeeper mode | AI-SEC.1, AI-GRD.1, AI-GRD.2 | Partial |
| 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 | Trust Mesh credential verification, trust level gating | AI-TRUST.1/2, AI-CHAIN.1 | Full |
| MCP07 | Insufficient Auth | Agent identity, HMAC signing, Trust Mesh bilateral verification | AI-ID.1, AI-ACC.1, AI-TRUST.1/2 | Full |
| MCP08 | Insecure Deserialization | Deterministic fingerprint formula, domain-separated Merkle, append-only WAL | Architectural | Full |
| MCP09 | Shadow MCP Servers | Trust Mesh strict mode, tenant whitelisting, denied attempt witnessing | AI-TRUST.1, AI-CHAIN.1 | Full |
| MCP10 | Context Over-Sharing | 4-level clearing engine, jurisdiction fields, per-agent clearing | Clearing engine, AI-DATA.1, AI-RAG.1 | 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 procedures, Trust Mesh in permissive mode, velocity limits (10/60s), chain depth limits (8), token budget (100K), Merkle accumulation, and fail-secure mode. See the repository for the full profile template.