Because the risk comes from what connected agents can do once authorised. If an agent can read tickets, query databases, open pull requests, or update records, the organisation must control delegated rights, not just transport security. The protocol can be sound while the governance model remains too weak to contain misuse.
Why MCP can be risky even when the protocol itself is sound
MCP reduces integration friction, but it does not eliminate the security consequences of delegated action. Once an agent is allowed to act on a user or system’s behalf, the real question becomes which data, systems, and actions it can reach. A clean transport and well-formed protocol cannot compensate for broad authority, weak approval boundaries, or poorly bounded tool access.
The security problem is therefore often governance, not wire format. If the same agent can read tickets, query databases, create pull requests, and update records, then compromise or misuse of that agent becomes a business-impacting access issue. The protocol can be well designed while the authorisation model remains too permissive to contain error, abuse, or downstream blast radius.
That is why MCP should be assessed as an access path, not just a messaging layer. The highest-value review is to trace what every tool call can do, what data it can touch, and whether the delegated rights match the task, the user context, and the environment in which the agent operates.
Where the real exposure appears in an MCP deployment
The exposure usually starts at the tool boundary. If an MCP-connected agent can invoke actions that a human would normally perform manually, the organisation inherits the same risks it would face from any privileged automation: overbroad scopes, weak segregation of duties, and the possibility that a single successful prompt, plugin, or session compromise can trigger multiple actions in sequence.
Another common weakness is treating authentication as sufficient. An authenticated agent or client can still be dangerous if the granted token, delegated session, or service identity can act beyond the intended workflow. Model Context Protocol: Authorization specification is useful here because it frames MCP servers as OAuth 2.1 resource servers and avoids token passthrough, which narrows one class of abuse but does not by itself solve privilege design.
MCP also inherits the familiar risk that convenience collapses boundaries. A single agent may bridge development, support, and operational systems, which makes misuse harder to detect and harder to contain. For that reason, secure MCP design has to include explicit scoping, environment separation, and a clear rule for which actions require fresh human confirmation.
How to reduce risk without treating MCP as broken
Good practice is to start with delegated authority, not protocol mechanics. MCP Security Guide is directly relevant because it focuses on the authorisation model, token handling, gateways, and the confused deputy problem that commonly appears when agents mediate access on behalf of users.
From there, the practical control is least privilege at the task level. Give the agent the smallest set of actions needed for the use case, keep write actions separate from read-only actions, and avoid reusing the same credential across unrelated tools or environments. If a task only needs retrieval, it should not also be able to mutate records or trigger workflows.
It also helps to design for revocation and review. Short-lived credentials, explicit approval gates for sensitive actions, and logging that records who authorised the action and which tool executed it make it far easier to limit damage when a workflow is abused or misconfigured. When those signals are missing, the organisation may not be able to distinguish legitimate automation from unauthorised delegation.
Risk and Threat Considerations
MCP risk increases when a capable agent can combine trusted access with broad tool permissions. The danger is not that the protocol fails in transit, but that a valid session can be used to reach valuable systems, move laterally across workflows, or carry out actions the operator did not intend.
Failure mechanism: An attacker, or even a poorly constrained agent, uses legitimate delegated access to read sensitive data, alter records, or chain multiple tool actions faster than a human reviewer can detect.
Impact: The result can be data exposure, unauthorised changes, supply of misleading outputs, or operational disruption, especially when one agent credential spans several systems or environments.
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) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP risk here centers on delegated agent authority and misuse of granted rights. |
| Recommendation — Limit agent scopes and require explicit approval for privileged tool actions. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP tools expose action-level authorization decisions that can be over-broad. |
| Recommendation — Enforce function-level authorization on every MCP tool action. | ||
| NIST Zero Trust (SP 800-207) | AC-6 — Least Privilege | MCP deployments need least-privilege delegation across connected systems and tools. |
| Recommendation — Apply least privilege to each delegated agent capability and session. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Delegated agent access depends on controlling issued credentials and their lifecycle. |
| AU-2 — Event Logging | MCP misuse is harder to detect without detailed action and delegation logs. | |
| Recommendation — Manage short-lived credentials and revoke them quickly when delegation changes. Log delegated actions, approvals, and target systems for audit and review. | ||
Practitioner Guidance
What to prioritise: Review the action surface before you review transport controls. The most important question is not whether the MCP channel is secure, but whether each connected tool is narrowly scoped to the minimum task set and isolated from higher-risk operations.
What to verify: Confirm that every sensitive tool call has a clear authorisation decision, a revocation path, and audit evidence that identifies the delegated actor, the target system, and the specific action taken. If you cannot reconstruct that chain, the deployment is too permissive for production use.
Decision rule: If the agent can change state in a system of record, require stronger approval, tighter scope, and shorter-lived delegation than you would for read-only access. If it can only retrieve data, focus on data classification and query limits first.
Practitioner takeaway: MCP is safest when it is treated as a bounded delegation layer, not a blanket permission to automate everything the user could do.
Related resources from NHI Mgmt Group
- Why do MCP directories create governance risk even when they look well curated?
- Why do MCP deployments create security risk even when the agent model itself is not compromised?
- Why do oracle manipulation attacks create legal and operational risk even when protocol code runs as designed?
- Why do connected devices create ongoing security risk even when organisations believe they are well protected?