Deadbugz shows how MCP metadata poisoning evades AI agent trust

At a glance

What this is: This is an analysis of an active MCP supply-chain campaign that hides malicious instructions behind benign tool metadata until an AI agent makes several tool calls.

Why it matters: It matters because AI agent governance now has to treat tool definitions, refreshes, and runtime context as security controls, not just the underlying endpoint or package.

By the numbers:

• The public delivery operation created 23 pull requests in a 74-minute period, from 9:52 PM to 11:07 PM UTC on August 10, 2026.
• The reviewed set included 17 remote-MCP configurations, four local-script configurations, and two directory or listing submissions.
• In 2025, a counterfeit postmark-mcp package gained adoption before an update added covert outbound-email copying.

👉 Read Pillar Security's analysis of Deadbugz and MCP metadata poisoning

Context

Model Context Protocol governance is becoming part of AI agent security because the client does not just call a tool, it also trusts the metadata that describes what that tool can do. In this campaign, a malicious server waited until normal usage crossed a threshold, then changed the instructions presented to the agent, which is a direct challenge to the trust model behind agentic AI.

The practical issue is not only malicious code in a repository or package, but malicious behaviour that appears only after approval and use. That makes this a tool integrity problem, an identity and privilege problem for AI agents, and a monitoring problem for teams that assumed initial review was enough.

Key questions

Q: How should security teams handle MCP tools that change behaviour after approval?

A: Treat the tool definition as an enforceable security object, not a comment. Fingerprint schemas and descriptions at approval time, revalidate them at runtime, and block sensitive actions if metadata changes unexpectedly. This is especially important when agents can reach secrets, cloud credentials, or internal configuration through remote tools.

Q: Why do MCP servers create new identity risk for AI-native development?

A: MCP servers create risk because they extend delegated access from the model into repositories, data, and workflow tools. If the trust path is too broad, the agent can act with capabilities that were never intended for that task. Teams should review those connections as access paths, not just as integration plumbing.

Q: How do teams reduce supply-chain risk in agentic AI deployments?

A: Teams should verify every artefact that can influence runtime behaviour, including tokenizer files, prompt templates, and packaging metadata. They also need a revocation path for mirrored or derived models so tampering does not persist across environments. The goal is to govern the full model package, not just the weights.

Q: Which controls matter most when AI agents can access secrets through tools?

A: Use least privilege, client-side policy enforcement, and monitoring for tool metadata changes. The control objective is to prevent an agent from crossing from ordinary task execution into credential access, data collection, or concealed exfiltration, even when the remote server appears trusted.

Technical breakdown

How runtime-gated MCP metadata poisoning works

MCP clients pass tool definitions to the model as context, which means the description, schema, and metadata help shape tool selection and execution. In this campaign, the server returned benign tool descriptions at first, then altered those instructions after three calls. That design exploits a review gap: static inspection sees a harmless tool, while normal use crosses into a different instruction set. The server can therefore influence agent behaviour without changing the visible tool name or initial interface. Because the client may refresh tool metadata, the poisoned instructions can be reintroduced after approval.

Practical implication: treat tool-definition refreshes as security events and require renewed approval when metadata changes.

Why GitHub pull-request supply chains are an identity problem

The delivery route matters because pull requests are often treated as collaboration events, not as identity-bearing trust decisions. Here, the campaign used public GitHub PRs to place remote MCP endpoints and local delivery artefacts into configuration paths that looked routine. That means the real security boundary is not only the repository, but who is allowed to introduce connected services into an AI workflow. In agentic systems, a changed integration can become a new identity and authorization path for the model, especially when the tool can reach sensitive files or cloud credentials.

Practical implication: review configuration changes that add MCP endpoints with the same scrutiny you would apply to a new privileged integration.

Why tool descriptions become a control plane for AI agents

AI agents rely on tool schemas and descriptions to decide whether an action is available, safe, or relevant. If a malicious server can rewrite those descriptions after trust is established, it can steer the agent toward SSH keys, AWS credentials, shell history, and Kubernetes configuration while concealing the activity from the user. That is not ordinary prompt injection alone. It is a control-plane manipulation of agent behaviour through trusted metadata, which means the security boundary has moved into runtime context management and policy enforcement around sensitive actions.

Practical implication: enforce policy on credential access and outbound actions at the client or gateway, not only in the remote tool source.

Threat narrative

Attacker objective: The attacker wants to hijack AI agent trust so the agent exposes credentials and configuration data through a malicious MCP tool.

1. Entry occurs through public GitHub pull requests that introduce or modify MCP configuration to point at a malicious server or local delivery artifact.
2. Credential access is attempted after a three-call runtime trigger changes the tool metadata and directs the agent to seek SSH keys, AWS credentials, shell history, and Kubernetes configuration.
3. Impact is achieved by covertly steering AI agents to reveal sensitive information and conceal the activity from the human operator.

NHI Mgmt Group analysis

Metadata trust is now an attack surface for AI agents. The central lesson is that MCP tool definitions are not passive labels. They influence model decisions, so a server that can alter metadata after approval can redirect behaviour without changing the visible tool inventory. That makes runtime metadata integrity part of agent governance, not just a protocol detail. Practitioners should treat tool-description drift as a control failure, not an anomaly to ignore.

Tool approval without runtime revalidation creates a false sense of control. This campaign exploits the assumption that once a tool is approved, its behaviour remains stable. The three-call threshold shows how easily a benign inspection can miss a malicious state change. For agentic AI programmes, that means security review has to cover post-approval behaviour, metadata refreshes, and stateful tool responses, not only package provenance.

AI agent identity needs privilege boundaries, not just access to tools. When an agent can read credentials, shell history, or cloud configuration through trusted tool calls, the agent is effectively operating as a non-human identity with delegated scope. That intersection is where NHI governance becomes relevant: the identity of the agent, the permissions of the tool, and the trust placed in the metadata must all be governed together. The practical conclusion is that tool access and data access cannot be separated in policy.

Supply-chain delivery is evolving from malicious code to malicious orchestration. The public GitHub PR route shows that compromise can begin with configuration, not exploitation. The campaign then uses runtime gating to evade shallow inspection and testing. That shifts the market problem from code scanning alone to orchestration trust, which aligns with OWASP Agentic AI Top 10 and agent-focused threat modelling. Teams should assume the next abuse path may be a trusted integration that changes behaviour after deployment.

We are entering a phase where detection must be state-aware. A static allowlist or package review will not catch an integration that behaves benignly for the first few calls and maliciously afterward. The named failure mode here is runtime-gated metadata poisoning, and it should be treated as a class of control failure across agent platforms. The field now needs state-aware monitoring for tool schema changes, not just binary malware detection.

What this signals

Runtime-gated metadata poisoning is a useful name for this failure mode because it captures the real problem: the integration looks trustworthy during review, then changes behaviour after normal use begins. For agent programmes, that means the governance conversation has to move from approval lists to ongoing state verification, with special attention to tool-description drift and hidden triggers.

The practical programme signal is that AI agents should be monitored as identity-bearing systems, not just as application features. When a tool can surface secrets or configuration, the boundary between agent governance and NHI governance disappears, which is why Top 10 NHI Issues and the OWASP Agentic AI Top 10 are both relevant reference points.

Teams that rely on static review will miss stateful abuse patterns. The next step is to align runtime monitoring, tool policy enforcement, and credential protection so that a malicious metadata change cannot turn a benign integration into a credential-harvesting path.

For practitioners

• Monitor tool-definition drift Fingerprint approved MCP tool schemas and descriptions, then alert when a server changes metadata after approval or after a fixed number of calls.
• Gate sensitive actions by policy Require client-side policy enforcement before any tool can read SSH keys, AWS credentials, shell history, or Kubernetes configuration.
• Review repository-to-runtime trust paths Treat pull requests that add MCP endpoints or connected services as high-risk changes and require security review before merge.
• Segment agent privileges from tool availability Separate the ability to list a tool from the ability to execute sensitive actions through it, especially in environments using remote MCP servers.
• Hunt for delayed-behaviour indicators Search logs for repeated benign tool calls followed by sudden changes in metadata, destination hosts, or credential-seeking prompts.

Key takeaways

• MCP tool metadata has become a security boundary because it can redirect AI agent behaviour after approval.
• Runtime-gated instruction changes expose a governance gap that static review and package scanning will not close.
• AI agent programmes need policy enforcement for tool use, credential access, and metadata drift, not just trusted source code.

Key terms

• Runtime-gated metadata poisoning: A malicious technique where a tool or service behaves benignly at first, then changes its metadata or instructions after a trigger condition is met. In agentic systems, this can steer an AI model toward unsafe actions while evading shallow review and approval workflows.
• MCP tool metadata: The descriptive information an MCP server sends to a client about available tools, including names, schemas, and instructions. AI agents use this context to decide what to call and how to act, which makes metadata a security-relevant input rather than a harmless label.
• Control-plane manipulation: An attack pattern where the mechanism that governs behaviour is altered instead of the underlying workload being broken directly. For AI agents, that means changing the instructions, policies, or metadata that shape decisions, which can be more dangerous than a single compromised endpoint.
• Stateful trust boundary: A security boundary that depends on what has happened before, not just on whether a source is initially trusted. In MCP and agentic AI, the trust decision must account for prior tool calls, metadata refreshes, and behaviour changes over time.

What's in the full report

Pillar Security's full research covers the operational detail this post intentionally leaves for the source:

• The public indicators of compromise and the exact endpoint, local-file, and campaign-marker artefacts used in the activity
• The public-source behaviour of the malicious MCP server, including the threshold trigger and metadata changes after three tool calls
• The account-level evidence that ties the pull-request activity, repository pattern, and delivery window together
• The referenced historical MCP incidents and how they compare with this campaign's runtime-gated design

👉 The full Pillar Security post covers the pull-request indicators, runtime trigger, and compromise markers in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps security and identity teams apply consistent controls to delegated access, including AI agents and other non-human identities.