They fail when the agent inherits access from a tool or server that was trusted by default rather than explicitly approved. That lets a rogue connector act with the agent’s authority, so the weak point is the trust boundary around tool issuance, not only the model itself.
Why broad MCP trust breaks the agent’s security model
AI agents fail when trust is granted to an MCP tool or server as a default property instead of being earned per request, per action, and per principal. The problem is not only the model’s reasoning quality, it is the trust boundary: once a connector is treated as implicitly safe, the agent can inherit authority the connector should never have had.
That creates a classic confused-deputy pattern. A hostile or compromised tool can present work to the agent that looks legitimate, then use the agent’s standing authority to reach data, invoke functions, or forward tokens beyond the original intent.
In practice, the question is whether the agent is making an explicit authorization decision or simply relaying trust from the MCP layer. When the latter happens, the weakest point is often the issuance and acceptance of tool access, not the model output itself.
Where the failure occurs in the trust chain
The failure usually shows up at the boundary between tool discovery, tool registration, and tool execution. If a server is enrolled without strong origin checks, capability limits, or audience restrictions, the agent may treat every exposed tool as equally eligible for use.
That is especially dangerous when the connector can act on the agent’s behalf across multiple resources. An agent that can read a prompt, call a tool, and reuse an attached token can be turned into a relay for actions the user never explicitly approved.
MCP security guidance is strongest when the server is treated as a resource server with narrow, auditable access rather than as a trusted extension of the agent itself. The relevant design question is not only “can the agent call this tool?” but “what exact authority is being delegated, and for how long?”
For a deeper look at how MCP authorization should constrain token use and avoid token passthrough, see Model Context Protocol: Authorization specification. The same trust-boundary issue is also central to MCP Security Guide, which frames the practical failure modes around authorization, token handling, and tool control.
What broad trust enables an attacker or rogue connector to do
Once trust is overly broad, a malicious connector does not need to defeat the model. It only needs to supply a plausible workflow that the agent will carry out with inherited authority. That makes token theft, overbroad scope, and tool injection especially damaging because the abuse path is already inside the agent’s normal operating channel.
This is why “trusted by default” is a high-risk design choice. If a connector can trigger action without explicit approval, it can become a mechanism for data exposure, unauthorized function calls, or lateral movement through linked systems. The resulting compromise often looks like normal automation until the blast radius is examined.
For practitioners, the useful mental model is that the connector is part of the attack surface, not a protective wrapper around it. A rogue server can exploit the agent’s authority only because the trust boundary was placed too far downstream.
That boundary discipline is the same reason AI Agent Authorisation Guide matters here: the decision point must sit on the action, not on the presence of a tool. For attack-path context, OWASP Agentic AI Top 10 captures the broader identity and privilege abuse patterns that broad MCP trust can enable.
Risk and Threat Considerations
Broad MCP trust increases the chance that a connector, server, or tool can act as a deputy with more privilege than it should have. The practical risk is not only accidental misuse, but also deliberate abuse by a compromised or malicious integration that can steer the agent into high-impact actions.
Failure mechanism: The agent accepts tool output, server identity, or delegated credentials as sufficient proof of trust, then executes actions without a fresh authorization decision tied to the specific request and resource.
Impact: A rogue connector can trigger unauthorized reads, writes, or token reuse under the agent’s authority, which can expand blast radius well beyond the original user intent.
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 SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Broad MCP trust can let tools inherit and misuse agent authority. |
| ASI02 — Tool Misuse | MCP connectors can be abused as tools that execute unintended actions. | |
| ASI04 — Agentic Supply Chain Vulnerabilities | Trusted-by-default connectors create supply-chain risk in agent integrations. | |
| Recommendation — Require per-action authorization so tool calls cannot inherit excess agent privilege. Constrain tool invocation paths and validate each tool against approved intent. Vet connector provenance and restrict newly introduced tools before deployment. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP trust failures can let unauthenticated or weakly authenticated actors present as trusted servers. |
| Recommendation — Bind server access to strong authentication and verify token audience before execution. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Agent inheritance of broad tool authority is a least-privilege failure. |
| Recommendation — Limit each tool and connector to the minimum permissions needed for its task. | ||
Practitioner Guidance
What to verify: Confirm that each MCP tool call is checked against explicit policy for the current principal, target, and action. If the tool can reach multiple systems, verify that scope, audience, and lifetime are all constrained separately.
Decision rule: If a connector can act without user-visible approval or without an action-level policy decision, treat it as standing privilege and redesign before production use. If the server can forward tokens or invoke downstream systems, require tighter delegation controls and auditability.
Common mistake: Treating “trusted connector” as a sufficient security control. Trust should be conditional, short-lived, and specific to the action, otherwise the agent becomes a high-authority relay for whatever the connector asks it to do.
Practitioner takeaway: The right control is not simply restricting the model, it is forcing every tool invocation to earn authority at the boundary where the agent crosses into another system.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org