MCP controls how agents and tools speak to each other, while Kubernetes governs where the server runs, what it can reach, and how its identity is enforced. Protocol controls do not replace runtime controls. Production security depends on both layers, but the operational authority sits in the substrate.
Why This Matters for Security Teams
Kubernetes governance and MCP protocol controls solve different security problems, and confusing them creates false confidence. MCP governs how an agent requests tools and data, but Kubernetes governs the runtime boundary where that server is scheduled, which network paths it can use, and what workload identity it presents. That distinction matters because autonomous agents do not behave like fixed applications: their tool use changes with context, prompting, and task chaining.
NHI Management Group sees this pattern repeatedly in agentic environments. The strongest evidence is that agent risk is already materialising in production, with AI Agents: The New Attack Surface report showing 80% of organisations reporting agent actions beyond intended scope. Protocol rules alone do not stop a server-side compromise, and cluster controls alone do not prevent an agent from abusing allowed tool calls. Current guidance from NIST Cybersecurity Framework 2.0 and OWASP Agentic AI Top 10 points to layered control, not substitution.
In practice, many security teams discover the gap only after an agent has already chained a tool call into a broader cloud or data-plane incident, rather than through intentional design review.
How It Works in Practice
Think of MCP as the language of the conversation and Kubernetes as the room, the locks, and the surveillance. MCP controls what methods an agent can invoke, what schemas those methods follow, and which tool endpoints are discoverable. Kubernetes controls pod identity, service account binding, namespace isolation, network policy, secrets mounting, admission rules, and whether the MCP server can reach anything beyond its intended service boundary.
For agentic workloads, the practical security pattern is to combine both layers with workload identity and short-lived credentials. A Kubernetes-deployed MCP server should present a verifiable workload identity, preferably through mechanisms such as SPIFFE or OIDC-backed service identity, while the agent’s tool access should be authorised at request time using policy-as-code. That is the point where intent-aware or context-aware authorisation becomes relevant. An agent asking to read a ticket is not the same as an agent asking to export customer records, even if both requests travel over the same protocol.
Operationally, teams should separate concerns:
- MCP policy defines which tools exist and which tool shapes are valid.
- Kubernetes policy defines where the server runs and what it can reach.
- Identity policy defines who or what the server is, at runtime.
- Secrets policy defines how ephemeral credentials are issued, scoped, and revoked.
The distinction is consistent with NHIMG guidance in Top 10 NHI Issues and the lifecycle focus in the Ultimate Guide to NHIs. Best practice is evolving, but the direction is clear: protocol controls should be enforced at the request layer, while Kubernetes enforces the runtime boundary underneath.
These controls tend to break down when a single cluster hosts many agents and shared MCP servers, because lateral movement, overbroad service accounts, and reused secrets make the protocol boundary easy to bypass.
Common Variations and Edge Cases
Tighter separation between protocol and runtime often increases operational overhead, requiring organisations to balance stronger containment against deployment complexity. That tradeoff is especially visible in multi-tenant clusters, shared dev environments, and rapid agent prototyping, where teams want speed but still need meaningful isolation.
There is no universal standard for this yet, but current guidance suggests treating MCP servers like privileged workloads rather than ordinary app components. If an MCP server can reach internal APIs, cloud metadata services, or secret stores, Kubernetes hardening becomes the decisive control plane. If the agent itself can dynamically select tools or chain actions across multiple servers, then MCP alone is not enough, because the protocol does not understand business context or real-time risk.
Edge cases matter. A harmless-seeming read-only tool can become risky when combined with prompt injection, cached credentials, or a permissive service account. Likewise, namespace isolation does not help if the agent’s tool permissions are too broad inside MCP. Practitioners should align this layered model with OWASP Top 10 for Agentic Applications 2026 and the NHIMG perspective in Ultimate Guide to NHIs - Standards.
In regulated or high-risk environments, the safest assumption is that protocol controls limit what the agent may ask for, while Kubernetes and identity controls determine whether that request should ever be possible in production.
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 | A2 | Agent tool abuse depends on protocol and runtime boundaries. |
| CSA MAESTRO | AG2 | MAESTRO covers agent runtime governance and containment. |
| NIST AI RMF | AI RMF addresses operational risk from autonomous behaviour. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | MCP servers are non-human workloads that need identity controls. |
| NIST CSF 2.0 | PR.AC-4 | Access control must separate protocol permissions from runtime privilege. |
Map agent and platform controls to risk, then reassess them as behaviour changes.
Related resources from NHI Mgmt Group
- What is the difference between human identity governance and AI agent governance?
- What is the difference between managed identities and hardcoded secrets for AI agents?
- What is the difference between workload identity and API keys for AI agents?
- What is the difference between governing human access and governing AI agent access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
