Advise and Auto

ChangeGuard is autonomous-capable by design and human-controlled by default. How much authority it has is decided per environment, never account-wide, and in one of two modes: Either way, authority becomes a ChangeGuard Permit bound to the exact action, and an Executor carries out only the permitted action. Judgment never authorizes; a verdict of SHIP is a belief, not a grant.

​

Where you set it

Open the environment in Connected environments (or the environment panel at the top of Changes → Remediations). The Mode toggle reads Advise or Auto; the policy editor sits beside it. An environment with no explicit setting is Advise.

​

Advise — the default

When ChangeGuard proposes a fix, the change appears as Awaiting approval with Approve and Reject. Approving records your identity and binds the canonical hash of the exact action; ChangeGuard then issues a Permit and the Executor applies the fix. The record keeps proposed by changeguard-agent · approved by ‹you› permanently, together with the Permit and its outcome. Rejecting keeps the record too, with the reason. A fix that is applied is verified against fresh evidence before it is called successful; a fix that fails verification is handed back to a human. Nothing in Advise executes on ChangeGuard’s say-so.

​

Auto — bounded by policy, falling back to Advise

In Auto, ChangeGuard may authorize its own proposal — but only when all of the following hold:

1. the environment’s mode is Auto and its policy is complete: namespaces, fix types, a confidence floor and an hourly cap, each non-empty;
2. the proposal is inside every dimension — the target namespace is allowed, the fix type is allowed (manifest patches only; code fixes are never auto-executed), the analysis confidence meets the floor, and the hourly cap has headroom;
3. the action passes the same server-side allowlist as every other change.

Anything outside the policy is created as Awaiting approval for a human, exactly as in Advise. An empty or default policy fails closed: nothing auto-executes, and the product says so. A fix authorized by policy records approved by agent-policy and the policy id and version that authorized it, so history always says who decided. The policy is re-derived at the moment of execution, not just at proposal time: editing a policy bumps its version and revokes every Permit issued under the old one. A change already consumed completes under the authority it had; a change not yet consumed returns to a human. It is never re-authorized silently under the new version.

​

Either way

• Every applied fix is verified against fresh evidence of the environment before it is called successful. No observation, no VERIFIED.
• A failed fix is handed to a human. A compensating action needs its own authority and its own Permit.
• Every record keeps the mode at execution, the approver or policy version, and the Permit — permanently.
• Nothing in the loop can move the mode, widen the policy or approve on your behalf. Lowering authority is always safe: it can only reduce what happens next.