Guardrails for High-Risk Automations

This guide helps you identify when an assignment carries meaningful risk — financial, regulatory, reputational, or irreversibility — and apply the right guardrails before letting it run autonomously.

---

Risk Classification

Before configuring guardrails, score your assignment against the five risk dimensions below. The highest single dimension determines the overall risk tier.

Risk dimensions

Dimension	Low	Medium	High	Critical
Dollar impact	Under $500 per action	$500–$5,000	$5,000–$50,000	Over $50,000 or recurring charge
Irreversibility	Fully reversible (e.g., tag, draft, status)	Recoverable with effort (e.g., archive, field overwrite)	Hard to undo (e.g., sent email, posted record)	Cannot be undone (e.g., payment settled, contract signed)
External visibility	Internal only	Shared with internal teams	Customer-facing	Public or regulatory submission
Regulatory exposure	None	Internal policy only	PII / GDPR / HIPAA / SOC	Financial (SOX, PCI-DSS), legal, or contractual
System criticality	Experimental or sandbox	Non-critical production	Important but not mission-critical	Mission-critical (billing, payroll, ERP)

Tier definitions and required guardrails

Tier	Overall score	Required guardrails
Low	All dimensions score Low	None required — routine reversible operations
Medium	Any dimension scores Medium	HITL gate on the risky branch; anomaly alerts enabled
High	Any dimension scores High	HITL gate; hard caps on action volume and spend; allow/deny lists
Critical	Any dimension scores Critical	All High guardrails; shadow mode before first autonomous run; two-person SOP review before going live

---

Guardrail Patterns

HITL approval on high-risk branches

Add a Human-in-the-Loop approval step before any action that scores Medium or above. The approval request should give the reviewer enough context to decide without opening another system.

Before submitting the payment, request approval.
Title: "Payment — [vendor] — $[amount] — [invoice ID]"
Description: vendor name, bank details, invoice due date, budget line.
If denied, stop and log the reason. Do not retry without a new instruction.

See Designing Human-in-the-Loop Workflows for choosing the right approval shape and setting escalation chains.

Hard caps

Limit the blast radius of a runaway job by setting explicit caps in your SOP.

Process at most 50 records per run.
Send at most 20 external emails per hour.
Do not submit more than one payment per invoice ID per day.
If either cap is reached, stop and log: "Cap reached — [cap name] — [count] actions taken."

Use the Jobs list to verify cap behavior during testing before removing gates.

Allow and deny lists

Restrict write operations to approved targets. Any action outside the list requires a HITL approval step.

Email domain allowlist:

Only send outbound emails to addresses ending in @acme.com, @partner.com,
or addresses listed in the approved-recipients.csv file.
If the recipient is outside this list, request approval before sending.

Account allowlist for financial actions:

Only process payments to vendors in the approved-vendors list in Files.
If the vendor is not in the list, flag for procurement review and stop.

Idempotency checks

Prevent duplicate actions when a job retries or runs more than once.

Before creating the record, check whether a record with this [reference ID]
already exists for today's date. If it does, skip creation and log:
"Skipped — record already exists — [reference ID]".

Idempotency checks are especially important for financial writes, external API calls, and email sends where duplicates cause downstream problems.

Shadow mode before enabling writes

For new high-risk assignments, run the assignment in read-only mode first. Observe what it would have done, then enable write access once the outputs look correct.

SHADOW MODE — DO NOT WRITE:
Read the data and log what actions you would have taken, but do not
submit, send, or update anything. Summarize in the job output:
"Would have [action] for [count] records."

After reviewing a week of shadow-mode outputs with no surprises, remove the SHADOW MODE instruction and enable the write connections.

Two-person SOP review for Critical assignments

For Critical-tier assignments, require a second team member to review the SOP before any change goes live. In practice this means:

1. The Builder drafts and saves the updated SOP revision.
2. A Manager or Administrator opens the assignment, reviews the diff, and runs a test job.
3. Only after the reviewer is satisfied does the Manager update the live revision.

Team roles and permissions defines who can create revisions versus who can promote changes on assignments owned by others.

Time-window restrictions

Limit autonomous write operations to business hours to ensure a human can respond quickly to anomalies.

Only perform write actions (updates, sends, submissions) between 08:00
and 18:00 Monday–Friday in [timezone]. Outside these hours, queue the
action and log it. On the next business day, request approval before
executing queued actions.

---

Detection and Response

Anomaly signals to monitor

Review job outputs regularly for these patterns, especially in the first two weeks after a new assignment goes live:

Signal	What it may indicate
Job duration much longer than usual	Stuck loop, external system slowdown, runaway processing
Action count far above the average	Cap not applied; duplicate records being created
Cost spike without corresponding output	Repeated retries, large context being sent to the model
Output drift — format or content changes without SOP change	Upstream data schema change; model behavior change
HITL denial rate rising above 20%	SOP is generating incorrect outputs; refine before removing gates

The Jobs list and Team Insights show duration, action counts, and run history. Use these to spot unusual patterns.

Kill switch: pausing an assignment

If something is going wrong, you can stop an assignment immediately:

Disable a schedule:

1. Open the assignment.
2. Go to Assignment Settings > Schedule.
3. Toggle the schedule off. The assignment stops running automatically. Jobs already running continue to completion.

Disable a trigger:

1. Open the assignment.
2. Go to Assignment Settings > Triggers.
3. Disable the trigger. No new jobs start from that trigger.

Revoke a connection:

1. Go to the Connections page.
2. Find the connection used by the assignment.
3. Disconnect it. The assignment will fail immediately if it tries to use this connection, which prevents further writes to that system.

Revoking the connection is the fastest way to stop a write-heavy assignment when you are not sure whether a running job has already done damage.

Rollback via Assignment Versions

If a SOP change caused the problem, revert to the previous working version:

1. Open the assignment.
2. Click the revision selector in the builder toolbar.
3. Select the last known-good revision.
4. The assignment now runs the reverted SOP on the next trigger or manual start.

See Assignment Versions for details on how versioning works.

Communication template

When you pause a high-risk assignment, notify stakeholders immediately. Waiting for a full post-mortem before communicating increases risk.

Subject: [Assignment name] paused — [date]

We have paused the [assignment name] assignment as a precaution.

What happened: [one sentence — e.g., "The assignment sent 12 duplicate
emails to the procurement team before the cap triggered."]

Current status: The assignment is paused. No further automated actions
will occur until we have reviewed and restarted it.

Impact: [e.g., "12 emails were sent that should not have been. We are
contacting the recipients to clarify."]

Next step: We are reviewing the SOP and expect to have an update
by [date/time]. We will notify you before restarting.

---

Worked Example: Purchase Order Processing

The Purchase Order Processing tutorial covers the basic flow. Here is how to apply the full risk classification and guardrail set before enabling it in production.

Risk classification

Dimension	Score	Reason
Dollar impact	Critical	Individual POs can exceed $50,000
Irreversibility	High	Approved POs trigger downstream procurement actions
External visibility	Medium	Confirmations go to vendors
Regulatory exposure	Medium	Internal procurement policy; financial audit trail required
System criticality	High	ERP is mission-critical

Overall tier: Critical (highest single dimension score)

Guardrails applied

HITL gates:

For POs between $1,000 and $5,000: request approval from department manager.
Title: "Approve PO — [vendor] — $[amount] — [PO number]"
Description: vendor, department, line items, budget line.
For POs over $5,000: request approval from finance director.
Include budget impact analysis in the description.
If not approved within 48 hours, escalate to the next level.
If denied twice, halt and mark the PO as Needs Manual Review.

Hard cap:

Process at most 30 POs per run.
Do not submit more than one approval request per PO number per calendar day.
If the cap is reached, stop and log: "Run cap reached — [count] POs processed."

Vendor allowlist:

Only process POs for vendors in the approved-vendors.csv file in Files.
If the vendor is not found, flag for procurement review and skip.
Do not send any communications to unapproved vendors.

Idempotency check:

Before sending an approval request, check whether an approval request
for this PO number is already pending. If yes, skip and log:
"Skipped — approval already pending — [PO number]".

Shadow mode (first two weeks):

Enable the assignment with all connections in read-only mode. Add the SHADOW MODE instruction to the SOP. Review the weekly job outputs with the procurement lead before enabling write access.

Time window:

Only submit approvals and send notifications between 07:00 and 19:00 UTC,
Monday–Friday. Queue any actions triggered outside these hours and process
them at 07:00 on the next business day after requesting approval.

Two-person review: A Manager reviewed and approved the SOP before the assignment was promoted to live.

---

Related

• Designing Human-in-the-Loop Workflows — Risk tiers, approval shapes, escalation chains, and ramping toward autonomy
• Assignment Versions — How to review and revert to a previous SOP version
• Roles and Permissions — Who can create, edit, and promote assignment revisions
• Security & Privacy — Platform-level security controls, SOC 2, and data handling
• Purchase Order Processing — Full tutorial showing threshold-based approval routing
• Expense Report Approval — Full tutorial showing HITL approval with dollar thresholds