Skip to content
All projects
AI in infrastructure operations

Namespace-Scoped MCP Servers

Letting AI agents operate Kubernetes without letting them operate it unsupervised.

Result
RBAC
on every mutating path
Where
CleverTap
2025 to present
Stack
5 tools
MCP · Kubernetes · RBAC · EKS · GitHub PR gates

Context

Once agents were reviewing code, the next question was whether they could help diagnose and fix infrastructure. MCP, the Model Context Protocol, is the interface an agent uses to reach a tool, which makes the server the natural place to put a permissions boundary. Reading cluster state is useful. Changing it is where the risk lives.

The problem

Giving an agent kubectl access is a permissions problem disguised as an AI problem. An agent with cluster-admin is an unbounded blast radius, and the failure mode is not malice, it is a confidently wrong action taken quickly. The design had to make the dangerous path narrow and observable rather than trusting the model to be careful.

  1. step: Agentdiagnoses an issue
  2. step: Read-only MCPcluster state
  3. step: Proposed planintended change
  4. control: RBACnamespace scope
  5. control: PR approvalhuman
  6. result: Appliedscoped mutation
Reading is open. Changing passes three independent controls.

Approach

  1. 01

    Split read from write at the server boundary

    A read-only MCP server answers questions about cluster state. Mutating operations live behind a separate, namespace-scoped server. An agent that only needs to diagnose never holds a capability that can change anything.

  2. 02

    Name the operations, on both sides of the boundary

    The read-only server inspects pods, deployments, nodes, logs, events, resource status and scheduling information through get, list and watch. It cannot modify a workload or read secrets at will. The mutating server is deliberately much smaller: inside one sandbox namespace it can create, inspect and delete test pods, and that is close to all of it. Cluster-admin, cross-namespace mutation and unrestricted secret access were all withheld on purpose.

  3. 03

    Let the cluster enforce it, not the prompt

    Nothing here depends on telling the model what it may do. Kubernetes identity, RBAC, namespace isolation, ResourceQuota and container resource limits are what actually hold the line. A prompt is a request; RBAC is a decision. If the two ever disagree, the cluster wins, which is the only arrangement worth deploying.

  4. 04

    Give every agent an identity that can be revoked

    Mutating access is issued per person rather than as one shared standing credential, so an action is attributable and one person's access can be withdrawn without disturbing anyone else. Credentials are short-lived, on the order of an hour, which bounds how long a leaked token is worth anything. Kubernetes supplies the underlying activity trail. An agent is treated as a production identity like any other: least privilege, attribution, short-lived credentials, controlled scope, revocation.

  5. 05

    Scope by namespace, enforced by RBAC

    The mutating server binds to specific namespaces through Kubernetes RBAC. The limit is enforced by the cluster, not by the agent's instructions. A prompt cannot talk its way past a role binding.

  6. 06

    Require a plan before an action

    Changes are proposed as a reviewable plan rather than applied directly, so the intended effect is visible before anything happens.

  7. 07

    Gate execution on pull-request approval

    A human approves the change through the same review path as any other infrastructure change. The agent accelerates the work; it does not shorten the control path.

Next case study
Backstage Golden Paths