Accountability shifts to the team operating the transport layer and gateway boundary. Once MCP moves into production, security and platform teams must own identity enforcement, session logging, rate limits, and policy decisions at the ingress point. Application teams still own tool behavior, but governance becomes a shared operational responsibility.
Why This Matters for Security Teams
When an MCP estate leaves local development and becomes production infrastructure, the question is no longer who wrote the tool calls, but who can prove what happened, who approved it, and who can stop it. That accountability moves to the team operating the transport layer and gateway boundary because that is where identity enforcement, access checks, logging, and throttling actually occur. Application teams still own tool logic, but they do not control the trust boundary once traffic is brokered centrally.
This matters because MCP security failures often look like routine integration issues until audit or incident response needs a defensible record. NHIMG research on The State of MCP Server Security 2025 shows how quickly weak scoping turns into exposed credentials and overbroad tool access, while the OWASP Non-Human Identity Top 10 treats secret sprawl and missing lifecycle control as recurring NHI risks. In production, those risks are amplified by the need for traceability across multiple agents, services, and approvals.
Security teams usually discover the accountability gap only after a tool has already been used outside intended scope and the logs are too thin to reconstruct why.
How It Works in Practice
The practical model is to treat the MCP gateway as the enforcement point and the production operator as the accountable owner for auditability and access control. The application team defines what the tool should do, but the platform or security team decides whether a request is allowed at runtime, whether the caller is authenticated, and whether the event is recorded with enough context for forensics. This is consistent with current guidance in NIST Cybersecurity Framework 2.0 and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.
Operationally, the boundary owner should be able to answer four questions for every production request: who or what called the tool, what policy allowed it, what data was exposed, and how long the credential or session remained valid. That means:
- enforcing workload identity at ingress rather than trusting local developer credentials
- issuing short-lived access and revoking it when the session ends
- logging tool name, caller identity, request context, and decision outcome
- applying rate limits, scope filters, and deny-by-default policies at the gateway
For production MCP, this is less about static RBAC tables and more about policy evaluation at request time, especially when the same agent can behave differently across environments. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reinforce that auditability depends on lifecycle control, not just credential issuance. These controls tend to break down when MCP servers are deployed directly by feature teams behind inconsistent proxies because the gateway no longer has a single authoritative policy path.
Common Variations and Edge Cases
Tighter gateway control often increases release overhead, requiring organisations to balance developer velocity against evidentiary strength. That tradeoff becomes sharper when a local prototype is promoted into a shared production service, because the team that owns the code may still assume it owns the access model even after platform engineering has taken over the ingress layer.
There is no universal standard for this yet, but current guidance suggests three common operating models:
- platform-owned controls, where one team runs the gateway, identity checks, and audit logs for all MCP traffic
- shared governance, where application teams define scopes and platform teams enforce them centrally
- delegated controls, where mature product teams manage their own gateway policies under a common security baseline
The second model is usually the most realistic for production because it keeps policy decisions near the boundary while preserving tool-owner accountability for business logic. That said, auditability can still fail in multi-tenant MCP estates, during rapid experimentation, or when developers bypass the gateway for direct server access. NHIMG’s AI Agents: The New Attack Surface report is a useful reminder that governance gaps are already visible in agent deployments, and the same pattern applies when MCP becomes the control plane for those agents. The practical answer is that accountability for access control and logs belongs to the production boundary owner, while tool correctness remains with the team shipping the tool.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Production MCP relies on strong non-human identity boundaries and auditability. |
| OWASP Agentic AI Top 10 | A2 | Agentic tool use increases the need for runtime authorization and logging. |
| CSA MAESTRO | TR-1 | MAESTRO addresses trust boundaries and operational control for agentic systems. |
| NIST AI RMF | AI risk governance requires accountable monitoring and oversight of autonomous behavior. | |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and identity verification map directly to gateway enforcement. |
Set explicit ownership for logging, access control, and escalation paths before production rollout.
