Command Engine Binaries

The 21 binaries the seeded policy permits through runtime command run, what each authenticates against, and what the shipped rules deny.

This is the escape hatch for tools no provider covers. Prefer a provider operation when one exists.

The roster

Binary	Auth provider	Context injection	Denied by default
gh	github	—	—
git	—	—	push --force, push -f, reset --hard, clean -fd, filter-branch, update-ref -d
terraform	—	—	destroy
pulumi	—	—	destroy
packer	—	—	—
gcloud	gcp	--project=	projects delete, iam service-accounts delete
gsutil	gcp	—	rm -r, rb
bq	gcp	—	rm -f, rm -r -f, rm -f -r
aws	—	—	s3 rb --force, ec2 terminate-instances, iam delete-user, rds delete-db-instance
az	—	—	vm delete, group delete, ad user delete, keyvault delete
kubectl	kubernetes	-n <namespace>	delete namespace
oc	openshift	-n <namespace>	delete project
helm	kubernetes	—	uninstall
flux	kubernetes	—	delete, uninstall
istioctl	kubernetes	—	uninstall
kustomize	—	—	—
argocd	—	—	app delete, cluster rm, repo rm
docker	—	—	system prune -a, volume rm, network rm, run --privileged
podman	—	—	system prune -a, volume rm, run --privileged
vault	—	—	kv delete, kv metadata delete, secrets disable
sops	—	—	—

This is the release default, not necessarily your policy

policy-config.yaml is user-owned and never overwritten by an upgrade, so an older install may allow fewer binaries than this table.

runtime config validate      # what your active policy actually allows,
                             # plus an installed check per binary

See the upgrade trap.

Hard-denied, always

command_policy:
  denied_binaries: [rm, sudo, chmod, curl, wget, ssh]

Refused independently of allowed_binaries — adding one to the allow-list does not un-deny it.

Cheatsheets

One per binary, in your Runtime Home, refreshed with every version:

ls ~/.engineering-runtime/commands/
cat ~/.engineering-runtime/commands/terraform_commands.txt
cat ~/.engineering-runtime/commands/kubectl_commands.txt

gh's raw command run gh examples live in github_commands.txt alongside the provider operations, rather than in a separate file.

Notes by group

Version control

git is unmapped for auth: the Command Engine does not inject RUNTIME_GITHUB_TOKEN into bare git. Configure git credentials yourself before a capability pushes:

runtime command run git clone https://github.com/owner/repo.git
runtime command run git status
runtime command run git commit -m "message"

Reads, commits and ordinary pushes are allowed; irreversible history operations are refused. Because denial rules match anywhere in the command, a leading global flag does not help:

runtime command run git -C /tmp/wd push --force    # denied

Infrastructure as code

terraform and pulumi resolve credentials through their own provider configuration, so neither maps to an Auth Engine provider. Both deny destroy.

packer carries no denial rule — it only builds new machine images and has no subcommand that destroys existing infrastructure.

GCP

gcloud, gsutil and bq all map to gcp — the same SDK and the same Application Default Credentials. Only gcloud receives context injection.

bq's rules deny rm -f in both flag orders because -r (recursive, for a whole dataset) can precede -f, and -f is what skips the confirmation prompt that would otherwise protect you.

AWS and Azure

Both are on the allow-list but unmapped — there is no AWS or Azure Auth Engine provider yet. They run with whatever credentials their own credential chain resolves. Denial rules target credential/account loss and bulk data deletion; ordinary describe/list/get calls are unaffected.

Kubernetes and GitOps

kubectl, oc, helm, flux and istioctl all authenticate against the kubernetes provider (or openshift for oc), because they read the same active kubeconfig context — validated by reading the file directly, with no CLI dependency.

Only kubectl and oc receive -n <namespace> injection. helm, flux and istioctl accept -n in practice but have no injection case — pass it yourself.

helm uninstall and istioctl uninstall are denied outright, on the same reasoning as terraform destroy: they tear down a whole release or the mesh control plane.

kustomize has no denial rules and no auth mapping — it only renders YAML to stdout and never talks to a cluster or a registry.

argocd is unmapped pending an Argo CD auth provider. Its rules deny removal of apps, clusters and repos; sync, diff, get and ordinary app management are unaffected.

Containers

docker and podman manage their own daemon and registry logins, and will not gain an auth provider mapping — run docker login yourself.

run --privileged is denied as a container-escape risk, not a deletion one — worth knowing, since the other rules in this file are all about irreversibility.

Secrets

vault is unmapped pending a Vault auth provider. Its rules refuse permanent secret and engine removal. Sealing and unsealing are deliberately not denied — they are availability, not data loss, and are already gated by Vault's own ACLs.

sops encrypts and decrypts files in place using its own KMS/PGP/age keys. It has no delete concept, so no denial rule. Note that confidentiality of decrypted output is a different concern from the irreversible-action governance these rules provide.

Deliberately excluded

ansible and ansible-playbook are not on the allow-list.

Their ad-hoc and playbook modules (ansible all -m shell -a '<opaque payload>') are arbitrary remote command execution — the same risk category as ssh, which is refused outright. The dangerous part is an opaque payload argument, not a recognizable subcommand, so a denied: rule cannot cap it the way terraform destroy can be capped.

Revisit deliberately if a real need arises; don't add it by the same pattern as everything else on the list.

Adding a binary

allowed_binaries:
  - my-internal-cli

command_policy:
  rules:
    my-internal-cli:
      denied:
        - teardown

runtime config validate      # confirms the binary is installed and the rule can match
runtime command run my-internal-cli --version

If it needs an Auth Engine provider, map it in config.yaml's command_providers. Leaving it unmapped is a valid declaration that the tool manages its own credentials.

Adding a binary does not grant it Runtime Context injection — that requires a change in the runtime source, deliberately, so the injection surface stays small and auditable.