Command Engine Binaries

The 21 binaries the compiled safety profile permits through runtime command run, what each authenticates against, and what the shipped rules deny.

This is not a native provider. gcloud, kubectl and terraform are reachable through Runtime as Command Engine binaries: Runtime does not own their context or credentials. Each tool keeps its native configuration; Runtime observes one effective snapshot at execution and never asks you to copy either into Runtime Home or the Control Plane. Prefer a provider operation when one exists (files, github). There is no AWS provider — command run aws is refused as unsupported context, and an assistant must report that gap rather than bypass Runtime.

The roster

Every tool is registered context-aware (an adapter observes the tool's own state to say where an operation lands), context-free (its operations carry their own coordinates), or unsupported (Runtime cannot say where the operation would land, so it refuses). There is no fourth "allowed but unknown" class — see where an operation lands.

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

Native CLI admission is semantic, not binary-wide

gh repo list is admitted because Runtime can bind its explicit owner or authenticated account/host and isolate it from the caller's repository. Other gh modes remain refused until separately reviewed. AWS and Azure are still refused because Runtime cannot yet bind the account/subscription their native credential state selects.

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

The admitted gh.repo.list examples and auth/output contract live in github_commands.txt alongside provider operations.

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.

Two things an allowed_binaries entry does not give you, deliberately:

• A context mode. A tool with no registered mode is unsupported and will be refused with a message saying so. Registering one is a change in the runtime source, so the set of tools whose target Runtime can vouch for stays small and reviewable.
• Environment variables. Your tool receives the reviewed baseline and nothing else unless the runtime carries a contract naming what it may have. Adding a name to command_policy.rules.<binary>.environment narrows that contract; it cannot widen it. If your internal CLI needs a variable, that is a runtime change too.

Both are the same rule from two directions: what a tool may reach is a review decision, not a configuration one.

Operational examples on this site were verified against Runtime 0.9.8. After bootstrap, the version-exact files in Runtime Home win.