AI agents create risk because they initiate actions autonomously, often with standing access and without a human approving each call. MCP connections can link those agents to external tools and data sources, so a malicious or compromised endpoint may exploit the trusted connection path. Traditional perimeter controls assume network trust after connection, which is too broad for machine identities that act independently.
Why AI Agents and MCP Are Different From Ordinary Traffic
AI agents are not just clients sending requests. They can choose actions, chain tools, and keep operating after the first decision, which changes the trust model from passive traffic to delegated execution. MCP adds a standard way to connect those agents to tools and data, so the security question becomes who is allowed to act, on what basis, and with what bounds.
That difference matters because the risk is not only transport exposure. Once a connection is treated as trusted, the endpoint behind it can become a launcher for actions, data access, or downstream requests that were never meant to be automatic. A simple network policy is often too coarse for that kind of authority.
For a useful baseline on agent behaviour and autonomy, see AI Agents vs Agentic AI.
How MCP Changes the Attack Surface
MCP is valuable because it standardises how an agent discovers and uses tools, but that same consistency also concentrates trust. If the agent can reach a tool through a valid MCP connection, then the security boundary moves from the network path alone to the combination of agent identity, tool authorization, and endpoint behaviour. A malicious tool server, poisoned response, or over-broad connector can turn a legitimate integration into an abuse path.
Traditional application traffic usually assumes a request is bounded by the application session and the immediate operation. MCP workflows are more dynamic: the agent may select a tool, pass context, and follow a sequence of actions across systems. That makes request origin, delegation, and per-action authorization more important than a simple allowlist of destinations.
The authorization model for those connections is described in the Model Context Protocol: Authorization specification, which is the right reference point when you need to understand token scope and resource-server boundaries.
For operational detail on the protocol risk surface, MCP Security Guide covers token passthrough, gateways, and the practical controls that reduce over-trust in connectors.
Why Standing Access and Human-Free Execution Increase Risk
The security gap widens when agents inherit standing access or reuse a user context without a fresh approval step for each meaningful action. A human can usually notice a strange page load or unusual form submit; an agent can silently continue if its credentials, session, or delegated authority still work. That means compromise may look like normal automation until the blast radius is already large.
This is especially true when the agent is allowed to reach multiple tools under one umbrella permission. If one connected endpoint is compromised, the trust path can be abused to pivot into other actions or data sources, even though no single request looked malicious on its own. The more the agent can do without re-authorization, the harder it is to distinguish intended automation from abuse.
For a control-oriented view of reducing standing privilege, AI Agent Authorisation Guide explains task-scoped access, per-action decisions, and human approval gates.
For the broader identity model behind these systems, Agentic AI Identity Guide shows how delegation, registration, authentication, and retirement change the control model for autonomous software.
Risk and Threat Considerations
The main risk is trust collapse: once an agent or MCP connection is treated as an approved path, the environment may grant it far more reach than the original request justified. That creates exposure to tool misuse, unauthorized data access, and unintended cross-system actions when the endpoint, connector, or delegated context is compromised.
Failure mechanism: An attacker abuses a trusted agent context, poisoned tool response, or over-scoped MCP integration to turn legitimate delegation into unauthorized execution, often without needing to break the perimeter first.
Impact: The result can be data exfiltration, destructive actions, lateral movement through trusted integrations, or a hidden compromise that looks like normal automation until recovery starts.
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 Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents and MCP links create abuse risk when delegated authority is too broad. |
| ASI02 — Tool Misuse | MCP expands tool access, making misuse a core agentic security risk. | |
| ASI10 — Rogue Agents | Unauthorized autonomous actions become a distinct threat when agents act without human review. | |
| Recommendation — Enforce per-action authorization and remove standing agent privilege. Constrain tool access to approved actions, scopes, and contexts. Detect and disable agents that execute outside approved authority. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Standing access and broad delegated permissions are the central exposure. |
| IA-9 — Identification and Authentication (Service and Other Non-Organizational Users) | MCP endpoints and agent-to-tool trust depend on authenticating non-human actors. | |
| AC-3 — Access Enforcement | Per-request authorization is needed when actions are executed by autonomous agents. | |
| Recommendation — Limit agent permissions to the minimum needed for each task. Authenticate each service or agent endpoint before granting tool access. Enforce access decisions at the point of each agent action. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question contrasts broad perimeter trust with continuous verification for agents. |
| Recommendation — Apply continuous verification and assume breach for agent connections. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agent and MCP access becomes riskier when non-human identities have excess privilege. |
| NHI-10 — Human Use of NHI | Human credentials or human-approved access reused by agents widens the trust boundary. | |
| NHI-04 — Insecure Authentication | Agent-to-tool trust depends on strong authentication and token handling. | |
| Recommendation — Reduce non-human identity privilege to task-specific scope. Separate human and agent use of credentials and approvals. Use strong authentication and bound tokens for agent connections. | ||
Practitioner Guidance
What to prioritise: Treat agent access as an authorization problem before you treat it as a network problem. The first question is not whether the connection is allowed, but whether each action should be allowed with the current principal, tool, and context.
What to verify: Confirm that the agent has task-scoped permissions, that MCP tokens are audience-bound, and that any high-impact action still requires an explicit decision point or approval path. If a tool can act broadly on the agent’s behalf, assume the blast radius is too large until proven otherwise.
Practitioner takeaway: The key control shift is from “can this client connect?” to “should this delegated identity be allowed to do this exact action right now?”
