Namespace-scoped Kubernetes read access

Set the scope

$ npx opskit scope --namespaces payments,users --label-selector "team=payments"
# Restart your agent so the MCP server reloads.

$ npx opskit scope          # show current scope
$ npx opskit scope --clear  # back to kubeconfig-wide reads

Every one of the 13 read tools respects the current scope — a query for a pod outside the allowlisted namespaces returns nothing, not a partial read.

Soft scope vs. hard scope

opskit scope is enforced by the MCP server itself, which is stronger than a prompt instruction but still relies on OpsKit's own code path. For a pilot where the security team needs the guarantee to hold even if OpsKit had a bug, pair it with Kubernetes RBAC:

$ kubectl apply -f rbac/opskit-readonly-namespaced.yaml
# Role + RoleBinding per namespace, instead of the cluster-wide
# opskit-readonly.yaml

With the namespaced role applied, the service account OpsKit's connector authenticates as can't read outside the allowed namespaces at the API server — independent of whatever the MCP server's own scope config says.

Recommended pilot setup

• Start with opskit scope to the one or two namespaces you're piloting against
• Apply the namespaced RBAC role so the guarantee holds at the API server, not just in OpsKit
• See Kubernetes AI agent security for the hook layer that sits alongside this