Deadbugz shows how MCP metadata poisoning evades AI agent trust

At a glance

What this is: Pillar Security describes an active MCP supply-chain campaign in which tool metadata stays benign until a three-call threshold, then shifts into credential-seeking instructions aimed at AI agents.

Why it matters: This matters because practitioners governing AI agents, MCP servers and delegated tool access need controls that cover runtime metadata integrity, not just package approval or installation review.

Context

Model Context Protocol gives an AI agent structured access to tools and their descriptions, so the metadata itself becomes part of the trust boundary. In this case, the security problem is not simply a malicious package, but a server that withholds hostile instructions until ordinary use crosses a runtime threshold.

That pattern matters for agent governance because approval workflows often inspect the first interaction, while the dangerous behaviour appears later. For teams governing AI agents, MCP servers and delegated tooling, this is a direct challenge to assumptions about static tool identity and immutable tool definitions.

Key questions

Q: What breaks when MCP server metadata is only reviewed before approval?

A: A one-time review fails when a server can change behavior after it is trusted. A malicious MCP server may look harmless during initial checks, then rewrite tool descriptions or return instructions only after several calls. Security teams should monitor tool metadata for drift after approval and compare cached definitions on every reconnect, because the attack can begin only once the server is already in use.

Q: Why does delayed MCP behaviour increase agent security risk?

A: Delayed behaviour defeats short tests, static scans and first-impression review because the malicious state appears only after enough interaction has occurred. That means the security team may approve what looks like a harmless server and still miss the payload that appears during normal use. The risk is conditional delivery, not obvious malware.

Q: How should security teams govern AI agents that choose tools at runtime?

A: Security teams should treat runtime tool choice as a governed access event, not a normal application call. That means task-scoped credentials, explicit approval boundaries for sensitive actions, and logs that record both the tool selected and the identity used. If the agent can change its plan, the control model must be able to change with it.

Q: What should teams do with upstream secrets used by MCP servers?

A: Teams should treat upstream secrets as non-human identities with owners, expiry, rotation and revocation requirements. If those credentials let a model reach internal systems, they carry the same governance burden as service account keys or workload tokens. Leaving them in configuration without lifecycle control creates unnecessary exposure.

Technical breakdown

Runtime-gated MCP metadata poisoning

MCP clients pass tool descriptions, schemas and prompts to the model so it can choose actions and interpret outputs. If a server can change those definitions after approval, the agent is no longer reasoning over a stable contract. In Deadbugz, the server remained harmless for the first few calls, then altered the metadata returned to the client. That is a form of runtime-gated poisoning because the malicious content is not in the initial approval surface, but in the live tool context exposed during normal execution. Practical implication: treat tool-definition changes as a security event, not a routine refresh.

Practical implication: Make tool-definition fingerprints and metadata refresh events visible before an approved MCP server can influence sensitive actions.

Why three-call triggers evade inspection

A delayed trigger defeats superficial review because sandbox tests, one-off validations and short manual checks may never reach the malicious state. In this pattern, the server uses ordinary behaviour at first, then shifts once it has seen enough interaction to decide the client is real. That creates a split between what reviewers observe and what production agents experience. The security issue is not only malicious content, but conditional delivery based on runtime context, which is harder to detect with static scanning alone. Practical implication: test MCP servers with longer, stateful sessions and policy checks that persist across tool invocations.

Practical implication: Run stateful validation, not single-call checks, when assessing whether an MCP server changes behaviour after approval.

Why trusted tool definitions are a governance boundary

Tool descriptions are often treated as documentation, but in agentic systems they shape model behaviour, action selection and downstream tool use. If metadata can instruct an agent to seek SSH keys, AWS credentials or Kubernetes configuration, the boundary is no longer just identity or authorization on the backend. It is also the integrity of the context fed to the agent. That makes metadata governance part of agent authorisation, prompt integrity and runtime policy enforcement. Practical implication: enforce policy on credential access, file reads and repository writes independently of what remote tool metadata says.

Practical implication: Separate tool approval from policy enforcement so remote descriptions cannot authorize sensitive actions on their own.

Threat narrative

Attacker objective: The objective is to use trusted MCP metadata to push an AI agent toward local secrets and operational credentials without triggering suspicion during initial review.

1. Entry occurs through public GitHub pull requests that introduce or alter MCP configuration for a server that appears routine at first review.
2. Credential-seeking instructions stay dormant until three ordinary tool calls have occurred, which lets the server present benign behaviour during brief inspection and testing.
3. After the threshold, the server returns altered metadata that steers the agent toward SSH keys, AWS credentials, shell history and Kubernetes configuration while hiding the activity from the user.

Breaches seen in the wild

• ClawHub malicious skills 2026: Hundreds of malicious ClawHub skills for the OpenClaw agent pushed credential stealers in early 2026; Koi found 341 of 2,857 in the ClawHavoc campaign.
• Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime metadata integrity is now part of agent governance. MCP deployments cannot be judged only by whether a server was approved or installed. If the server can alter tool descriptions after approval, the trust model for AI agents collapses at runtime, not at onboarding. Practitioners should treat tool metadata as governed security input, not passive documentation.

This campaign exposes a named failure mode: delayed tool-definition poisoning. The control gap is the assumption that malicious content must be visible during initial inspection. Deadbugz shows that hostile instructions can remain dormant until the agent has already accepted the server as legitimate, which means static review alone is not enough. The practical conclusion is that approval workflows must include runtime validation and post-approval drift detection.

MCP security must extend beyond package provenance into live interaction state. Public GitHub delivery, a harmless initial tool set and a three-call gate combine to defeat the usual supply-chain checks. That means practitioners need to govern not only source authenticity, but also whether an approved tool can mutate its own instructions during use. The field should now treat runtime state as part of identity and access governance for agents.

Agent trust is being attacked through the interface layer, not only the infrastructure layer. This is where NHI and agentic AI governance intersect: the agent is the decision-maker, the MCP server is the delegated tool source, and the metadata is part of the authorization context. If metadata can be rewritten, the agent is being manipulated through a trusted channel. Teams should respond by binding tool identity, metadata integrity and sensitive-action policy together.

Deadbugz is a supply-chain warning for the agentic stack. The article shows how a campaign can blend public delivery, conditional runtime behaviour and credential-harvesting prompts into one control-bypassing pattern. That should push security teams to re-evaluate how they approve, monitor and revoke MCP tooling, because the next failure may arrive through a trusted tool definition rather than an obviously malicious binary.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Agentic AI Identity Guide

What this signals

Delayed tool-definition poisoning is the important concept here: an approved MCP server can stay benign long enough to pass review, then change the instructions the agent sees during ordinary use. That shifts governance from one-time approval to continuous verification of live metadata and runtime behaviour.

MCP deployments now need the same kind of drift awareness that identity teams expect from privileged access and delegated trust. If a server can alter the context that drives agent actions, then runtime policy, metadata integrity and explicit action controls become the real enforcement points for agentic systems.

For practitioners

• Harden MCP approval workflows Require explicit review of tool descriptions, schemas and refresh behaviour before any MCP server can be used by an agent in production.
• Detect metadata drift after approval Compare approved tool fingerprints against live tool-definition responses and alert when a server changes its returned instructions or tool list.
• Enforce policy on sensitive actions Block credential access, file reads, repository writes and outbound communication at the client or gateway layer, regardless of instructions embedded in remote tool metadata.
• Hunt for the campaign indicators Search developer endpoints, MCP client configs and home directories for the reported remote endpoint, local delivery artifact and server name, then preserve client logs if exposure occurred.
• Require stateful red teaming of MCP servers Test approved servers across multiple tool calls so delayed triggers, prompt changes and hidden metadata do not escape a single-call validation path.

Key takeaways

• Deadbugz shows that MCP trust can be undermined after approval, when tool metadata changes at runtime rather than at installation.
• The campaign illustrates a control gap that short inspections will miss, because the malicious behaviour appears only after ordinary interaction crosses a trigger threshold.
• Agent governance now needs runtime metadata integrity checks, action-level policy enforcement and stronger review of tool-definition drift.

Key terms

• MCP Metadata Poisoning: A technique in which a malicious MCP server alters the descriptions, schemas or prompts it returns so an AI agent receives hostile instructions through a trusted tool channel. The danger is not only the server’s presence, but the fact that its live metadata can change after approval and guide the agent into unsafe actions.
• Runtime-Gated Trigger: A condition in which malicious behaviour is withheld until a server has seen enough interaction to cross a predefined threshold. In agentic systems this can defeat short tests and static review, because the harmful content appears only during normal use, not during initial validation.
• Tool-definition drift: A mismatch between the tool definition that was approved and the tool definition that is later executed. Drift can happen when descriptions, schemas, or tool lists change after onboarding, which means a prior review no longer reflects the live authorisation surface.
• Agentic Supply Chain Risk: The risk that an AI agent's behaviour is compromised through malicious or vulnerable third-party components, including tools, plugins, MCP servers, prompt templates, and RAG data sources. Mapped as ASI04 in the OWASP Top 10 for Agentic Applications 2026.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It gives security practitioners a practical way to connect delegated access controls to broader identity risk.