Relynt
Back to blog
Product

Designing approvals that do not kill automation

12 min read

Approvals are the fastest way to make agent writes safe—and the fastest way to make agents useless. Here's how to gate what matters, present clear decisions, and avoid approval fatigue.

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:

  1. What is changing?
  2. Why is it changing?
  3. What is the blast radius?
  4. Can I verify it?
  5. 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:

  1. Prepare phase (automatic): gather info, draft changes, propose diff
  2. 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.

All posts