What breaks is the delegation layer. The server no longer enforces audience validation, the token may be forwarded without protection, and the audit trail no longer shows which user approved which action. Teams also lose a natural place to terminate the credential outside the model, which makes it easier for the agent to expose or overuse access.
Why the Delegation Layer Breaks When You Go Direct to HTTP
When teams remove an mcp server and call tools or APIs directly, they usually remove more than a transport hop. They remove the place where the request can be shaped, checked, attributed, and bounded before it reaches the downstream system. That changes the security model from delegated action to raw credential forwarding, which is a materially different control surface.
The MCP server is often the boundary that turns a model-originated request into a controlled, policy-aware action. Without it, the agent or client has to carry the trust burden itself, and that usually means weaker audience checks, less reliable approval context, and a thinner separation between user intent and tool execution. The direct-call pattern may work technically, but it usually erodes the guardrails that made the integration safe enough to operate.
That difference matters most when the tool call is privileged, sensitive, or user-scoped. A raw HTTP integration can still be secure, but only if the team deliberately rebuilds the missing controls elsewhere, including audience binding, credential containment, and request attribution.
What Security Properties Disappear in Practice
Three practical losses show up again and again. First, the server no longer enforces the intended audience for the token, so a bearer credential can become easier to forward or replay in the wrong context. Second, the server is no longer the natural place to terminate and isolate the credential, which makes overuse and accidental exposure more likely. Third, the audit trail becomes flatter, because the downstream request may show who called the API but not which user approved the specific action.
That is why teams often notice that the integration feels “simpler” after they remove the MCP layer, but the simplification is partly achieved by deleting controls. The model, client, and API can still communicate, yet the security semantics are weaker because the request is now closer to a direct privilege-bearing transaction than a mediated one.
For teams standardising MCP transport behaviour, the most relevant detail is that the authorization model is not just about whether a token exists, but about where the token is validated and how the request remains bound to the intended resource and action. The MCP authorization specification captures that distinction directly.
How Teams Should Judge the Trade-off Before Removing MCP
Removing MCP is easiest to justify when the endpoint is low risk, the action is read-only, and the token can be tightly scoped and short lived. It becomes harder to justify when the action can change state, reach multiple backends, or act on behalf of a user. At that point, direct HTTP is not just an implementation choice, it is a governance choice about where delegation, authorization, and logging live.
Practitioners should also treat “works over HTTP” as an incomplete test. The real question is whether the design still preserves the separation between identity proof, request authorization, and action execution. If the answer is no, the team has not simplified the system, it has moved hidden security obligations into the application and hoped they stay correct.
That is why the relevant comparison is not MCP versus HTTP in the abstract, but mediated delegation versus ad hoc credential use. For a structured view of the broader control problem, MCP Security Guide and NHI Authentication Guide are useful references on token passthrough, credential containment, and service-to-service authentication patterns.
Risk and Threat Considerations
Removing the mediation layer increases the chance that a token is accepted in a broader context than intended, or forwarded into a path where the original user’s approval is no longer visible. That creates both misuse risk and post-compromise risk, because a stolen or overexposed credential is harder to constrain once the boundary that terminated it has been removed.
Failure mechanism: The direct HTTP path collapses audience binding, request mediation, and audit attribution into the application flow, so the same credential can be reused outside the original approval context or exposed to more of the execution chain than intended.
Impact: A compromised or overused token can drive unauthorised tool calls, blur accountability, and make incident response harder because defenders cannot easily reconstruct which user approved which action or where the credential should have been stopped.
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 addresses 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 | Direct calls weaken delegated authority and privilege boundaries for agent actions. |
| Recommendation — Enforce per-action authorization and bound agent privilege before allowing tool execution. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service, Workload, and Device-based Systems) | Covers service-to-service authentication and token handling in direct API calls. |
| AU-2 — Event Logging | Applies because the issue is loss of user-action attribution in the audit trail. | |
| AC-6 — Least Privilege | Relevant because removing mediation often broadens effective access beyond necessity. | |
| Recommendation — Require service authentication controls that prevent token forwarding beyond the intended resource. Log user approval and downstream action events so mediated actions remain attributable. Restrict tool and API access to the minimum permissions needed for each action. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question concerns continuous verification and bounded access instead of implicit trust in the client path. |
| Recommendation — Verify each request and enforce policy at the point of access instead of trusting the transport path. | ||
Practitioner Guidance
What to verify: Before removing an MCP server, verify where audience validation will happen, where the token will terminate, and whether the downstream API can still attribute the action to the approving user rather than only to the calling service.
Decision rule: If the call can read or change sensitive state, keep a mediation layer or rebuild its controls explicitly; if it is purely low-risk and read-only, direct HTTP may be acceptable with tightly scoped, short-lived credentials.
Practitioner takeaway: The question is not whether HTTP can replace MCP technically, but whether your replacement preserves bounded delegation, credential containment, and auditable user intent.
Related resources from NHI Mgmt Group
- What breaks when security teams rely on raw AI finding volume instead of context?
- What breaks when teams rely on MCP authorization instead of identity governance?
- What breaks when organisations rely on standard DLP controls instead of MCP-layer inspection for AI agent tool calls?
- What breaks when MCP tools rely on the UI instead of server-side authorization?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
