Notifications
Clear all
Topic starter
11/08/2026 3:11 pm
TL;DR: Prompt injection in MCP becomes materially more dangerous when an AI agent can use tools, because malicious instructions can drive real actions such as data retrieval, messaging, code execution, or API calls, according to Unosecur. The security issue is no longer just bad output; it is unauthorized execution through trusted interfaces.
NHIMG editorial — based on content published by Unosecur: Prompt Injection Is Worse When Agents Can Use Tools: The MCP Execution Crisis
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams implement least privilege for AI agents and NHIs?
A: Start by treating AI agents as a separate identity class with explicit ownership, purpose, and lifecycle records.
Q: Why do AI agents make prompt injection more dangerous than chat-only tools?
A: AI agents are more dangerous because they can act, not just generate text.
Q: What breaks when MCP tool permissions are scoped too broadly?
A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role.
Practitioner guidance
- Constrain tool permissions by function Give each agent only the files, APIs, commands, and destinations required for its specific task.
- Move approval to the execution path Require action-level authorization before a tool call is executed, not after the model has already chosen it.
- Monitor tool drift and post-approval changes Track tool descriptions, schemas, server identity, and returned content for changes after trust is established.
What's in the full article
Unosecur's full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step explanation of how MCP tool poisoning moves from untrusted content to privileged execution.
- Specific examples of tool shadowing, rug pulls, and cross-tool escalation in agent workflows.
- A practical control set for least privilege, sandboxing, and execution-layer authorization in MCP environments.
- The vendor's logging and inspection flow for tracing model decisions, arguments, and downstream actions.
👉 Read Unosecur's analysis of MCP prompt injection and tool-enabled execution risk →
MCP prompt injection: are your tool controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
11/08/2026 3:26 pm
MCP prompt injection is an identity and execution problem, not a content-safety problem. Once a model can invoke tools, the security question becomes who or what is authorized to make a state-changing request. That is a familiar IAM problem, but the attacker is now shaping the request through poisoned context instead of stolen credentials. Practitioners should stop treating this as a chat moderation issue and start treating it as delegated execution with identity consequences.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, leaving most tool estates over-broad by design.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unsafe action?
A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.
👉 Read our full editorial: Prompt injection becomes an execution-control problem in MCP
