AI Cyber Defense / Cloud, Kubernetes and software supply chain
AI Cyber Defense: Separate CI build permissions from deployment permissions
Use separate identities for build and release, restrict production approval to trusted contexts and avoid exposing secrets to untrusted pull-request code.
Environment and inputs: Cloud control planes, workload identity, Kubernetes clusters, CI/CD pipelines and immutable deployment artifacts; provider support varies.
Scenario and goal
A compromised build job can publish or deploy artifacts if it shares production credentials.
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
Map job identities, repository trust, artifact signing steps and environment deployment rights.
Validate with an authorized exercise
Run a harmless untrusted-branch fixture and confirm it cannot obtain deployment credentials; verify a reviewed release can deploy only the approved artifact to the intended test environment.
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.