Skip to main content
The execution policy is the contract that bounds what Auto may authorize in one environment. It is deny-by-default in every dimension: a new environment has no policy, and an empty or incomplete policy means nothing auto-executes, even with the mode set to Auto. Everything outside the policy waits for a human, exactly as in Advise. You edit it per environment, beside the Mode toggle, in Connected environments or the environment panel on Changes → Remediations. The editor always shows a plain-language summary of the net effect, for example:
Auto may apply manifest patches in production, payments at high+ confidence, up to 5/hour.
or, when the policy is incomplete:
Nothing auto-executes — Auto requires a complete policy (namespaces, fix types, confidence floor, hourly cap).

​
Policy dimensions

​
Identity and versioning

Every explicit policy has an id and a version. A Permit issued under Auto cites both — together with the scope and the rule that matched — so every record can say exactly which policy decided. The tenant-wide fallback that predates per-environment policies has no identity and therefore can never authorize anything automatically.

​
When the policy is evaluated

The policy is not a one-time gate. It is enforced when a change is proposed and re-derived at consume, the moment the Executor is about to act:
  1. At proposal. When analysis completes in an Auto environment, ChangeGuard checks every dimension before authorizing the change under agent-policy and issuing a Permit. Anything outside the policy becomes Awaiting approval for a human instead.
  2. At consume. Before the Executor may act, ChangeGuard re-checks that the environment is still in Auto under the same policy id and version. If not, consume is refused and the Permit is revoked (policy_changed).
Editing a policy — broader or narrower, or changing the mode — bumps the version and revokes every Permit issued under the old one. A change already consumed is past the commit point and completes under the authority it had. A change not yet consumed returns to a human. Nothing is ever re-authorized silently under the new version: Auto authority is decided when a change is proposed, so a change proposed after the edit is authorized by, and cites, the new version.

​
Interaction with hard safety limits

The policy is an envelope inside platform-level guarantees you cannot accidentally disable:
  • Every manifest patch is validated server-side against a field allowlist of safe operational fields (resource limits and requests, replicas, environment variables, probe tuning, and similar). Patches touching identity or metadata are rejected outright, whatever the policy says.
  • The Executor’s own identity is namespace-scoped by the RoleBindings you applied, so even a maximally permissive policy cannot reach namespaces you never granted. See Execution authority and least privilege.
  • Only one remediation per workload is in flight at a time; a second apply is refused.
  • Every automatic authorization still becomes a single-use, expiring Permit, consumed once.
Treat the namespace allowlist as your primary blast-radius control and start narrow: one non-critical namespace, high confidence, a low hourly cap. Widen it only after you have watched the audit trail for a while and trust what you see.