An agent asked to “audit the cluster for security” ran 9 different security checks across 7 parallel Kubernetes API calls — pods, services, secrets, RBAC roles, RBAC bindings, network policies, and nodes — all in a singleDocumentation Index
Fetch the complete documentation index at: https://docs.cnap.tech/llms.txt
Use this file to discover all available pages before exploring further.
execute call.
What It Checks
| Check | What it looks for |
|---|---|
| Pod security context | Privileged containers, running as root, privilege escalation, writable root filesystem, capabilities not dropped |
| Image tags | Containers using :latest instead of pinned tags |
| Resource limits | Missing requests or limits |
| Exposed services | NodePort or LoadBalancer services directly accessible |
| RBAC — cluster-admin | Non-system bindings to the cluster-admin role |
| RBAC — wildcards | Roles with * on resources, verbs, or API groups |
| Network policies | Namespaces with no network policies (unrestricted pod-to-pod traffic) |
| Host namespaces | Pods using hostNetwork, hostPID, or hostIPC |
| Service account tokens | Non-system pods with automounted service account tokens |
The Code
Why This Matters
A traditional approach would require the agent to make 7+ sequential tool calls just to fetch the data, then somehow reason about all the raw JSON in its context window. The context would be flooded with every pod spec, every RBAC rule, every service definition. Code Mode runs all 7 fetches in parallel and does the analysis inside the sandbox. The agent wrote the security checks — privileged containers, missing capabilities, writable filesystems, RBAC wildcards, network policy gaps — as JavaScript logic. The LLM receives a structured findings report, not raw Kubernetes API responses.What the Agent Does
- Fires 7 Kubernetes API calls in parallel (
Promise.all) - Audits every container’s security context (8 checks per container)
- Identifies overly permissive RBAC bindings and wildcard roles
- Finds namespaces with no network policies
- Flags pods using host namespaces or automounted service account tokens
- Collects node runtime info for version auditing
- Returns a structured report with findings grouped by severity
From Audit to Remediation
The agent doesn’t just report findings — it can fix them. After the audit flagged zero network policies across all namespaces, a follow-up “create network policies for my installs” produced two moreexecute calls:
Step 1 — Discovery: fetched services and pods from each install namespace in parallel to learn which ports each app needs.
Step 2 — Apply policies: created 3 network policies per namespace using POST through the kube proxy:
201 Created:
| Install | default-deny-all | allow-dns | allow-app-ingress |
|---|---|---|---|
| cloudflare-gateway | ✓ | ✓ | — (no ports) |
| openclaw2 | ✓ | ✓ | ✓ (TCP 18789) |
| httpbin | ✓ | ✓ | ✓ (TCP 8000) |
| openclaw | ✓ | ✓ | ✓ (TCP 18789) |