Notifications
Clear all
Topic starter
18/08/2026 2:54 pm
TL;DR: A crafted Gmail message, Claude Desktop, and permissive MCP plugins were enough to produce code execution in Pynt’s test, showing that the danger lies in how trusted components compose rather than in any single vulnerable server. Context resets, untrusted input, and cross-tool invocation together create a governance gap that existing IAM and application controls do not fully address.
NHIMG editorial — based on content published by Pynt: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
Questions worth separating out
Q: How should security teams govern MCP tool access in enterprise environments?
A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools.
Q: Why do MCP-based AI workflows create more risk than isolated integrations?
A: Because risk emerges from composition.
Q: What breaks when untrusted content can influence privileged tool use?
A: The control boundary breaks between interpretation and execution.
Practitioner guidance
- Map tool-to-tool authority chains Inventory which inputs can influence which tools, then classify every cross-tool path by trust level and execution impact.
- Separate content ingestion from privileged execution Require a policy decision between reading untrusted content and invoking any action-capable tool.
- Constrain cross-tool delegation by default Limit the set of tools a model can invoke in a session and require explicit approval for any transition from interpretation to execution.
What's in the full article
Pynt's full article covers the operational detail this post intentionally leaves for the source:
- The exact Claude Desktop attack sequence and how each prompt iteration changed the model's response.
- The Gmail MCP, Shell MCP, and Claude Desktop composition that created the exploit path.
- Screenshots and figures showing the model's own reasoning while the attack was refined.
- The disclosure steps the author described after successful code execution.
👉 Read Pynt's analysis of MCP composition risk and Claude Desktop code execution →
MCP composition risk: what it means for AI agent governance?
Explore further
18/08/2026 3:37 pm
Compositional trust, not isolated vulnerability, is now the identity problem in MCP environments. The article shows that each component can look secure on its own while the interaction between them creates the exploit path. That breaks a core governance assumption in both NHI and AI-enabled workflows: access decisions are often made per system, but abuse emerges across systems. Practitioners need to evaluate the trust chain, not the component checklist.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: What should teams do when an AI session can be refined across resets?
A: Assume the session can be reconstituted into a new attack path and remove any reliance on a one-time refusal. Review whether the model can be coached into alternative strategies, then require separate approvals for each privileged action so a refreshed context cannot reopen the same abuse path.
👉 Read our full editorial: Compositional risk in MCP systems can trigger code execution
