Accountability should sit with the team that owns the protocol exposure, not only the infrastructure host. That usually means platform, application, and identity stakeholders all share responsibility for access scope, authentication, and external discoverability. If no owner can answer who can see the tools, governance has already failed.
Why This Matters for Security Teams
Exposed MCP endpoints are not just another forgotten service interface. They define what tools an agent can discover, which credentials it can reach, and whether external parties can invoke capabilities that were assumed to be internal. Accountability matters because MCP exposure sits at the boundary of platform engineering, application ownership, and identity control. If ownership is unclear, the endpoint usually outlives the risk review.
The practical danger is that mcp server often expose more than they should. Astrix Security found that 53% of MCP servers expose credentials through hard-coded values in configuration files and only 18% implement any form of access scoping for tool permissions. That pattern makes exposed endpoints a governance issue, not just a hosting issue. The broader agentic risk is consistent with NHIMG research in the AI Agents: The New Attack Surface report and the Analysis of Claude Code Security, where tool access and uncontrolled execution paths become the real attack surface.
In practice, many security teams discover exposed MCP endpoints only after tools have already been enumerated from outside the intended trust boundary.
How Accountability Should Be Assigned in Practice
Accountability should follow control of the protocol exposure, not simply the machine or cluster that hosts it. The team that publishes the MCP endpoint should own discoverability, authentication, authorization scope, logging, and revocation paths. Infrastructure teams may operate the runtime, but they cannot be the only accountable party if they do not define which tools are visible or which identities may call them.
A useful operating model is to assign a single service owner and then make platform, application, and identity stakeholders accountable for their parts of the control plane. The service owner is responsible for the business purpose of the endpoint and for approving which tools are exposed. Platform teams handle deployment patterns, network controls, and secret handling. Identity teams manage workload identity, token issuance, and policy enforcement. This aligns with current guidance from OWASP Agentic AI Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls, which both emphasize control definition, least privilege, and auditability.
- Define a named owner for every production MCP endpoint.
- Record the tool inventory and its intended audience.
- Use runtime policy checks for access, not just perimeter filters.
- Require short-lived secrets and revocation on change.
- Log every tool discovery and every invocation for audit.
NHIMG’s 52 NHI Breaches Analysis shows that identity exposure becomes materially worse when no one owns the full access path from discovery to use. These controls tend to break down when MCP endpoints are embedded inside fast-moving AI application stacks because ownership is split across teams that never reconcile tool exposure with identity policy.
Common Variations and Edge Cases
Tighter accountability often increases operational overhead, requiring organisations to balance release speed against control coverage. That tradeoff is real, especially when MCP endpoints are created dynamically by agentic workflows or when multiple product teams share a common platform. Best practice is evolving, but there is no universal standard for this yet: some organisations centralise ownership in a platform security team, while others keep ownership with the application team and require formal identity sign-off.
The edge case that causes the most confusion is a “temporary” MCP endpoint used for testing that later becomes production-facing without a new review. Another common failure mode is when security assumes the cloud or container team owns the endpoint, while the application team silently decides which tools are reachable. Where exposed endpoints back AI agents, accountability should also include the team responsible for the agent’s tool policy, because exposed access without scope control can turn into lateral movement or data leakage very quickly. That concern is reinforced by the Ultimate Guide to NHI Security Matters Now and the OWASP Top 10 for Agentic Applications 2026.
Accountability becomes ambiguous when teams treat exposed endpoints as a pure networking problem, because the risk is actually distributed across identity, tooling, and runtime behaviour.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AA-01 | Exposed MCP endpoints expand agent tool reach and attack surface. |
| CSA MAESTRO | A1 | MAESTRO maps ownership and control of agent tool access. |
| NIST AI RMF | AI RMF governance requires accountability for autonomous system impacts. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Exposed MCP endpoints often leak secrets and weaken NHI controls. |
| NIST CSF 2.0 | PR.AC-1 | Accountability depends on managing identities and access to exposed services. |
Define accountable owners for production AI endpoints and document oversight, monitoring, and escalation paths.
