AI Cyber Defense / Cloud, Kubernetes and software supply chain
AI Cyber Defense: Verify network policy enforcement in the actual CNI
Start with explicit workload dependencies and apply supported default-deny intent in a staged namespace. Include DNS, control-plane and approved external dependencies.
Environment and inputs: Cloud control planes, workload identity, Kubernetes clusters, CI/CD pipelines and immutable deployment artifacts; provider support varies.
Scenario and goal
A policy object can exist without providing the intended traffic isolation if enforcement or rule semantics differ.
Why it matters
For this scenario, an attacker can automate permitted API operations after gaining a workload or pipeline identity. Review who can change trust, who can assume the resulting identity and what resources it can reach. Keep source review, build provenance, deployment authorization and runtime permissions as distinct checks. A configuration object or successful deployment does not prove the intended runtime boundary is enforced.
Evidence to collect
Record CNI capabilities, selected pods, labels, policy objects and observed ingress and egress results.
Validate with an authorized exercise
Run approved pod-to-pod and egress checks in a test namespace; confirm expected denies at runtime rather than accepting successful policy creation as proof.
Rollout and checks
Evaluate effective permissions and runtime behavior in a disposable account or namespace before production rollout. Retain the approved source revision, resulting artifact and independent audit trail. Plan recovery if identity, policy or admission dependencies fail. Reconcile running assets after the change because resources created outside the normal pipeline can otherwise remain outside its checks.
Scope and limits
This guide proposes a defensive test; it is not a tested production design. Check platform support and local requirements. References explain the mechanisms but do not certify the design. Behavior alone does not prove AI involvement.