Accountability should sit with the team that owns the workload, but it must be shared across platform, identity, and application stakeholders. If one team can open the tunnel while another owns the credentials and a third owns the tools, then the operating model needs explicit approval and revocation rules before production use.
Why This Matters for Security Teams
Exposing an mcp server in Kubernetes is not just a networking choice. It creates a control point where workload identity, tool permissions, secrets handling, and pod-to-pod access all converge. If accountability is vague, teams tend to treat the exposure as a temporary plumbing issue instead of a security boundary. That is where unauthorized tool use, credential leakage, and untracked agent actions start to appear.
The risk is amplified because MCP is often used to connect AI agents to internal systems, which means the server can become a high-trust broker for data and actions. NHI Management Group research on the 52 NHI Breaches Analysis shows how quickly identity and access mistakes become incident paths when machine credentials are not governed with the same discipline as human access. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls aligns accountability to control ownership, not convenience.
In practice, many security teams discover the exposure problem only after an agent has already reached a tool or secret that was never meant to be externally reachable.
How It Works in Practice
Accountability should follow the team that owns the workload, because that team understands the business purpose, the tool chain, and the risk of exposing the server. But operational responsibility is shared. Platform teams usually own the Kubernetes service, ingress, namespace boundaries, and network policy. Identity teams own the service identity, certificate lifecycle, token issuance, and revocation. Application teams own the MCP server logic, tool catalog, and which upstream systems the server can invoke.
This division matters because a secure MCP exposure is not a single control. It is a runtime decision about who can reach the server, what the server can do, and under what identity it acts. That is why OWASP Top 10 for Agentic Applications 2026 and the OWASP Agentic Applications Top 10 both emphasize tool misuse, over-privileged agents, and weak authorization boundaries. The practical answer is explicit ownership plus explicit approvals for exposure, ideally with named approvers for namespace publication, secret binding, and tool enablement.
- Workload owners should request the exposure and accept the business risk.
- Platform teams should enforce ingress, mTLS, and namespace policy.
- Identity teams should bind the server to workload identity and short-lived credentials.
- Security teams should define review, logging, and revocation requirements before production.
Where possible, exposure should use ephemeral access paths and policy checks at request time rather than broad static allowlists. If the server is fronted by a gateway, the gateway owner must also be part of the accountability chain. These controls tend to break down in shared Kubernetes clusters with ad hoc namespace ownership, because no single team can reliably enforce the end-to-end trust boundary.
Common Variations and Edge Cases
Tighter exposure control often increases delivery overhead, requiring organisations to balance speed against the risk of turning an MCP server into an unmanaged internal API. That tradeoff is real, especially when teams want to move fast with agent pilots. The rule of thumb is simple: the more the MCP server can read, write, or trigger, the stronger the approval and revocation model needs to be.
There is no universal standard for this yet, but current guidance suggests treating highly privileged MCP servers like sensitive service accounts, not like ordinary application endpoints. If an agent can chain tools, reach secrets, or pivot across namespaces, accountability cannot stop at the workload team alone. It must include the infrastructure owner who published the path and the identity owner who issued the credential. This is consistent with the direction of AI Agents: The New Attack Surface report, which shows that agent behaviour often exceeds intended scope, and with the broader NHI lessons from Ultimate Guide to NHIs — Why NHI Security Matters Now.
In regulated environments, the safest operating model is a named owner for exposure decisions, a separate approver for credential release, and a documented revocation path if the MCP server is misused or no longer needed.
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 | TBD | Agent tool exposure creates over-privileged action paths. |
| CSA MAESTRO | TBD | Covers governance for agentic workloads and tool brokerage. |
| NIST AI RMF | Supports governance and accountability for AI-enabled systems. | |
| NIST CSF 2.0 | PR.AC-4 | Access control must map to workload ownership and enforced boundaries. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Machine identities and secrets must be owned and governed. |
Review agent tool access at runtime and restrict MCP exposure to approved, least-privilege actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
