Who is accountable when MCP access controls are enforced in the application instead of the gateway?

Why This Matters for Security Teams

When MCP access controls are enforced in application code instead of at a gateway or other central policy point, accountability becomes harder to prove and harder to sustain. The organisation still owns the risk, but operational responsibility shifts toward the teams that can actually keep controls consistent, observable, and revocable. That distinction matters because application-level enforcement fragments policy, weakens auditability, and creates bypass paths when code changes, deployments fail, or one service diverges from another.

This is especially important in MCP-heavy environments because tool permissions, scope checks, and secrets handling are not static concerns. They change as agents, services, and integrations change. NHIMG’s analysis of the The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how often control enforcement is still inconsistent in practice. For broader identity governance, the OWASP Non-Human Identity Top 10 frames this as a control-plane problem, not just an application design issue.

In practice, many security teams discover the ownership gap only after an application release has silently removed a control that the audit team believed was still active.

How It Works in Practice

The cleanest accountability model is simple: the organisation owns the outcome, platform and security teams own the enforcement plane, and application teams consume centrally governed policy rather than reimplement it. That usually means the gateway, broker, or sidecar becomes the place where MCP scope checks, authentication, authorisation, logging, and rate limits are enforced consistently. Application code can still request access, but it should not be the only place where access decisions live.

This pattern aligns with current guidance from both the OWASP Top 10 for Agentic Applications 2026 and NIST SP 800-53 Rev 5 Security and Privacy Controls, which both favour consistent control enforcement and auditable decision points. It also reflects NHIMG’s research on Ultimate Guide to NHIs — Standards, where central governance is repeatedly treated as the mechanism that makes non-human access manageable at scale.

• Use one policy decision point for MCP scope, rather than duplicating logic across services.
• Log the requestor, tool, scope, decision, and outcome at the gateway for audit trails.
• Keep application code focused on business logic, not security decisions that can drift over time.
• Require security-owned change control for policy updates, especially for high-risk tools.

That said, this model still depends on clear service boundaries and reliable routing, and these controls tend to break down when direct service-to-service calls bypass the gateway because enforcement no longer has a single choke point.

Common Variations and Edge Cases

Tighter central enforcement often increases platform overhead, requiring organisations to balance consistency against release speed and service autonomy. That tradeoff is real, especially where teams want fast iteration or where legacy services were built before MCP controls existed. Best practice is evolving, but there is no universal standard for whether the gateway, service mesh, or broker should be the primary enforcement layer in every architecture.

In high-trust internal networks, teams sometimes assume that application-level checks are enough because traffic is “already inside.” That assumption is weak for MCP because policy drift, over-permissioned tools, and inconsistent logging can create hidden privilege exposure. The risk becomes more visible when a single application controls multiple tools, or when one workflow can chain requests across several services. NHIMG’s AI Agents: The New Attack Surface report found that 80% of organisations report AI agents have already performed actions beyond intended scope, which is a reminder that central controls matter most when behaviour becomes unpredictable.

For regulated environments, the practical answer is to document organisational accountability in policy, assign operational ownership to platform and security teams, and require evidence that enforcement is working outside application code. Where gateways are unavailable, compensating controls should be explicit, temporary, and reviewed frequently rather than treated as equivalent. The strongest stance is not that one team “owns” the risk alone, but that one team owns the control plane and one team owns the business outcome.

Related resources from NHI Mgmt Group

• When should organizations review access controls?
• What breaks when an MCP gateway creates a second access path outside existing IAM controls?
• Who is accountable when forged session data bypasses application access controls?
• Who is accountable when gateway spend or access changes bypass budget controls?