Chapter 6 · Policy, Approvals, and Execution Safety as Code

Giving an agent more autonomy is a promise to your organization. Policy as code is how you keep that promise when nobody is watching. This chapter gives you four things to build or demand from a vendor: a risk classification for agent actions, approvals that resist fatigue, execution safeguards, and an audit record anyone can replay.

6.1 Classify actions on two axes

Every control later in this chapter depends on classifying actions well. Two questions do the work:

Reversibility. Can the change be undone cleanly, and how fast?
Blast radius. How much of your estate can it touch, and which tiers of it?

Classify action classes, not single commands. “Restart a stateless pod” is a class with known properties, and policy refers to the class. Where you can, derive the class by machine: a skill or tool that declares its access type, reversibility, and scope (see Chapter 3) classifies itself, so nobody has to remember that a script is dangerous.

	Reversible	Hard or slow to reverse
Narrow blast radius	Automate first. Restarts, cache clears, replica scaling, certificate rotation.	Ask a person, even when small. Data deletions, credential revocations.
Wide blast radius	Ask a person, then roll out in stages. Traffic shifts, config rollouts with checks between stages.	Human-owned, senior approval. Schema migrations, failovers, security-group changes on critical systems.

Use the matrix as your starting policy: fill each cell with your own action classes before you connect an agent to production.

Write the policy down as code

Policy binds the matrix to your real estate. For each action class it answers: which agent, in which environment, during which change window, under which preconditions, and with which approvers. Keep that policy as versioned configuration that changes through pull requests with named owners. A policy diff is an autonomy decision, so review it like a production change. Here is a generic sketch (not a CloudThinker file format) of one action class:

# Generic policy sketch, not a product format
action_class: rollback_recent_deploy
preconditions: [deploy_age < 60m, slo_breach_active, rollback_plan_attached]
environments:
  staging:    { decision: allow, notify: "#ops-incidents" }
  production: { decision: ask_first, approvers: [sre-senior] }
limits: { max_per_hour: 2, halt_on: repeated_failure }

Read it top to bottom: the agent may roll back only a deploy younger than an hour, during an active SLO breach, with a rollback plan attached. Staging runs without asking. Production waits for a senior SRE. Two rollbacks an hour is the ceiling, and a repeated failure stops the class.

6.2 Design approvals people actually read

Approvals are a human-factors system, and they fail in a known direction: fatigue, then rubber-stamping. Once that happens the gate is theater, and the audit trail records consent that never really happened. A working heuristic: when people accept more than about 95% of a class unchanged, let that class run without asking. When they accept less than about 70%, fix the agent or the policy before you widen anything. Wait for at least 30 decisions on a class before you trust either number, since three approvals out of three proves nothing. High acceptance only means “ready” when people actually read the request. High acceptance with near-zero review time is fatigue, not readiness (Chapter 11, failure mode 7). Four practices make the heuristic usable:

Practice	What it means in practice
One screen, full context	The request shows the finding, the evidence, the exact plan (a diff or plan output, not prose), the blast radius, the rollback, and the check that will follow. If an approver has to go digging, the design failed.
Make rejection informative	Capture why a request was declined: wrong diagnosis, right diagnosis but wrong fix, bad timing, or a policy exception. That reason feeds policy tuning and evaluation (Chapter 7). Ask for it at the moment of rejection, or lose it.
Identity and quorum are policy	Risky classes can require a named group or a second person. Approvals authenticate as the person, not the chat channel, and land in the audit trail as events.
Measure the gate	Track approval latency, acceptance rate, and how often people edit the plan, per class. Those numbers are your evidence for loosening a class, and they show fatigue before it turns into rubber-stamping.

Review approval numbers per action class every few weeks. A class with high acceptance and long approval latency is the clearest candidate to automate: people agree with it, and waiting for them costs you time.

6.3 Execution safety between “approved” and “done”

Hold agent changes to a higher bar than the average human change. Five mechanisms get you there:

Pre-flight checks. Recheck preconditions when the action runs, not when it was planned, because the world moves in between. Scope assertions such as “affects 5 resources or fewer, none tagged critical” fail closed.
Staged rollout with checks between stages. Wide changes go out in slices, with the verification loop from Chapter 1 between slices. Stage the rollback before slice one.
Circuit breakers and rate limits. An agent repeating a failing action, or a fleet above its change-rate ceiling, halts and escalates. Retry with backoff is for network calls, not for production changes.
Rollback as a deliverable. Every consequential action ships with an executable rollback attached at plan time, tested where you can. “We can probably reverse it” is not a rollback plan.
A kill switch. One action that stops all autonomous execution while investigation keeps running. Give it an owner, a drill schedule, and an audit event. Design it before the day you need it.

6.4 An audit record anyone can replay

Design the audit record so three readers can replay any action: the engineer the next morning, the auditor at quarter-end, and the regulator in your worst week. For each consequential action, record:

Field	Answers
Trigger and its source	What started this?
Context snapshot references	What did the agent know?
Reasoning summary with evidence pointers	Why did it choose this?
Policy evaluation	Which rules matched, and what did they decide?
Approval events	Who approved, when, and what did they see?
Execution log	Which tool calls ran, with which parameters (secrets masked) and results?
Verification outcome and any rollback	Did it work, and was it undone?

Make the record immutable and exportable, and keep it as long as your own retention policy requires. Done well, agentic operations produce better change evidence than most human processes, as a side effect of doing the work.

6.5 How this maps to CloudThinker

In CloudThinker, Approvals decides every write an agent makes through a connection. Reads always run. Each write passes four checks in order, and the first one with an answer decides, with one exception: under Manual, an Allow Rule doesn’t decide, and the write still goes to a person. CloudThinker turns on Rule enforcement one workspace at a time, and the Approval mode alone decides until it does.

Always blocked. A built-in list of calls that never run, such as stopping CloudTrail logging, closing an AWS account, or deleting the kube-system namespace. No Rule, no person, and no break-glass can override it. You can’t add to this list; to block more, accept a Deny Rule with Never allow break-glass on, which takes effect once enforcement reaches your workspace.
Rules. Each Rule names one kind of write, such as ec2:StopInstances on a staging account, and says Allow, Ask first, or Deny. Agents propose Rules as they work, and a proposed Rule does nothing until a workspace admin accepts it. While the Rules step shows In preview, even an accepted Rule only records what it would have decided, with enforcement still off.
Approval mode. Decides any write no Rule decided. Manual asks a person before every write that no Deny or Ask first Rule decided, including one an Allow Rule covers. Auto has four choices, named by their steps (see the table below). New workspaces start on Auto · Rules + AI · Ask me. Automations default to Auto · Rules + AI · Refuse, since no one may be there to answer.
Approvers. Default approvers or a named group, an optional two-person rule, and break-glass, which is off until an admin turns it on and needs a written reason each time.

Auto choice	AI judgment	A write still not allowed
Auto · Rules · Ask me	Off	Waits for a person
Auto · Rules · Refuse	Off	Is refused
Auto · Rules + AI · Ask me	On	Waits for a person
Auto · Rules + AI · Refuse	On	Is refused

AI judgment allows a write that matches what you asked for and stays in its scope. A destructive write, or one with an unclear effect, goes to the last column. To see what AI judgment decided, open Approvals → Activity: its No Rule matched row counts the writes the Approval mode decided, including AI judgment. Each idea in this chapter has a concrete home:

Chapter idea	Where it lives in CloudThinker
Action classes and the two-axis matrix	Rules, one per kind of write, scoped to a connection
Policy as reviewed code	Export active Rules (in the More Rule actions menu on the Rules tab) downloads your Rules, approver groups, and Approval modes as YAML. Import policy in the same menu applies a reviewed file back.
Review a policy diff before it ships	When you review a proposed Rule or edit one, a preview replays the last 7 or 30 days of calls and shows which would have run, asked first, or been refused
Quorum and identity	Approver groups and the two-person rule on the Approvers tab
Measure the gate	The Activity tab shows what each Rule decided in a period, with CSV export
Reviewed procedures for known fixes	Resolve runbooks. A command in a runbook that changes something is still a write, so your Rules and Approval mode decide it.
Pre-flight checks (6.3)	Not a Rule setting. A Rule scopes one kind of write to a connection, which bounds what can run. Optimize actions open a conversation that first checks the finding is still valid. Put other prechecks in your runbooks.
Staged rollout (6.3)	Not built in. Roll wide changes out in your own pipeline. Once enforcement is on, put an Ask first Rule on the write that starts each stage; until then, keep that run type on Manual.
Circuit breakers and rate limits (6.3)	Not built in: a Rule has no per-hour cap. Use Ask first on any class where a repeat would hurt.
Rollback as a deliverable (6.3)	Not enforced by the product. Ask for the rollback in the runbook or in the request, and decline approvals that lack one.
Kill switch (6.3)	No single halt-all switch. The control that works today is Allow writes: turn it off on a connection and every change on that connection is refused. Setting each run type to Manual sends its writes to a person, but that alone isn’t a halt, because a chat can pick its own mode in the composer. Turn off On duty in Resolve to stop automatic investigations, and switch off an automation’s triggers to stop its runs. Once CloudThinker turns on Rule enforcement for your workspace, Rules add a broader halt. A Deny Rule for every operation, on every connection, with Never allow break-glass on, refuses every agent write in every mode while reads keep running.
Replayable audit record	Audit Logs, on the Scale, Scale Plus, and Enterprise plans, for organization Owners and Admins. Nobody can edit or delete an event from the app. Events are kept 90 days, so export to CSV if you need them longer. On other plans, use Approvals → Activity and its CSV export, which show what each Rule decided and who approved.

Apply it in your workspace

Anyone in the workspace can view Approvals. To accept Rules or change modes and approvers, you need the workspace Admin role (organization Owners and Admins have it in every workspace).

Open Approvals

Open Approvals in the sidebar. If it isn’t there, click More and select Approvals. The page opens on the Overview tab.Success state: you see what needs you and how many calls ran, asked a person, or were refused in the last 7 days.

Fill your matrix with Rules

On the Rules tab, review the Rules agents proposed. No proposals yet? Click Find rules. The check-up takes 5 to 10 minutes, uses credits, and proposes Rules from your connections, findings, incidents, alerts, and approval history. Accept the ones that match your matrix from 6.1. If it proposes nothing you want, click Add from template or write a Rule in the form (Rules).Success state: each accepted Rule shows Allow, Ask first, or Deny, and nothing changed before you accepted it.

Choose an Approval mode

On the Approval mode tab, set Workspace mode. Auto · Rules + AI · Ask me suits most teams. For a production workspace where only accepted Rules should run writes alone, pick Auto · Rules · Ask me or Manual. Under Run types, click Override to give one run type, such as Automations, its own mode.Success state: the picker shows your choice, and each run type row shows Same as workspace or its override.

Set who approves

On the Approvers tab, click Edit on Default approvers and add the people who should answer most asks. Click New group for a team that owns one system, and name that group in each Ask first Rule for its systems; those Rules route asks once enforcement is on. Turn on the two-person rule for production, so nobody approves their own run’s write. Leave break-glass off until you have an emergency procedure for it.Success state: the Who approves card on Overview shows how many default approvers you have and whether the two-person rule is on.

Put the policy under review

On the Rules tab, open the More Rule actions menu, click Export active Rules, and commit the YAML file to a repository with named owners. After a pull request merges, open the same menu, click Import policy, and load the merged file. Import shows what would change before you apply it. It merges by default: Rules in the file are added or updated, and Rules missing from the file stay unless you select Remove Rules that are not in the file. Imported Allow Rules wait for review unless you turn on Activate Allow Rules. An accepted Rule decides a write only once CloudThinker turns on Rule enforcement for your workspace; until then set the mode to Manual for the writes that must wait for a person.Success state: the workspace matches the reviewed file in Git.

Git doesn’t lock the workspace. An admin can still accept or edit a Rule in the app, and that change skips your pull request. Keep the workspace Admin role to the few people who own the policy, and export again after any change made in the app so Git stays current.

KEY TAKEAWAYAutonomy is governable when it is written down and enforced. Classify actions by reversibility and blast radius, keep the policy as reviewed code, design approvals against fatigue and measure them, wrap execution in pre-flight checks, staged rollout, circuit breakers, and a ready rollback, and record every action so anyone can replay it.

Learn

Workshops

Scenarios

Chapter 6 · Policy, Approvals, and Execution Safety as Code

6.1 Classify actions on two axes

Write the policy down as code

6.2 Design approvals people actually read

6.3 Execution safety between “approved” and “done”

6.4 An audit record anyone can replay

6.5 How this maps to CloudThinker

Apply it in your workspace

Next steps

Chapter 7 · Evaluating Agents Like Production Systems

Set up Approvals

​6.1 Classify actions on two axes

​Write the policy down as code

​6.2 Design approvals people actually read

​6.3 Execution safety between “approved” and “done”

​6.4 An audit record anyone can replay

​6.5 How this maps to CloudThinker

​Apply it in your workspace

​Next steps

Chapter 7 · Evaluating Agents Like Production Systems

Set up Approvals

6.1 Classify actions on two axes

Write the policy down as code

6.2 Design approvals people actually read

6.3 Execution safety between “approved” and “done”

6.4 An audit record anyone can replay

6.5 How this maps to CloudThinker

Apply it in your workspace

Next steps