How to give an AI agent safe Kubernetes access
The question isn't whether to let an agent read your cluster — it's what stops it from writing to one, and what proves what it actually did afterward. OpsKit answers that with four independent layers, not a prompt telling it to be careful.
Layer 1 — the MCP server has no write tools
OpsKit's Kubernetes connector exposes 15 tools. All 15 are reads: pods, events, logs, resource usage, GitOps state. There is no apply, delete, or exec tool in the server for a model to call, correctly or incorrectly — the capability doesn't exist in the connector at all.
Layer 2 — opskit-guard blocks the shell
A pre-tool hook intercepts every bash command your agent tries to run before it executes, and checks it against an allowlist. kubectl apply, helm upgrade, terraform apply, kubectl exec, and 120+ bypass patterns — shell wrappers, pipe chains, inline environment overrides — are blocked before they reach your cluster.
Auditable, not trust-me
The safety layer ships as its own open-source package, opskit-guard, under MIT. Read exactly what it allows and blocks before you point it at production — don't take a vendor's word for what a hook does.
Layer 3 — fixes only ever leave as a GitOps PR
When OpsKit proposes a remediation, the output is a patch file or a pull request against the repository ArgoCD or Flux owns — never a direct cluster mutation. Auto-merge is never enabled. A human reviews and merges, same as any other change.
Layer 4 — every action is recorded in a chain you can verify
The first three layers stop a mutation from happening. This layer answers a different question: after an investigation, how do you know the agent didn't do anything it didn't tell you about? Every tool call is appended to a hash-chained log — editing, deleting, or reordering an entry afterward breaks the chain, and opskit replay --verify names the exact record where it broke. See the flight recorder for the full detail, including what it deliberately does not cover.
Enforce it at the cluster too
Agent-side hooks are the first line of defense, but defense in depth means the cluster itself shouldn't trust the identity with more than it needs. Apply the read-only RBAC role that ships with OpsKit:
$ kubectl apply -f rbac/opskit-readonly.yaml # or, scoped to specific namespaces: $ kubectl apply -f rbac/opskit-readonly-namespaced.yaml
See namespace-scoped read access for how to pair this with an allowlist of namespaces and labels.
Limitations
Hooks and the RBAC role are independent controls — installing OpsKit doesn't automatically apply the RBAC manifest, and applying the RBAC manifest doesn't install the hooks. For a real pilot, security teams should verify both are in place, not assume one implies the other.
Ready to point it at your cluster?
Get instant access — Free