MCP-based GenAI apps expand risk because the system decides which tools to invoke at runtime, so the actual execution path is not fully known in advance. That creates hidden API calls, variable permission use, and a larger set of trusted dependencies. Traditional controls struggle when the boundary moves from code paths to orchestration paths.
Why MCP changes the security model
MCP-based GenAI apps are riskier than static flows because the application no longer has a fixed, auditable execution path. The model can choose tools at runtime, which means the security boundary shifts from a known code path to an orchestration path that may invoke different services, with different scopes, at different times. That makes trust decisions harder to predict, inspect, and constrain.
The practical difference is not just “more integration.” It is that the app now behaves like a broker of delegated actions. Each tool call can introduce a new API surface, a new permission boundary, and a new dependency chain. In that sense, the app inherits control challenges that are closer to agentic orchestration than to a static UI workflow.
Static application flows are usually easier to reason about because the permitted sequence of actions is encoded in software logic. With MCP, the sequence can vary based on prompt, context, retrieved data, or model choice. That flexibility is useful, but it also reduces determinism, which weakens traditional review methods that assume you can enumerate expected requests ahead of time.
What changes about trust, permissions, and dependencies
The main security change is that the system may call tools or APIs that were not obvious at design time, or may call them with broader authority than a static flow would normally need. That creates hidden API calls, variable permission usage, and a larger trusted dependency set. The result is a wider blast radius when a tool, credential, or policy decision is wrong.
This is why MCP security guidance focuses on authorization boundaries, token handling, and delegation semantics. MCP authorization specification matters here because it treats the MCP server as an OAuth resource server and avoids token passthrough assumptions that can quietly expand access beyond the intended scope.
When an MCP app is designed well, each tool should have a narrow, explicit purpose. When it is designed poorly, the model becomes an overpowered decision layer that can trigger actions across systems that were never meant to share the same trust boundary. That is why runtime orchestration needs stronger guardrails than a static application flow, even when the user experience looks similar.
The broader agentic risk pattern is also relevant. OWASP Agentic AI Top 10 captures the same structural issue, tool misuse and identity or privilege abuse become materially more likely when the system can choose and chain actions dynamically.
Why traditional controls struggle, and what to do instead
Traditional application controls are strongest when they can inspect a known request, a known endpoint, and a known permission model. MCP reduces that certainty. A policy written for a single static transaction may miss the real risk if the model can switch tools, alter parameters, or route through a less obvious dependency path.
That makes implementation discipline more important than architecture slogans. MCP Security Guide is useful because it concentrates on the control points practitioners actually need, authorization, gateway design, local server exposure, and tool poisoning resistance, rather than treating MCP as a generic integration pattern.
The same logic applies when credentials or on-behalf-of actions are involved. If the app can act through delegated credentials, then the real control question is not “can the model call a tool?” but “what exactly can this tool do, for whom, and under which trust conditions?” A strong MCP design should answer that with narrow scopes, explicit audience binding, and clear separation between the model’s suggestion and the system’s permission to execute.
For readers who want the broader design lens, the agentic AI applications guide is helpful because it frames orchestration risk as a structural property of runtime decision-making, not just a tooling issue.
Risk and Threat Considerations
MCP expands exposure because a prompt, context injection, or misplaced tool selection can trigger actions with real system consequences. The threat is not only malicious abuse, but also accidental overreach: a model can call the wrong tool, combine tools in an unsafe order, or surface data into a dependency that was never meant to receive it.
Failure mechanism: The attacker or failure condition exploits runtime delegation, excessive tool scope, or token reuse to turn a flexible orchestration layer into an unintended execution path.
Impact: The result can be unauthorized data access, privilege amplification, secret exposure, lateral movement through trusted integrations, or business action taken on the wrong basis.
For concrete threat modelling, it helps to treat MCP as an exposed trust broker rather than a mere protocol adapter. That perspective is reinforced by Analysis of Claude Code Security, which shows how code-oriented agent workflows can inherit new attack paths once tool use and verification become part of the runtime loop.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Runtime tool selection is the core reason MCP expands attack surface. |
| ASI03 — Identity & Privilege Abuse | MCP changes how identities and privileges are exercised at runtime. | |
| ASI04 — Agentic Supply Chain Vulnerabilities | MCP adds third-party tools and dependencies that broaden trust boundaries. | |
| Recommendation — Restrict tool invocation paths and validate every tool call against explicit policy. Bind each action to least privilege and prevent privilege inheritance across tools. Vet and continuously monitor tool providers before allowing them into orchestration paths. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP tool calls depend on correct auth boundaries and token handling. |
| API5 — Broken Function Level Authorization | MCP can invoke powerful functions dynamically, making function-level checks critical. | |
| Recommendation — Enforce strong authentication and avoid token passthrough between unrelated services. Authorize each function call independently, not just the session or client. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Dynamic orchestration needs explicit trust verification at each access step. |
| Recommendation — Apply continuous verification and least privilege to every tool and dependency. | ||
Practitioner Guidance
What to prioritise: Start with tool inventory, permission boundaries, and the questions “what can this tool do” and “under what identity or token.” If you cannot answer those two questions per tool, you do not yet have a safe MCP rollout.
What to verify: Verify that the model cannot silently inherit broad tokens, that high-impact tools are separately gated, and that each call can be attributed to a specific action path. If the control plane cannot reconstruct why a tool was invoked, the architecture is too permissive for production.
Common mistake: Treating MCP as just another API integration and assuming existing application authorization is enough. The risky part is not the existence of APIs, it is the dynamic choice of which ones to invoke, in which order, and with what delegated authority.
Practitioner takeaway: The security goal is not to eliminate dynamic orchestration, but to make every possible tool action narrow, explicit, and observable enough that runtime flexibility does not become runtime ambiguity.
Related resources from NHI Mgmt Group
- Why do MCP deployments create NHI risk beyond normal application security?
- Why do browser-based verification flows create security risk for identity teams?
- Why do AI-generated MCP tools and agent workflows create a different security risk than ordinary application code?
- Why do password-based authentication flows create more risk and maintenance burden in React Native apps?