Direct MCP connections can let an agent inherit the human's standing access in the target application, which collapses the separation between interactive use and programmatic use. That turns one user's permissions into an agent's operational blast radius. Brokered mediation matters because it inserts policy, vaulting, and logging between the agent and the tool.
Why direct MCP connections are riskier than brokered access
Direct MCP connections are risky because they often let the agent operate with the same application context as the person who connected it. That makes the integration feel like simple automation, but the security effect is closer to delegated use of an existing account. The result is a weaker boundary between human intent, tool action, and system authority.
With a direct connection, the agent may inherit whatever the user can do in the target tool, including broad read, write, export, or administrative capabilities. If the app does not distinguish clearly between interactive use and programmatic use, one approval can become an always-on access path with a much larger blast radius than the operator expected.
Brokered mediation changes that model. A gateway or broker can interpose policy checks, limit which scopes are exposed, issue shorter-lived access, and preserve logs that show what the agent actually requested and used. That additional layer is often what keeps an integration from becoming an unreviewed extension of the user’s standing access.
Where the identity boundary collapses
The core problem is not MCP itself, but the way direct connections can reuse existing identity relationships without rethinking them for machine execution. If a user authorizes an agent once and the target tool treats the resulting session as equivalent to the human's session, the agent can act under human-level trust even when the task is fully automated.
This is especially important for enterprise tools that were built around person-centric workflows. Those systems may assume a named user, a browser session, and manual review, yet a direct MCP path can turn that into a background channel for repeated actions, bulk retrieval, or chained operations that the user would never perform interactively at the same pace.
Brokered architectures help because they can create a distinct control point for the machine path, even when the underlying application still uses the same enterprise account model. In practice, that means separating authorization for the tool from authorization for the person, instead of letting the agent borrow the person's access unchanged.
Why this matters for enterprise tools and operations
Enterprise applications usually contain concentrated data, privileged workflows, or business actions that matter far beyond the local task. If a direct MCP integration reaches email, ticketing, code repositories, document stores, finance systems, or admin consoles, the identity risk is not just account misuse, it is unintended expansion of authority across multiple systems.
That risk grows when teams connect many tools to the same agent pattern. Reused credentials, shared tokens, and broad OAuth grants can make every new connector another path into the same trust domain. The more the enterprise relies on direct connections, the easier it becomes for one compromised agent, prompt, or integration mistake to affect many downstream systems at once.
A brokered design can reduce that concentration by forcing per-tool policy, per-action logging, and tighter scope management. For that reason, practitioners evaluating the MCP Security Guide should treat “can the agent reach the tool” as a separate question from “should this action run under the user's full authority.”
Brokered access, least privilege, and trust checks
Direct connections are most dangerous when teams assume the approval screen is the control. In reality, consent to connect is not the same as consent for every future action. Brokered mediation gives security teams a place to enforce least privilege, verify intent, and apply different rules for read-only, write, and high-impact operations.
That distinction is why identity design matters so much in agentic integrations. If the agent needs to act repeatedly, the safer pattern is usually task-scoped or short-lived access rather than a long-lived session that mirrors the human account. For a broader view of that design choice, the AI Agent Identity Security deployment guide is useful for understanding how access boundaries should be shaped around agent authority.
For teams building or reviewing these integrations, the practical question is whether the connector can prove which identity performed which action, under what scope, and for how long. If the answer is no, the integration is too close to standing access and should be treated as a governance problem, not just an automation feature.
Risk and Threat Considerations
Direct MCP connections can create a confused-deputy problem where the agent is trusted to act, but the tool cannot distinguish between a deliberate human action and an automated one. That makes privilege misuse, unintended data access, and credential reuse easier to trigger and harder to contain.
Failure mechanism: The connection inherits human access, then reuses that authority for automated actions without a separate policy, vault, or audit boundary, so any mistake, prompt abuse, or connector misuse can execute at the user's effective privilege level.
Impact: A single compromised or overbroad connection can expose sensitive records, trigger unauthorized changes, or expand lateral movement across enterprise systems, especially when the same identity is reused across multiple tools.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Direct MCP paths can let agents reuse human authority in tool access. |
| Recommendation — Separate agent authority from user authority and restrict inherited privileges. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Direct connections often rely on reused sessions or weak machine authentication boundaries. |
| NHI-05 — Overprivileged NHI | Inherited user access can give the agent more privilege than its task needs. | |
| NHI-07 — Long-Lived Secrets | Direct integrations often depend on durable tokens or credentials that expand exposure. | |
| Recommendation — Use distinct machine authentication and avoid sharing human sessions with agents. Minimise scopes and issue only task-appropriate privileges for each connector. Replace durable secrets with short-lived, scoped credentials where possible. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question is fundamentally about preventing inherited access from exceeding need. |
| Recommendation — Restrict each connector and action to the minimum privilege required. | ||
Practitioner Guidance
What to prioritise: Treat every direct MCP integration as an access-design review, not a plumbing exercise. The first decision is whether the agent should inherit user permissions at all, or whether the task needs a brokered path with separate scopes and logs.
What to verify: Confirm that the connector can show identity separation, scope limitation, and durable audit evidence for each high-risk action. If the tool cannot distinguish interactive use from agentic use, assume the blast radius is larger than the integration owner believes.
Common mistake: Teams often secure the MCP server but leave the target application untouched. That leaves the agent riding on the same broad entitlement set the human already has, which is exactly how direct connections turn convenience into identity risk.
Practitioner takeaway: The safer design is not “connect everything directly,” but “make every automated action prove its own authority, scope, and traceability before it inherits any human access.”
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 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org