Agent's Kubernetes account has cluster-admin
CriticalAV-PERM-008PermissionsCore packNew in 2.0
What it finds
A Kubernetes service account is bound to the cluster-admin role.
Why it matters
cluster-admin can do anything in the cluster. If the agent running under it is manipulated, it can read every secret and change every workload.
What an attacker could do: Full control of the Kubernetes cluster.
How to fix it
Bind the agent's service account to a namespaced Role with only the verbs and resources it uses.
Pro shows the corrected code for your exact file, step by step, and re-scans to confirm the fix. See plans
Check details
- Finding code
- K8S_AGENT_CLUSTER_ADMIN
- How it detects
- Looks for a specific risky pattern in the code or config.
- Confidence
- Definite: the risky setting is written plainly in the file.
- Scans
- Any text-based agent source or configuration (JS/TS/Python/JSON/YAML)
- OWASP LLM Top 10
- LLM08 - Excessive Agency
- NIST AI RMF
- GV-4.1
- SOC 2
- CC6.1, CC6.3
Check your agent for this
Paste your agent code or MCP config. The free scan runs all 124 checks in about 10 seconds — no account needed.
Related checks
- Overly broad cloud IAM permissionsAV-PERM-003 · Critical
- AI workflow checks out untrusted PR code with secretsAV-PERM-007 · Critical
- No permission or tool scope declaredAV-PERM-001 · High
- Unscoped delegation detectedAV-PERM-002 · High
- LangChain SQL agent with unrestricted database accessAV-FW-002 · High
- Retrieval with no per-customer filterAV-DATA-007 · High