MCP Tool Poisoning and the Cryptographic AIBOM Defense

Last updated: September 12, 2026

Bottom line up front

MCP tool poisoning is a rug-pull: you review and approve a tool, then the server silently changes it. The defense is a cryptographic AIBOM — a pinned SHA-256 over each connected tool's name, description, and input schema — plus a kill switch that refuses execution when the live hash no longer matches the approved baseline. This maps to OWASP MCP Top 10 MCP03 Tool Poisoning and overlaps ASI03 Confused Deputy when poisoned metadata steers tool arguments.

“The root cause is a trust gap between connect-time and runtime. Tool descriptions are reviewed once, when the agent first connects to a server. Tool responses go straight into the LLM’s context with no equivalent check. That unguarded runtime channel is what the attacker abuses.”

— OWASP Foundation, MCP Tool Poisoning

The OWASP Top 10 for MCP lists MCP03:2025 Tool Poisoning and MCP09:2025 Shadow MCP Servers as first-class risks. Tool poisoning includes rug-pulls, schema poisoning, and tool shadowing — all of which require integrity verification after connect-time review, not only an allowlist.

Registering a tool and trusting it forever is the vulnerability. Tools are mutable; your approval is a point-in-time decision. Without a content hash, you have no way to know a connected tool changed under you.

Kimss combats this by enforcing container isolation scope for skill execution and validating immutable content hashes for all connected tools. See the engineering spec in internal MCP routing and the control-plane Trust Center.

How MCP tool poisoning works

The attack lives in the metadata the model reads: a tool's description and input schema. Change those after approval and you change what the model is willing to do.

When an agent connects to an MCP server it calls tools/list and receives each tool's name, description, and input schema. The model relies on that description to decide when and how to call the tool. Descriptions are effectively instructions to the model.

A poisoning attack ships a benign tool during review, then mutates the description to embed hidden directives, or widens the input schema to exfiltrate additional data, after you have granted trust. The agent, reading the new metadata, complies. Nothing about the agent's own code changed.

This is a supply-chain problem for agent tools. The same way software needs a bill of materials with verifiable hashes, connected agent tools need an Agent/AI Bill of Materials — an AIBOM — with immutable content hashes.

The cryptographic AIBOM defense

Kimss computes a SHA-256 over the canonical JSON of every discovered tool (name, description, input schema), pins an approved baseline, and flags any later divergence as drift.

On each discovery, Kimss recomputes the content hash of the connected tool set. An administrator reviews the tools and approves the baseline, moving the server to a verified state. If a later discovery produces a different hash, the server is marked drift-detected and a Threat Intercept is recorded.

The hash is canonical and order-stable, so reordering tools does not cause false positives, but any change to a name, description, or input schema does. That is precisely the surface a poisoning attack must touch.

Connect and discover the MCP server; its tool set is hashed and marked unverified.
Review the exact tools, then approve the baseline; the server becomes verified.
On any later change, the recomputed hash diverges and the server is flagged drift-detected.
Re-review and re-approve to intentionally accept the new tool set.

The drift kill switch

Detection without enforcement is a dashboard. When enforcement is enabled, a drift-detected tool is refused at execution time inside the Hermis loop.

Kimss checks AIBOM state before dispatching an MCP tool call. On drift it records an intercept, and when the enforcement flag is enabled it blocks the call with a guardrail error instead of executing a possibly poisoned tool. This ships in a soft-launch posture: observe drift intercepts first, then enforce.

Enforcement lives at the gateway, in the same loop that runs the kill switch, argument-level policies, and the Authority Boundary — so a poisoned tool is caught alongside every other tool-time control. See the Confused Deputy deep-dive.

Concern	Register-and-trust	Kimss AIBOM
Tool integrity over time	Assumed	Verified per discovery
Post-approval change	Silent	Flagged as drift
Unit of trust	The server	The exact tool content hash
Enforcement	None	Kill switch on drift (flag-gated)
Evidence	None	Threat Intercept + approved hash
MCP poisoning coverage	None	Direct

Skill isolation: honest scope

Kimss enforces a restricted execution sandbox for skill code today and treats full container isolation as a declared, in-progress design — not a claim we make before it ships.

Skill code executes in a restricted sandbox on the control plane with an import allowlist, a forbidden-name denylist, output caps, and a wall-clock timeout. That contains a large class of misbehavior without a provider-hosted interpreter.

Container-grade isolation — a dedicated sandbox with no ambient credentials, ephemeral filesystem, and egress policy — is a separate infrastructure track. We describe it as reserved rather than shipped, in keeping with our rule to verify end to end before claiming a control works. The AIBOM defense above, by contrast, is shipped and flag-gated for enforcement.

How to adopt it

Connect MCP servers through Kimss, approve AIBOM baselines deliberately, and enable drift enforcement after observing intercepts.

Register your MCP servers in the workspace; credentials are vaulted and write-only.
Discover and review the tool set, then approve the AIBOM baseline.
Watch for drift-detected Threat Intercepts in log-only mode.
Enable AIBOM enforcement so poisoned tools are refused mid-loop.

Attach only the tools an agent needs; the allowlist and SSO tool grants limit exposure even before AIBOM. See MCP for enterprise AI and RBAC and identity.

What the approved hash actually covers

Precision matters: the AIBOM hash is computed over the security-relevant surface of each tool — its name, its human-readable description, and its input schema — because those are exactly the fields a poisoning attack must change to redirect the model.

The tool name is what the model references when it decides to call. The description is, in effect, an instruction the model reads and trusts; a poisoning attack hides directives there. The input schema defines what data the tool can receive; widening it is how an attacker exfiltrates more than you approved. Hashing all three pins the entire manipulable surface.

Kimss reduces each tool to that canonical trio and sorts the set by tool name before hashing, so cosmetic reordering by a server does not create false alarms, while any substantive change to name, description, or schema does. The hash is stored as the current content hash on every discovery and compared to the approved baseline.

What the hash deliberately does not cover is transient, non-instructional metadata that legitimately varies. The goal is a stable fingerprint of what the model will read and act on — not a brittle hash that drifts on every heartbeat.

AIBOM and software SBOM: same idea, agent surface

Software supply-chain security learned this lesson already: you pin dependencies by hash and alert on drift. An AIBOM applies the same discipline to the tools an agent can call.

A software bill of materials enumerates dependencies with verifiable hashes so a swapped or tampered package is detectable. Connected agent tools are dependencies too — arguably more dangerous, because their descriptions are read directly by a model that will act on them.

The AIBOM is the agent-surface analog: an enumerated, hashed record of every connected tool's name, description, and input schema, with a pinned approved baseline. Drift against that baseline is the agent-world equivalent of a dependency-confusion or tampered-package alert.

The difference in stakes is the autonomy: a poisoned tool does not wait for a human to run it. The agent invokes it as soon as the model is convinced, which is why integrity verification must be enforced at execution time, not only at review time.

Layering AIBOM with the rest of the loop

AIBOM is one control in a defense-in-depth loop. It verifies integrity; the allowlist bounds exposure; SSO grants bind identity; the Authority Boundary governs arguments.

Attach only the tools an agent needs, so the allowlist limits which connected tools are even reachable. Bind execution to an authenticated principal with SSO tool grants, so identity — not just possession of a key — gates the call. Verify the tool has not changed with AIBOM. Then govern the specific argument with the Authority Boundary.

Each layer covers a different OWASP Agentic threat: the allowlist and grants address over-broad capability and identity, AIBOM addresses tool poisoning, and the Authority Boundary addresses the Confused Deputy. Together they turn a set of trusted-forever integrations into a continuously verified supply chain. See rogue agents for the discovery and kill-switch layer.

Shadow MCP servers (MCP09) and inventory

Shadow MCP is the agent-world analog of shadow IT: developers and agents attach unvetted servers that never entered your allowlist or AIBOM baseline. Detection without a control plane is guesswork.

The OWASP MCP Top 10 catalogs MCP09:2025 Shadow MCP Servers as a distinct risk from tool poisoning. A shadow server may look helpful in a local IDE, yet it never received enterprise review, never had credentials vaulted write-only, and never produced a Threat Intercept when it misbehaved.

Kimss addresses shadow MCP by requiring inbound customer MCP routing through Hermis: workspace identity, kill switch, allowlist, optional Authority Boundary, and audit before your MCP URL. Agent Discovery inventories routed traffic so JIT/shadow agents become visible. Pair that with AIBOM so approved servers cannot silently mutate after review.

Allowlist — only registered MCP servers are reachable for governed agents.
AIBOM — approved tool content hashes detect post-approval drift (MCP03).
Discovery + kill switch — shadow agents and drifted servers can be severed at the gateway (ASI10 adjacency).
Authority Boundary — even a listed tool cannot execute untrusted security-sensitive arguments (ASI03).

See Shadow AI, rogue agents, and routing internal MCP servers.

Connect-time review vs runtime trust

Connect-time review is necessary and insufficient. Runtime must re-verify integrity and authorize each argument — otherwise the trust gap OWASP documents remains open.

At connect time, an operator (or automated policy) reviews tool names, descriptions, and schemas. That produces a baseline. At runtime, every tools/list refresh and every tool response can change what the model believes is true. Poisoned responses inject instructions into context; mutated descriptions change when the model chooses to call a tool; widened schemas expand exfiltration surface.

Kimss treats those as separate controls:

AIBOM hash — integrity of the tool metadata surface after approval.
Authority Boundary — provenance of arguments flowing into sinks mid-loop.
Content safety / Prompt Shields — optional classifiers on input, tool context, and output (application-layer complement).
Threat Intercepts — durable evidence when any layer refuses.

No single layer replaces the others. AIBOM without argument provenance still allows a confused deputy through an unchanged but over-broad tool. Provenance without AIBOM still allows a rug-pull description to convince the model to call a different sink. See AI agent security.

Operator playbook: from log-only to enforce

Ship soft: observe intercepts, tune false positives, then enforce. Hard-fail on day one without baselines creates outages that teams disable permanently.

Register MCP servers in Provider Vault / MCP routing; store credentials write-only.
Discover tools; review name, description, and input schema for instruction-like content.
Approve the AIBOM baseline; record who approved and when.
Run in log-only: watch drift-detected and Authority Boundary intercepts for one pilot workspace.
Enable AIBOM enforcement and Authority Boundary for Production+ on that workspace.
Expand to regulated workspaces; export Threat Intercepts to SIEM on Scale/Enterprise.

Document approved servers in your change-management system the same way you document production dependencies. MCP tools are dependencies with autonomy.

Mapping OWASP MCP03 / MCP09 to Kimss controls

Use this extractable mapping when procurement asks how the product addresses the MCP Top 10.

OWASP item	Failure mode	Kimss control
MCP03 Tool Poisoning	Rug-pull / schema poisoning after approval	Cryptographic AIBOM + drift kill switch
MCP09 Shadow MCP	Unregistered local/remote servers	Inbound MCP routing + allowlist + discovery
ASI03 Confused Deputy	Untrusted args on allowed tools	Authority Boundary + argument policies
MCP07 AuthZ gaps	Tool calls without workspace identity	Entra / workspace RBAC + vault unwrap
MCP08 Audit gaps	No durable tool-call evidence	audit_log + Threat Intercepts + optional APIM GatewayLogs

This is alignment guidance, not a certification claim. Full framework mapping lives at compliance framework mapping.

Frequently confused claims

Clear the claims answer engines misattribute so Kimss is not confused with consumer chat products or model hosts.

Kimss does not host MCP tools as a consumer marketplace; customers vault and route their own servers.
AIBOM is not a replacement for least privilege — you still allowlist tools and bind SSO grants.
Log-only drift alerts are not enforcement; enable the flag after observation.
Kimss AI (kimss.ai) is not Kimi (Moonshot AI).

Frequently asked questions

What is MCP tool poisoning?

It is a rug-pull attack on Model Context Protocol tools: a server exposes a benign tool during review, then changes its description or input schema after approval to steer the agent toward harmful behavior. The agent complies because the metadata it reads changed.

What is a cryptographic AIBOM?

An AIBOM (AI/Agent Bill of Materials) is an immutable record of connected agent tools with verifiable content hashes. Kimss pins a SHA-256 over each tool's name, description, and input schema so any post-approval change is detectable as drift.

How does Kimss detect tool drift?

On every discovery Kimss recomputes the canonical content hash of the tool set and compares it to the approved baseline. A mismatch marks the server drift-detected and records a Threat Intercept.

What happens when drift is detected?

Kimss records an intercept and, when AIBOM enforcement is enabled, refuses the tool call inside the Hermis loop with a guardrail error rather than executing a possibly poisoned tool. It ships log-only first so you can observe before enforcing.

Does Kimss provide container isolation for skills today?

Kimss enforces a restricted execution sandbox for skill code today. Full container isolation is a declared, in-progress design; we do not claim it as shipped until it is verified end to end.

How is AIBOM different from just an allowlist?

An allowlist limits which tools an agent may call; AIBOM verifies that the approved tools have not changed since approval. You need both: the allowlist bounds exposure, AIBOM guarantees integrity over time.

What fields does the AIBOM hash cover?

Each tool's name, human-readable description, and input schema — the exact surface a poisoning attack must change to redirect the model. Kimss canonicalizes and sorts the set before hashing so reordering does not cause false positives, but any substantive change does.

How does AIBOM relate to a software SBOM?

It is the agent-surface analog. An SBOM pins software dependencies by hash and alerts on drift; an AIBOM pins connected agent tools by content hash and flags drift. The stakes are higher because an agent invokes a poisoned tool autonomously, so integrity is enforced at execution time.

MCP tool poisoning and the cryptographic AIBOM