They assume one authenticated chokepoint can safely wrap all downstream tools and systems. In practice, that model hides what each agent is doing after login and creates a false sense of trust inside the tunnel. Security teams need per-action authorisation, not just a single credential in front of a broad tool surface.
Why This Matters for Security Teams
Treating an mcp server like a VPN concentrator encourages a dangerous mental model: authenticate once, then trust the tunnel. That works poorly for agentic systems because the risk is not just who connected, but what each agent does after connection. Once an agent can chain tools, pull secrets, or pivot across systems, the authenticated front door becomes a blind spot rather than a control point.
This is why current guidance around OWASP Agentic AI Top 10 and NHIMG research on OWASP Agentic Applications Top 10 keeps returning to runtime authorisation, tool scoping, and identity per workload. The issue is not tunnel encryption or perimeter login. The issue is that MCP tool surfaces can expose far more authority than a single session should ever inherit. In practice, many security teams discover this only after an agent has already overreached, not during the access design phase.
NHIMG research from The State of MCP Server Security 2025 shows how easy it is for MCP deployments to accumulate hidden exposure when access scoping is weak and secrets are embedded in configuration. That pattern is the opposite of what security teams want from a control plane.
How It Works in Practice
An MCP server should be treated as a policy-enforced tool broker, not a tunnel endpoint. The useful security question is not “did the agent authenticate?” but “was this specific action allowed, for this identity, in this context, at this moment?” That usually means combining workload identity, short-lived credentials, and request-time policy evaluation. For agents, static RBAC is often too blunt because behavior is dynamic and goal-driven, which is why current guidance suggests intent-based or context-aware authorisation for high-risk tool use.
Operationally, that means the agent proves its workload identity, then receives only the minimum credential or token needed for the specific action. Policies should evaluate the requested tool, target data, time window, sensitivity level, and any step-up requirements before approval. This is consistent with the direction of OWASP Top 10 for Agentic Applications 2026 and the control logic described in Analysis of Claude Code Security. The practical aim is to keep the agent’s privileges ephemeral, narrowly scoped, and revocable per task.
- Use workload identity as the primary trust anchor, not a shared server login.
- Issue JIT credentials with short TTLs and automatic revocation after the action completes.
- Evaluate each tool call through policy-as-code rather than a one-time session grant.
- Log the action, target, and policy decision so investigations can reconstruct agent behavior.
This model aligns better with MCP because the server is only useful if it can distinguish safe, approved tool calls from broad, post-authentication lateral movement. These controls tend to break down when the MCP server is fronting legacy systems that cannot enforce per-action checks because the tunnel becomes the only enforceable boundary.
Common Variations and Edge Cases
Tighter per-action control often increases integration overhead, requiring organisations to balance faster agent enablement against stronger operational discipline. That tradeoff is real, especially when teams want to connect MCP to many tools quickly. Best practice is evolving, and there is no universal standard for every implementation pattern yet.
One common edge case is internal-only deployment, where teams assume private network placement makes MCP safe. It does not. A private MCP server can still leak secrets, over-authorize tools, or let an agent fan out into systems it should not reach. Another edge case is “single sign-on for the server” used as a substitute for downstream authorization. That can improve user experience while still leaving tool abuse invisible after login. The lesson from NHIMG’s mcp security research and agent threat coverage is that visibility into the session is not the same as control over the action.
Where mature teams are getting traction is by pairing MCP with a Zero Trust mindset, as reflected in OWASP Agentic AI Top 10 and the broader risk framing in The State of MCP Server Security 2025. If the server cannot prove what the agent is trying to do, the tunnel should not be treated as trust.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF 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 | A01 | Addresses overtrusted agent sessions and missing runtime tool authorization. |
| CSA MAESTRO | T1 | Covers agent trust boundaries, orchestration, and tool-use governance. |
| NIST AI RMF | Supports governance for unpredictable AI behavior and context-aware controls. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Relevant to shared secrets, weak scoping, and exposed credentials in MCP servers. |
| NIST Zero Trust (SP 800-207) | SC-7 | Applies zero-trust segmentation to prevent tunnel-based implicit trust. |
Require per-action approval and narrow each agent tool call to the minimum needed scope.
Related resources from NHI Mgmt Group
- What do organisations get wrong when they treat identity verification as a pilot project?
- What do organisations get wrong when they treat human, machine, and AI identities the same?
- What do organisations get wrong when they treat compliance frameworks as the same thing?
- What do organisations get wrong when they treat phishing resistance as a technology project?
