Notifications
Clear all
Topic starter
11/08/2026 3:19 pm
TL;DR: MCP-based AI assistants can be pushed into privilege escalation, data exfiltration, and code execution when tools, local resources, and inherited access are treated as trustworthy by default, according to Bishop Fox’s otto-support CTF. The core failure is not model capability but weak isolation around the assistant’s operating context.
NHIMG editorial — based on content published by Bishop Fox: LLMjacking and MCP attack-surface analysis through the otto-support CTF
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern MCP servers used by AI coding assistants?
A: Treat MCP servers as privileged trust boundaries, not simple data sources.
Q: Why do MCP-based assistants increase the risk of privilege escalation?
A: Because they can combine prompt-driven behaviour with real tool execution and inherited access.
Q: What do teams get wrong about prompt injection in AI assistants?
A: They treat it as a content safety issue instead of an access issue.
Practitioner guidance
- Isolate MCP-enabled assistants from ambient host privilege Run AI assistants and MCP servers in minimal containers or dedicated environments with only the credentials, mounts, and network paths required for the task.
- Inventory every tool and privilege tier exposed to the assistant Map each MCP tool to the data it can touch, the services it can reach, and the identity context it uses.
- Review source code before trusting runtime behaviour Inspect how tool calls are assembled, how prompts are handled, and where local resources are inherited.
What's in the full article
Bishop Fox's full article covers the operational detail this post intentionally leaves for the source:
- Hands-on CTF setup steps for running the vulnerable MCP server in a container or on a host
- The full privilege-tier progression across 19 tools and four access levels
- Source repository guidance for combining runtime testing with code review
- Case-study commentary on local MCP exposure, prompt injection, and unsafe tool execution
👉 Read Bishop Fox’s otto-support CTF analysis of MCP attack surfaces →
MCP attack surfaces and AI assistants: are your controls enough?
Explore further
11/08/2026 3:31 pm
MCP creates an identity boundary problem, not just an integration problem. Once an assistant can call tools and inherit host context, the security question changes from authentication to delegated runtime authority. Traditional app controls assume the caller is known and bounded before action begins. With MCP, the assistant can become the action path itself, which means governance must follow the runtime, not just the login event.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- The same research found that DeepSeek accidentally embedded over 11,000 secrets in training data and exposed more than one million sensitive records, showing how quickly secret hygiene failures scale.
A question worth separating out:
Q: How can organisations tell whether an AI assistant has too much authority?
A: Look for signs that a single assistant session can access secrets, internal services, and code execution paths without a separate approval step. If tool inventory, environment inheritance, and privilege changes are not individually reviewable, the assistant’s authority is already beyond what most governance models can safely justify.
👉 Read our full editorial: MCP attack surfaces expose why AI assistants need isolation
