They should treat the MCP server as a translation layer, not a trust boundary. The wrapped APIs still need object-level authorisation, least privilege, and confusion-resistant identity checks, because an autonomous agent can otherwise use a valid tool path to reach data or actions it was never meant to access.
How MCP Changes the Authorisation Problem, Not the Authorisation Requirement
An MCP layer simplifies how an agent reaches tools, but it does not replace the application’s own access decisions. The server may translate requests and broker context, yet the wrapped systems still decide what a caller can see or do. That means object scope, action scope, and identity confidence must be enforced at the API or resource layer, not inferred from a successful tool invocation alone.
The practical mistake is to treat “the agent got through MCP” as proof of legitimacy. It only proves the transport and tool path worked. The authorisation decision still needs to answer a narrower question: which object, which operation, and which subject are permitted for this request at this moment?
That distinction matters most when a tool can read records, trigger workflows, or mutate state. If the downstream API accepts the call without checking object ownership, tenant boundary, delegated scope, and current privilege, the agent can follow a valid path into data or actions that were never intended for it. A translation layer can help normalise requests, but it cannot substitute for the security logic that protects the target system.
What Authorisation Must Still Happen Beneath the MCP Server
Teams should expect at least three checks beneath the MCP layer: object-level authorisation, least privilege for the calling identity, and a confusion-resistant identity check that binds the request to the right principal and context. In practice, that means the downstream system should validate who is acting, what they are allowed to access, and whether the request was delegated for this exact action rather than inherited from some broader tool permission.
This is where many designs fail. A tool that is broadly allowed to “search customer data” can still become overpowered if the backing API does not limit records by tenant, ownership, case assignment, or another defensible object rule. Likewise, an agent that has a valid credential path is not automatically entitled to every operation that the MCP server exposes. Authorisation models only work well when the downstream policy matches the real business object and action, not just the tool name.
Least privilege should also be applied at the level of the downstream API, not only at the MCP server. If the server is acting as a broker, the broker’s own permissions should be narrow, and the wrapped service should still enforce its own checks. That separation matters because privilege at the orchestration layer often drifts wider than the safe set of actions on the underlying resource.
Teams building agent-facing systems should also separate identity proof from authorisation logic. A valid login, token, or session does not answer whether the requested object is in scope. That is especially important when requests arrive through delegated or reused context. AI agent authorisation works best when each action is evaluated against current policy, not trusted because it came from a previously approved tool chain.
Where Teams Should Put Controls, Reviews, and Boundaries
The cleanest control pattern is to treat MCP as a routing and normalisation layer, then put the real enforcement where the resource lives. For read paths, that usually means record-level checks, tenant filtering, and policy evaluation close to the data source. For write paths, it also means explicit action approval rules, immutable auditability, and a hard stop when the requested effect exceeds the delegated scope.
Teams should review whether their tool catalogue exposes actions that are broader than the policy model beneath them. If so, either narrow the tool, add a policy decision point, or split the capability into smaller operations that can be authorised separately. A single “do everything” tool almost always creates a larger blast radius than the underlying business process needs.
The same logic applies to identity confidence. If the MCP path can be reached by a long-lived token, a shared integration identity, or a credential that is reused across environments, the downstream policy becomes harder to trust. MCP security guidance is strongest when it keeps token handling, audience restriction, and delegated authority aligned with the actual resource server, not with the agent’s convenience.
Risk and Threat Considerations
When authorisation is too far upstream, the MCP layer can become a confused deputy that forwards a valid request to the wrong place with too much privilege. The main risk is not that the agent “breaks” the protocol, but that it uses a legitimate path to reach objects, actions, or tenants that were never intended to be reachable through that path.
Failure mechanism: The upstream tool path is accepted, but the wrapped API fails to re-check object ownership, action scope, or delegated identity context. That lets a broadly authorised agent, token, or integration identity perform a narrower operation without the downstream system noticing the mismatch.
Impact: Confidential data can be overexposed, workflows can be triggered out of policy, and write operations can be executed on the wrong records or environment. At scale, that turns a convenient abstraction layer into a high-blast-radius control failure across many tools and tenants.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | MCP-backed identities can become overpowered if backend APIs do not re-check scope. |
| Recommendation — Constrain downstream identities so MCP brokers cannot exceed the intended object and action scope. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | An agent using MCP can abuse excessive delegated privilege if authorisation is too coarse. |
| Recommendation — Enforce per-action authorisation so agents cannot use a valid tool path for unauthorized access. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | The core failure described is object access granted through a valid path without object-level checks. |
| Recommendation — Apply object-level checks on every request to stop unauthorized cross-object access. | ||
| NIST Zero Trust (SP 800-207) | AC-5 — Least Privilege | The answer depends on limiting each path to the minimum privilege needed for the request. |
| Recommendation — Apply least privilege at both the broker and the wrapped API so authority cannot expand implicitly. | ||
| OWASP ASVS | V8 — Authorization | Wrapped APIs must still verify authorization, especially object and action scope. |
| Recommendation — Verify authorization in the application layer for every sensitive object and operation. | ||
Practitioner Guidance
What to prioritise: Put authorisation at the resource boundary first, then simplify MCP routing around that policy. If the wrapped API does not enforce object scope and delegated action scope itself, do not rely on the MCP server to make the decision for it.
What to verify: Test the full path with a request that is valid at the tool layer but invalid for the object or action, and confirm the downstream service rejects it. If that test passes unexpectedly, the policy model is too shallow.
Common mistake: Teams often harden the MCP server and assume the backend is now safe. In practice, the backend must still know which object is in scope, which action is allowed, and whether the caller’s identity context is sufficiently specific for the request.
Practitioner takeaway: Treat MCP as a convenience layer for mediation, not a place to terminate trust, because the last enforceable security decision must still sit with the system that owns the data or action.