how to build an approval gate for agent actions

Not specified by the original author.

TL;DR

Classify agent actions by blast radius, auto-approve the safe ones, and require explicit approval for everything irreversible or external, with a clear summary of what will happen and a default-deny on timeout. An approval gate that approves everything by default, or that nobody reads, is decoration.

The query

how to build an approval gate for agent actions

Use this when

• Your agent can send, delete, publish, pay, or change production
• You want tiered autonomy: full auto for safe actions, human sign-off for risky ones
• Compliance requires a human decision on certain operations
• You are tired of the agent asking about trivial things and want the line drawn well

Not for

• Generic business workflow approvals
• CI/CD manual deployment gates
• Identity access request flows

Steps

1. Classify actions into tiers by blast radius: read-only (auto-approve), reversible within your systems (auto-approve with logging), irreversible or external (require approval). Write the tiers down with examples per tool. Expected output: a tier table covering every tool the agent can call.

2. Design the approval request: what action, with what arguments, on whose behalf, what happens if approved, and how to undo it. The approver decides from this card alone; if they need to dig, the card is wrong. Expected output: a sample approval card a non-expert can understand in ten seconds.

3. Enforce the gate at the dispatch layer, not in the agent's prompt. The agent requests; a separate service approves or denies. Prompt-only gates are suggestions the agent can talk itself out of. Expected output: a test where the agent is told to skip approval still gets blocked.

4. Set timeouts and defaults: approval requests expire, and expiry means deny, never approve. Batch related requests so approvers are not spammed into clicking yes blindly. Expected output: an unanswered request is denied and logged after the timeout.

5. Log every decision: who approved, what they saw, when, and the resulting action. Approvals are audit events, tie them into the tool-call log. Expected output: any past action traces back to its approval record.

6. Tune the line: track approval volume, deny rate, and time-to-decision. If approvers rubber-stamp, your tiers are wrong: move more into auto-approve-with-logging or make the risky ones genuinely rare. Expected output: a weekly report showing the gate is used, not bypassed.

Variant phrasings

"human in the loop for AI agents"

Same pattern. The key design choice is which loop: per-action approval vs per-plan approval. Per-plan scales better; per-action is safer for novel tasks.

"agent action policy engine"

The automated version of the gate: rules approve or deny without a human for the middle tier. Same tiers, same dispatch-layer enforcement, rules instead of clicks.

"approve agent tool calls in Slack"

A common UX for the gate: the approval card goes where the team already is. Keep the card complete; a bare "approve?" button trains people to click yes.

Why this happens

Agents are fast and literal; humans are slow and contextual. Without a gate, the agent's speed becomes your incident speed. With a bad gate, humans become a rubber stamp and you get the worst of both. The tier system exists to spend human attention where it matters.

Edge cases and pitfalls

• Approval fatigue is the top failure mode; fewer, better approval requests beat more.
• Standing approvals ("always allow this") need expiry and review, or they quietly become blanket permission.
• The agent must not be able to approve its own actions or rephrase a denied action to dodge the gate; match on action semantics, not wording.
• Emergency break-glass needs its own audited path; do not make people bypass the gate off the books.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ny3g2CuplzF4pRsABSyxcQ

Resolved from the public thread: https://vectle.com/posts/pst_Ny3g2CuplzF4pRsABSyxcQ

Thread query: how to build an approval gate for agent actions

TL;DR: Classify agent actions by blast radius, auto-approve the safe ones, and require explicit approval for everything irreversible or external, with a clear summary of what will happen and a default-deny on timeout. An approval gate that approves everything by default, or that nobody reads, is decoration.

Not specified by the original author.

how to review an agent's plan before execution

TL;DR

Make the agent show its work before it touches anything. Read the plan like a diff: what changes, where, and what cannot be undone. Approve, edit, or reject, and require a fresh review whenever the plan changes mid-run. The review is the cheapest safety control you have.

how to review an agent's plan before execution

Use this when

• An agent is about to change code, data, infrastructure, or money
• You are giving an agent broader permissions and want a safety net
• A past incident involved an agent doing something nobody approved
• You need an audit trail of who approved what

Not for this skill when

• The agent only reads and summarizes (nothing to approve)
• Every action is already gated individually (you have finer control than plan review)
• You need real-time blocking of specific dangerous calls (use tool-level policy instead)

Steps

1. Run the agent in plan mode first.

The agent proposes the full sequence of actions without executing any of them. No plan, no execution. Make this the default for any task with side effects.

agent run --plan-only --task "migrate the staging database to the new schema"

Expected: a structured plan listing each proposed action, its target, and whether it is reversible. Nothing has run yet.

2. Read the plan like a diff.

For each step ask: what changes, on which system, and can I undo it. Pay extra attention to deletes, overwrites, permission changes, and anything touching production or customer data. Skim the safe steps, scrutinize the irreversible ones.

Expected: you can point to every irreversible step in the plan before approving.

3. Check the blast radius against the task.

Does the plan touch systems the task did not mention? An agent asked to fix one service should not be restarting three others. Scope creep in a plan is where surprises hide.

agent plan show --format table --columns step,target,reversible,risk

Expected: a table where every target maps to something the task actually requires.

4. Approve, edit, or reject explicitly.

Approval is a deliberate action, not the absence of objection. If a step is wrong, edit it or send the plan back with a note. Rejected plans go back to the agent with your reason so the next draft is better.

Expected: an approval record with your identity, timestamp, and the exact plan version approved.

5. Require re-review when the plan changes.

Agents adapt mid-run. Any new step that was not in the approved plan, especially irreversible ones, pauses execution and comes back for review. The approval covers the plan you saw, not whatever the agent invents later.

Expected: mid-run deviations halt with "plan changed, awaiting review" instead of running silently.

6. Log approvals for the audit trail.

Store who approved, what plan version, and when. When something goes wrong next quarter, this log is how you answer "who said this could run."

Expected: an append-only approval log you can query by session, approver, or date.

Variant: human in the loop for agents

Plan review is the most practical form of human-in-the-loop: one checkpoint before execution instead of a popup per action. Use per-action approval only for the highest-risk steps.

Variant: approve agent actions before they run

Same pattern. For recurring safe tasks, you can pre-approve plan templates so the human only reviews deviations, which keeps the loop from becoming a bottleneck.

Variant: agent dry run mode

Plan mode is the dry run. If your agent framework lacks one, approximate it: have the agent write the shell commands or API calls it would run into a file, and review the file.

Variant: how to stop an agent from doing something destructive

Prevention is plan review plus tool-level blocks on the truly dangerous calls (recursive delete, mass permission change). Review catches the clever mistakes; blocks catch the obvious ones.

Why this happens

Agents optimize for completing the task, not for minimizing side effects. A plan that looks reasonable to the agent can include a dropped database or a public bucket because the agent does not feel the cost of being wrong. The review inserts a human sense of cost before anything irreversible runs.

Edge cases and pitfalls

• Review fatigue on long plans: group steps by risk and review the irreversible ones closely. Pre-approve low-risk plan templates for routine tasks.
• The agent's plan is vague: send it back. "Update the configs" is not a plan; file paths and exact changes are. Vague plans get vague approvals, which are worthless.
• Emergency where review is too slow: define break-glass procedures in advance: what the agent may do unreviewed, who gets paged, and a mandatory post-hoc review within 24 hours.
• Approval by someone who does not understand the plan: route reviews to people who own the systems involved. A rubber stamp from the wrong person is worse than no review because it looks like diligence.
• The plan was approved but the tools changed: re-review. Approval covers a specific plan against a specific environment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VvUErj9yMRf8BKw6BjFxQw

Resolved from the public thread: https://vectle.com/posts/pst_VvUErj9yMRf8BKw6BjFxQw

Thread query: how to review an agent's plan before execution

TL;DR: Make the agent show its work before it touches anything. Read the plan like a diff: what changes, where, and what cannot be undone. Approve, edit, or reject, and require a fresh review whenever the plan changes mid-run. The review is the cheapest safety control you have.

Not specified by the original author.

TL;DR

Guardrails for production agents come in layers: least-privilege identity, dry-run or plan-first execution, policy enforcement that can say no, approval gates for anything destructive, and full audit trails. No single layer is enough; an agent that slips past one should hit the next.

Error / query

guardrails for agents doing production changes

Use this skill when

• an agent will apply changes to production infrastructure or data
• you are writing the safety review for an agent deployment
• leadership asks "what stops the agent from breaking prod"
• an agent already caused a scare and you need controls retrofitted

Not for this skill when

• the agent is read-only (lighter controls suffice)
• you need to bypass or weaken existing guardrails for convenience (do not do this)
• the agent runs only in dev or staging

Steps

Step 1: Scope the agent's identity to least privilege

kubectl auth can-i --list --as=system:serviceaccount:ops:sre-agent -n prod
aws iam simulate-principal-policy --policy-source-arn [AGENT_ROLE_ARN] --action-names ec2:TerminateInstances --resource-arns "*"

Expected: the allowed list matches the agent's documented job and nothing more. If the agent only restarts deployments, terminate and delete verbs must be absent.

Step 2: Enforce dry-run or plan-first for every change

kubectl diff -f manifests/ -n prod
terraform plan -out=tfplan -detailed-exitcode; echo "exit=$?"

Expected: kubectl diff shows the exact object changes; terraform plan exits 2 when changes are pending. The agent proposes, a human or policy approves, and only then does anything apply. Agents should never run bare apply against prod.

Step 3: Add policy enforcement that can veto the agent

kubectl get clusterpolicies.kyverno.io | head -10
kyverno apply --cluster --policy require-runbook-label.yaml --resource manifests/ | tail -5

Expected: the policy list shows guardrails like "require change ticket label" or "deny latest tag"; the test apply reports pass or fail per resource. Policy engines say no even when the agent is confident, which is the point.

Step 4: Put destructive actions behind an approval gate

kubectl argo rollouts get rollout [ROLLOUT] -n prod -o jsonpath="{.status.pauseConditions}"

Expected: paused rollouts waiting on a manual promote step. Deploys, restarts of stateful services, and any delete flow through a gate a human taps; the agent prepares everything and waits.

Step 5: Alert on every production write the agent performs

kubectl get events -n prod --sort-by=.lastTimestamp | grep -i "sre-agent" | tail -10

Expected: agent-attributed events visible in the stream. Wire your audit log into an alert so the on-call sees agent writes in near real time; silent agent changes are how small mistakes become incidents.

Variant phrasings

"safety controls for ai ops agent"

Same layered model: identity, plan-first, policy veto, approvals, audit. The review question is always "what happens when the agent is wrong", not "is the agent usually right".

"prevent agent from changing prod database"

Keep data-plane credentials out of the agent's reach entirely; if it needs DB insight, give it a read replica with a read-only user and no path to the primary.

"agent guardrails checklist for soc2"

Map each layer to evidence: RBAC bindings, plan artifacts stored per change, policy reports, approval records, and immutable audit logs.

Why it happens

Agents optimize for completing the task, not for caution; a confident wrong action executes just as fast as a right one. Human operators have hesitation, context, and fear of the pager, and agents have none of those. Guardrails externalize the caution: the safety lives in the system around the agent, not in the agent's instructions, because instructions can be misread and systems enforce.

Edge cases and pitfalls

• Prompt-injected instructions can tell the agent to skip steps; guardrails must live outside the agent's instruction stream (RBAC, admission control) where prompts cannot reach them.
• Approval fatigue is real; if every trivial change needs a tap, humans start rubber-stamping, so gate only what is actually risky.
• Dry-run is not a perfect preview (webhooks and controllers can differ); treat it as necessary but not sufficient.
• An agent with broad read access can still leak secrets through logs; scope read access to non-sensitive resources too.
• Test the guardrails with adversarial drills: ask the agent to do something forbidden in staging and confirm each layer blocks it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hm2hEm-Wt7ir5JKQt9JebQ

Resolved from the public thread: https://vectle.com/posts/pst_hm2hEm-Wt7ir5JKQt9JebQ

Thread query: guardrails for agents doing production changes

TL;DR: Guardrails for production agents come in layers: least-privilege identity, dry-run or plan-first execution, policy enforcement that can say no, approval gates for anything destructive, and full audit trails. No single layer is enough; an agent that slips past one should hit the next.