Execution domain
Production deploys, cluster changes and agent-authored pull requests — a verdict before the step runs, bound to the exact artifact rather than to a standing permission.
CI, review and RBAC all pass before a bad change ships. None of them is asked whether shipping this artifact, now, by this actor, is authorized.
Did it build and pass?
Your pipeline proves the artifact is sound. It says nothing about whether shipping it is allowed.
Does a human approve the diff?
A reviewer approved the change at some point. The deploy can happen later, from a different commit.
Is this actor permitted?
Your cluster roles decide who may act at all — a standing permission, not a per-action decision.
Does this exact change have authority to execute, now?
A deterministic verdict against written policy, bound to the specific artifact digest, before admission.
The verdicts differ on purpose: a bound promotion is allowed, an RBAC escalation is refused, and an agent-authored change is held for a person.
deploy.productionA pipeline moves to promote a build to production. Review approved a commit; the artifact reaching the cluster is what actually runs.
Policy: Production promotion requires change approval and the exact artifact digest the approval was issued against.
kubectl applyA ClusterRoleBinding widens cluster-wide permissions, or a privileged pod is created in a production namespace.
Policy: RBAC escalation and privileged workloads in production require approval before the object is admitted.
pull_requestA coding agent opens a pull request that touches infrastructure. The reviewer sees a diff; nobody sees the blast radius until it merges.
Policy: A change authored by a non-human actor is evaluated on its own terms, whatever the diff looks like.
The GitHub Action evaluates the step before it runs. In shadow it comments the verdict and its verify link on the pull request without failing the build; you flip to enforce once the verdicts have earned it.
The Action Gate on GitHub MarketplaceA validating admission webhook, self-hosted via Helm, asks whether the exact operation is authorized now. ALLOW admits on a consumed single-use grant; HOLD and BLOCK deny with the Decision Dossier reference in the response. It starts shadow-first.
The Kubernetes admission gateShadow is fail-open by definition, and the enforcement fail mode is yours to choose. A hostile cluster-admin can remove the admission configuration: the default rules deliberately do not intercept admissionregistration resources, so an unavailable webhook can never block its own removal.
Read the threat model