TL;DR: Live cluster access lets an AI SRE agent find broken Kubernetes workloads and missing telemetry that dashboard-only summarizers miss, according to Mezmo, but the real control point is read-only scope plus enforced tool filtering. Read access is useful for diagnosis, yet governance still has to assume the agent can reason across partial evidence without mutating the cluster.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Mezmo's blog post: Read-only Kubernetes agent access changes what an AI SRE can find, but not the governance requirement to constrain tool scope and write permissions.
Why it matters: IAM and platform teams need to treat agent access to clusters as a privilege decision, because read-only diagnostics still create exposure if tool scope, logging, and approval gates are weak.
Context
AI SRE agents are software systems that inspect live infrastructure, reason over telemetry, and choose next actions from tools they are allowed to use. When those tools include cluster and metrics access, the question stops being whether the model is clever enough and becomes whether its runtime authority is tightly bounded. Kubernetes NHI Security Guide is the right foundation for that governance boundary.
The core security gap is not observability itself. It is the assumption that a model can safely inspect production systems without becoming another privileged non-human actor in the environment. In Kubernetes, that means the access model, tool registry, and runtime permissions all have to be designed together, not bolted on after the agent is already live.
This pattern is typical for early agent deployments: teams want diagnostic value before they are ready to think about execution rights. That is sensible, but it only works if read access is treated as a governed identity surface rather than an informal testing shortcut.
Key questions
A: Teams should attribute agent activity to the workload object that stays stable across restarts and rollouts, not to the service account alone. A service account tells you what was allowed, but not which agent acted. For runtime investigation, the Deployment is usually the right unit because it preserves one behavioral history while pods come and go. That makes alerting, rollback, and ownership clearer.
Q: What makes read-only agent access to Kubernetes risky?
A: Read-only agent access to Kubernetes is risky because cluster state, workload metadata and secrets names can still be exposed through API reads, logs and discovery calls. A compromised token, service account or kubeconfig with get and list permissions can map namespaces, service accounts, ConfigMaps and Pod specs, then support lateral movement or privilege escalation.
Q: How does Model Context Protocol shape AI agent privileges?
A: Model Context Protocol shapes AI agent privileges by exposing tools, resources and prompts through a controlled interface, so the agent only receives the capabilities the server publishes. Access should be bound to a narrow service account or delegated token, with per-tool authorisation, scoped credentials and explicit revocation when the agent no longer needs a capability.
Q: Are human approval gates enough for write-capable agents?
A: No. Human approval gates are a control, but they are not enough on their own for write-capable agents because the agent still needs a bounded runtime scope, least-privilege tool access and a clear human owner. Approval should sit alongside per-action authorisation, logging and revocation, otherwise an approved agent can still write beyond its intended task.
Technical breakdown
How MCP tool exposure changes Kubernetes agent authority
Model Context Protocol gives an agent access to external tools at runtime instead of baking those capabilities into the application itself. That matters because the security boundary is no longer just the model prompt or the code path that calls it. The effective authority of the agent is the intersection of what the MCP server registers, what the backing service account can do, and what the orchestration layer decides to expose. In Kubernetes, a read-only server can still disclose pod states, events, and logs, which is useful for diagnosis but also enough to surface sensitive operational detail if governance is weak. See the AI Agent Observability, Audit and Incident Response Guide.
Practical implication: Treat MCP tool registration as part of the access-control plane, not as a mere integration detail.
Why read-only Kubernetes access still needs identity governance
Read-only does not mean low risk. A Kubernetes agent with view-only access can still inspect workloads, events, and telemetry across namespaces, and that information can reveal workload structure, failure states, and operational patterns. The main restraint is not whether the agent can edit resources, but whether it can over-reach into namespaces, nodes, or data it never needed. Service accounts, RBAC, and tool filtering must therefore be aligned, because any mismatch creates a non-human identity that can observe more than the task requires. See the Kubernetes NHI Security Guide.
Practical implication: Apply least privilege to the agent's Kubernetes service account and the toolset it can discover.
Why the coordinator and worker split matters for agent containment
Orchestrated agents reduce blast radius by separating planning from execution. The coordinator decides which worker should act, and each worker gets a narrower tool list than the full environment. That design helps because one model instance no longer carries every capability in a single context window. It also creates a new governance question: if the coordinator sees only a truncated tool inventory, it may under-route work or miss that a risky capability exists. The architecture is safer than a single omnipotent agent, but only if the control plane faithfully enforces the separation it advertises. Read AI Agents vs Agentic AI.
Practical implication: Verify that each worker's effective tool set matches the intended role and cannot be widened by configuration drift.
Threat narrative
Attacker objective: The objective in this threat pattern is not takeover but over-observation, where the non-human actor gains broad situational awareness without equally strong limits on what it can inspect.
- Entry occurs when the agent is granted live access to Kubernetes and Prometheus through MCP servers rather than through a static summary feed.
- Credential access is constrained by read-only service account permissions, but the agent still receives enough runtime authority to query cluster state and operational telemetry.
- Impact appears as diagnostic reach, not mutation: the agent can reveal failures, sensitive workload structure, and operational gaps without being able to change the cluster.
Breaches seen in the wild
- TeamTNT worm 2020: A TeamTNT cryptomining worm spread through exposed Docker APIs and stole AWS credential files from every host it infected, Cado Security found.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Read-only access is the right starting point, but it is not a governance finish line. Mezmo's example shows that diagnostic value appears as soon as an agent can see live cluster state, yet the same access pattern also creates a governed non-human identity that can observe more than a human operator intended. The important decision is not whether the agent can write, but whether its authority is intentionally scoped from the first deployment. Read-only is a containment choice, not an assurance of safety.
Tool filtering is now part of the identity model. If the MCP server only registers read-only tools, then privilege is being enforced before the model ever reasons about an action. That is a stronger control than prompt-based restraint because it reduces the attack surface at the source of capability exposure. In practice, the agent's effective identity is the combination of service account, discovered tools, and orchestration policy, which makes Kubernetes NHI Security Guide directly relevant to how these systems should be governed.
Search compression creates a new operational expectation for SRE teams. A live agent that can inspect the cluster can compress hours of manual investigation into seconds, but that speed only helps if the evidence trail is trustworthy and the control plane is predictable. The field will increasingly expect agents to explain what they saw, what they could not see, and why. That makes observability for the agent itself a first-class governance requirement, not an afterthought.
The most material risk is capability drift. Today the system is read-only, tomorrow a team may widen globs, add write tools, or let a coordinator see more than it should. Once that happens, the same architecture that supported diagnosis can become a route to accidental mutation. The right policy question is how quickly the environment can detect and approve that widening before it becomes normal.
From our research library:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
What this signals
Capability separation will become the default design test for production agents. A system that can observe live infrastructure should not automatically be able to mutate it, and the practical proof is whether the same agent can be shown a failure without being able to widen its own reach. That makes tool registration, service account scope, and approval routing part of one control plane, not three separate projects.
Agent observability must include the agent's own blind spots. If an AI SRE can say that telemetry was incomplete or rate-limited, that is a governance signal, not a failure of usefulness. Teams should expect future operating models to track what the agent could not verify, because bounded confidence is safer than false certainty in production decision-making.
Read access is where most teams will discover their first governance gap. Before anyone grants an agent write authority, the environment needs a clear answer to what it can see, which identities it uses, and how its tool list is constrained. The next maturity step is to make that boundary auditable before it becomes operationally normal.
For practitioners
- Scope the agent to a dedicated service account Bind the AI SRE agent to a Kubernetes identity with the smallest possible namespace and verb set, then review every tool the MCP server exposes against that scope.
- Separate diagnostic tools from write tools Register read-only cluster and telemetry tools in a different server from any patch, restart, or delete capability so the agent cannot discover mutation paths by default.
- Log every tool call with enough context to reconstruct intent Capture coordinator decisions, worker calls, query text, and returned evidence so investigations can show which non-human identity saw which resource and why.
- Require approval before widening any tool glob Treat new write-capable MCP tools as a governance change, and gate them behind a human approval path before the agent can call them in production.
Key takeaways
- An AI SRE agent becomes a governed non-human observer the moment it can query live cluster state, even if it cannot make changes.
- The combination of service account scope, MCP tool registration, and orchestration policy determines the real authority of the agent.
- Production readiness depends on proving that diagnostic access stays separate from write capability, with approvals and logging around any expansion.
Related NHI Mgmt Group resources: Kubernetes NHI Security Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Security Policy Template · AI Agents vs Agentic AI
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The agent's cluster access depends on how its non-human identity is authenticated and scoped. |
| NHI-05 — Overprivileged NHI | Read-only does not prevent overbroad observation when the agent can reach too much of the cluster. | |
| Recommendation — Bind the agent to authenticated identities whose access can be verified and limited at runtime. Reduce the agent's namespace, verb, and tool scope to the minimum required for diagnosis. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post is fundamentally about who and what may access cluster and telemetry resources. |
| Recommendation — Review entitlements for the agent's service account and tool registry as one access-control decision. | ||
| CIS Controls v8 | CIS-5 — Account Management | The agent and its workers are account-scoped actors whose privileges must be managed explicitly. |
| Recommendation — Inventory the agent's accounts, roles, and tokens, then remove anything not needed for read-only work. | ||
| MITRE ATT&CK | TA0007;TA0006 — Discovery; Credential Access | The threat pattern here is broad discovery through runtime access, even without mutation rights. |
| Recommendation — Map agent exposure to discovery and credential-access tactics and monitor the paths it can inspect. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- orchestration mode: Orchestration mode is the way an AI agent is configured to coordinate tasks, tools and other agents during runtime. It defines how the agent plans, delegates and executes actions, including whether it can call tools directly, require approvals or hand off work, and therefore affects its effective authority and containment.
- Kubernetes service account: A Kubernetes service account is the identity a workload uses to call the cluster API and interact with other resources. It is a non-human identity, so its permissions, token handling, and lifecycle need governance just like any other privileged machine credential.
- Read-only access: Read-only access allows a machine or agent to inspect data or systems without changing them. In AI-assisted development, it is a practical least-privilege default because it lets teams validate behaviour and gather context while reducing the chance of unintended modification or privilege escalation.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and workload identity patterns that matter when agents touch live infrastructure. It is designed for practitioners who need to govern non-human access without losing operational value.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org