Topic starter
14/08/2026 6:33 pm
TL;DR: An active MCP supply-chain campaign used public GitHub pull requests, a benign-looking server, and a three-call runtime gate to switch tool metadata into credential-seeking instructions after approval, according to Pillar Security. The pattern matters because AI agents can be steered through trusted tool definitions, so access control has to extend beyond installation and into runtime metadata integrity.
Editorial analysis by NHI Mgmt Group, based on content published by Pillar Security: “Deadbugz: Currently Active MCP Supply-Chain Campaign”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Deadbugz shows that MCP trust can be undermined after approval, when tool metadata changes at runtime rather than at installation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/08/2026 6:41 pm
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.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Deadbugz shows how MCP metadata poisoning evades AI agent trust