Approvals are the fastest way to make agent writes safe. They are also the fastest way to make agents useless.

If every meaningful action requires a human click, your "automation" becomes a queue. The goal is not "approval everywhere." The goal is approval where it buys down real risk, while keeping low-risk work flowing automatically.

This post lays out a practical approach to designing approvals that preserve velocity: what to gate, how to present decisions, and how to avoid approval fatigue.

The failure modes

1) Blanket approvals

Teams ship approvals as a universal rule: "All writes require approval."

Outcome: users stop using the agent because the latency is too high.

2) Unclear approval prompts

Approvers get messages like: "Agent wants to update a deal. Approve?"

Outcome: approvals become random, rubber-stamped, or always denied.

3) Approval fatigue

If people see 50 requests a day, they stop thinking.

Outcome: security theater, not security.

4) Approval bypass pressure

When approvals slow things down, teams look for ways around them: broader scopes, shared tokens, or "temporary" exceptions.

Outcome: your controls erode over time.

A better mental model: approvals are for exceptions, not the default

The right baseline is:

Allow low-risk actions under strict limits
Deny obviously unsafe actions
Require approval only when risk is meaningful and the outcome is hard to reverse

That triage—allow / deny / approve—keeps automation alive.

What should require approval?

A clean rule of thumb:

Require approval when an action is high impact, hard to undo, or crosses a trust boundary.

Examples that usually deserve approval

moving money, refunds, credits above a threshold
provisioning access or changing roles/permissions
closing incidents, changing production configuration
merging to protected branches, deleting resources
sending customer-facing communications with legal or reputational risk
changing "state transitions" that have business meaning (e.g., "Closed Won")

Examples that usually should not

updating notes, adding context, tagging, linking tickets
drafting messages (with human send)
read-to-write "prep" steps (fetch data, propose changes)
low-dollar or low-scope updates under strict limits

If your approvals are triggering on "routine hygiene," you'll kill adoption.

Design approvals around risk tiers

A simple risk tier model works surprisingly well:

Tier 0: Auto-allow (low risk)

strict constraints (fields allowed, max amount change, rate limits)
always produce a receipt
optional post-action notification

Tier 1: Auto-allow + notify (medium risk)

still automatic, but notify an owner or channel
gives visibility without blocking work

Tier 2: Approval required (high risk)

human must approve before execution

Tier 3: Deny by default (prohibited)

blocked always, with clear reason

This allows you to preserve automation without losing control.

The approval prompt is the product

The number one reason approvals fail is that approvers cannot tell what they are approving.

A good approval request must answer, quickly:

What is changing?
Why is it changing?
What is the blast radius?
Can I verify it?
What happens if I do nothing?

What to include in an approval card

Agent name + owner (who is responsible for this agent)
Action summary in plain language
Target resource (ticket, deal, repo, config key)
A concise "diff" view (before → after) where applicable
Risk reason (why this is being gated)
Links to context (ticket, thread, record)
Approve / Deny buttons
Optional: "Approve once" vs "Approve for 1 hour" (advanced)

What to avoid

raw JSON dumps
vague descriptions ("update record")
approvals without context links
long paragraphs

Approvals should feel like reviewing a pull request: clear, scannable, and grounded.

Reduce approvals by tightening policy, not by loosening control

A common mistake is to remove approvals because they are annoying. The better move is to reduce how often they trigger while keeping protections.

Tactics that work:

1) Narrow the writable surface area

Instead of "agent can update a deal," define:

which fields it can touch
which deal states it can move between
which amount ranges are auto-approved

This converts many "approval required" events into "auto-allow under constraints."

2) Use thresholds and guardrails

dollar limits
rate limits ("no more than 10 changes per hour")
state transition rules ("requires approval only when moving to Closed Won/Lost")

3) Add preflight checks

Before asking for approval, have the system validate:

required metadata present
target exists and is in expected state
action is consistent with current context

This reduces low-quality approval requests.

Avoid approval fatigue with routing and ownership

Approvals should go to the smallest accountable group.

Best practice: route approvals by domain

CRM changes → sales ops approvers
ticket closures → on-call / incident commanders
access grants → security/IAM
code changes → repo owners

When approvals go to a generic channel, everyone assumes someone else will handle it.

Also: every agent should have a human owner. If the agent causes noise, you know who to talk to.

Keep automation moving with "two-phase" action design

For many workflows, you can split actions into:

Prepare phase (automatic): gather info, draft changes, propose diff
Commit phase (approved): execute the irreversible write

This dramatically reduces approval burden because:

the approver sees a clean proposal
the system does the busywork
the human only authorizes the final commit

Examples:

Draft customer email → human sends
Propose incident resolution steps → commander approves final close
Generate PR + tests → reviewer merges

Measure approval health like a system

A healthy approval system has:

low approval volume relative to write volume
high decision quality
fast response time for high-risk actions
low override/bypass pressure

Metrics worth tracking:

approval rate and deny rate (per agent, per action)
time-to-decision (p50/p90)
approval volume per approver
"rework" rate (approved actions that are later reverted)
frequency of emergency bypasses

If your approval flow is hurting velocity, the data will show it.

How this maps to Relynt

In Relynt, approvals are not an add-on. They're a first-class authorization outcome:

allow
deny
require approval

The product goal is to keep low-risk work automatic, and make high-risk decisions easy for humans:

policies define when approvals are required
approval cards present clear diffs and context
signed receipts prove what was approved and what executed

That's how you ship agents into production without turning automation into a ticket queue.

The takeaway

Approvals do not kill automation. Bad approval design does.

The pattern that works is:

narrow what agents can write by default
auto-allow routine work under strict guardrails
require approval only for high-impact exceptions
make approval prompts scannable, contextual, and diff-based
measure and tune like a production system

Do that, and you get both outcomes everyone wants: velocity and control.

Posts

Designing approvals that do not kill automation

Stay in the loop