Topic starter
19/08/2026 3:45 pm
TL;DR: MCP expands AI agent access from isolated prompts to dynamic tool orchestration, and Equixly argues that this shifts security from syntax validation to intent validation because broad permissions, tool metadata exposure, and weak API boundaries make exploitation easier than most teams assume. The practical question is no longer whether agents can use tools, but whether their discovery, authorization, and runtime behaviour are continuously tested under adversarial conditions.
Editorial analysis by NHI Mgmt Group, based on content published by Equixly: “Offensive security for MCP servers, or how to prevent AI agent exploits in the wild”.
Key questions
Q: What breaks when AI tools are exposed through loosely governed MCP servers?
A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight.
Q: Why do MCP deployments increase the need for continuous adversarial testing?
A: Because the attack surface changes whenever a tool, schema, or model changes.
Q: How should teams handle authorisation beneath an MCP layer?
A: They should treat the MCP server as a translation layer, not a trust boundary.
Practitioner guidance
- Govern tool discovery as an access decision Restrict which tools an MCP client can enumerate, and validate that exposed tool metadata does not reveal privileged operations that exceed the user’s intended scope.
- Separate instruction input from trusted data Apply strong context boundaries so retrieved content, external documents, and user prompts cannot directly influence tool selection or privileged execution.
- Test the APIs beneath MCP for broken authorisation Review the wrapped APIs for object-level authorisation failures, confused deputy conditions, and overbroad service permissions that an agent can chain through.
Bottom line: MCP turns agentic AI into a live control plane where discovery, delegation, and execution can be abused if permissions exceed intent.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:22 pm
MCP security is now an identity and authorisation problem, not just an application-security problem. The article shows that the real control issue is delegated runtime authority: the agent can discover tools, infer paths, and act inside permissions that were never designed for autonomous use. That makes intent validation and privilege scoping the governing question, not just input sanitisation. Practitioners should treat MCP as a delegated-access boundary that needs continuous assurance.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between prompt injection and MCP tool injection?
A: Prompt injection targets the model conversation, while MCP tool injection targets the metadata and instructions tied to external tools. The second is often harder to spot because the user may never see the malicious text. Both can steer behavior, but tool injection can directly influence privileged actions.
👉 Read our full editorial: Offensive MCP security is becoming the baseline for agentic AI