agent-k8s-harden-check: Kubernetes Agent Workload Hardening Checker

Read local Kubernetes YAML and flag AI-agent workloads that are missing isolation. One Python script. PyYAML is the only dependency.

Use it on manifests you own or are explicitly allowed to review.

Why it matters

Agent workloads often run with a tool that can open HTTP connections. Three public write-ups are the reason this checker exists:

• Zenity AgentCorruption describes an agent HTTP tool that could reach the instance metadata service.
• Anthropic's report on unintended model actions describes agent actions the product limits did not contain.
• The agent-sandbox secure-by-default ValidatingAdmissionPolicy describes the isolation Kubernetes SIG Apps publishes for Sandbox workloads: a gVisor runtime class, no service-account token, no privileged or root process, no host namespaces, and a NetworkPolicy that blocks RFC1918 and cloud-metadata egress.

Those are links to the public pages. This repository does not restate procedures from them. It reads the YAML you already have and tells you which of those controls are missing from the text.

Quickstart

Requires Python 3.9 or newer.

pip install agent-k8s-harden-check

To match CI exactly:

pip install -r requirements.txt

requirements.txt pins PyYAML. The script imports that package and the standard library only.

From this directory, the script and the installed command take the same path:

python3 agent_k8s_harden_check.py examples/bad-agent-pod.yaml
agent-k8s-harden-check examples/bad-agent-pod.yaml

python3 agent_k8s_harden_check.py examples/good-agent-pod.yaml examples/egress-networkpolicy.yaml
agent-k8s-harden-check examples/good-agent-pod.yaml examples/egress-networkpolicy.yaml

python3 agent_k8s_harden_check.py examples --json
agent-k8s-harden-check examples --json

PATH is a YAML file, or a directory. A directory is scanned for .yaml and .yml files. Hidden directories are skipped. Multi-document YAML is read. The examples are fictional and are there for a local offline check.

examples/bad-agent-pod.yaml is a pod with no runtime class, a service-account token automount, a privileged root container, host networking, and no limits. That run exits 1:

Kubernetes agent workload hardening check

examples/bad-agent-pod.yaml
  FAIL  runtime-class                         Pod/fictional-unisolated-agent  ns=agent-lab
        runtimeClassName is not set
  FAIL  automount-service-account-token       Pod/fictional-unisolated-agent  ns=agent-lab
        pod automountServiceAccountToken is true
  PASS  projected-service-account-token       Pod/fictional-unisolated-agent  ns=agent-lab
        no projected volume mounts a serviceAccountToken
  FAIL  privileged                            Pod/fictional-unisolated-agent  ns=agent-lab
        privileged is true on container agent
  FAIL  run-as-non-root                       Pod/fictional-unisolated-agent  ns=agent-lab
        root is set: container agent (runAsUser is 0)
  FAIL  host-namespaces                       Pod/fictional-unisolated-agent  ns=agent-lab
        host namespace enabled: hostNetwork
  WARN  resource-limits                       Pod/fictional-unisolated-agent  ns=agent-lab
        cpu or memory limits are missing: container agent (cpu, memory)
  WARN  egress-metadata-rfc1918               Pod/fictional-unisolated-agent  ns=agent-lab
        no NetworkPolicy with policyTypes Egress was found for namespace agent-lab. Manifest text only; this does not show the cluster enforces it.

summary: pass=1 warn=2 fail=5 errors=0
A pass is a reading of the local YAML. It is not cluster enforcement.

examples/good-agent-pod.yaml sets runtimeClassName: gvisor, turns automount off, runs as a non-root user, and sets cpu and memory limits. Scanned on its own, the egress check warns, because no NetworkPolicy was in that file. Exit 0. Pass the egress example on the same command line and that warning clears. Exit stays 0.

--json prints the same findings as JSON.

What it checks

The script reads these kinds: Pod, Deployment, StatefulSet, DaemonSet, Job, CronJob, ReplicaSet, NetworkPolicy, plus Sandbox and SandboxTemplate. A document whose apiVersion contains agent-sandbox is read as a workload too. For Deployments and the other owners, the pod spec is spec.template.spec. For a CronJob it is spec.jobTemplate.spec.template.spec. For Sandbox and SandboxTemplate it is spec.podTemplate.spec (or spec.template.spec when that is where the fields are).

The egress check looks for policyTypes containing Egress. Empty egress is read as default-deny text. An allow rule passes this check only when the four destinations above are outside the allow, including when they appear in an except list. Policies in one namespace are unioned, because Kubernetes unions allows. A pod or namespace selector is unclear for the RFC1918 ranges, since those selectors name pods rather than CIDRs. A podSelector with matchLabels is applied only when those labels are on the pod, or on the pod template. If the selector is not a clear match, that policy is not counted as coverage.

A pass on the egress check means those four destinations were excluded or omitted in the files you scanned. Other destinations may still be allowed. An empty egress list is the case where the text allows no destinations.

Every egress line says the same thing in prose: this is a reading of manifest text. It is not evidence that a cluster enforces the policy.

What it does

It parses the files you name, prints a pass / warn / fail line per object and check, and returns the exit code below. --json prints summary, findings, and errors.

What it does not do

• It does not connect to a cluster, run kubectl, or apply, create, or edit a resource.
• It does not decide that a cluster is safe. A clean file can still be absent from the cluster, and a failing file can describe a workload you have not deployed.
• It does not review admissions controllers, runtime installation, or identity systems that are not in the YAML you passed.
• It does not follow Helm or Kustomize. Give it rendered YAML.
• It does not treat a warning as success-of-the-control. Warnings are gaps the text did not settle. They do not fail the process exit code.

Authorized use

This repository is MIT licensed. It is for defensive checks only.

• Review manifests you own or are authorized to assess.
• Keep the examples as local fixtures. They are fictional and are not a deployment guide.
• Do not point the script at files you are not allowed to read.

Exit codes

Tests

From this directory, with PyYAML installed:

python3 -m unittest discover -s tests -v

The workflow in .github/workflows/test.yml installs requirements.txt and runs that command. It does not contact a cluster.

Examples

For more from Digital Fortress

This checker reads a handful of fields in local YAML. The paid packs are the longer review set: prompts, templates, and checklists for the same kinds of systems.

For more from Digital Fortress:

• $99 Agent Runtime Containment Pack, the pack closest to this script: agent egress, identity, Kubernetes sandboxing, and tool-call authorization.
• $99 AI Security & Infrastructure Prompt Pack
• $79 MCP & Multi-Agent Authorization Security Pack
• $149 Multi-Agent Orchestration Blueprint

Free siblings:

• AI Security Starter Checklist
• MCP Tool Definition Pinning Checker

Sources

• Zenity AgentCorruption
• Anthropic: Investigating unintended model actions
• agent-sandbox: Secure Sandbox Admission Policy

License

MIT © 2026 Digital Fortress · github.com/digitalfortressaudit. Authorized defensive use only, as described above.