Approving a Flagged Action

When a policy returns Require approval, the action doesn't fail and it doesn't run. It's held — waiting for a person to decide. This article covers what happens on both sides of that pause.

What happens when an action is flagged

Gatekeeper holds the request rather than forwarding it, creates an approval event with its own ID, and generates a link for a human to open.

From there the action goes one of three ways. On approval, Gatekeeper executes the original held request — with the original parameters — and returns the result to the agent. On rejection it's discarded. And if nobody answers, the event expires and the action is discarded too.

The important detail on the approval path: the action Gatekeeper runs is the one that was submitted and reviewed. The agent doesn't get a second attempt at composing the request after approval is granted.

What your agent experiences

A well-behaved agent will tell you it's waiting, surface the approval link, and then poll for the result. It should not retry the action while waiting.

Retrying is the mistake to watch for. Re-submitting a held action creates a second approval event rather than checking on the first, which means duplicate requests in your approval queue and — if both get approved — the action potentially running twice. If your agent seems to be generating approval requests in pairs, this is why.

Approval events expire

An approval event does not wait indefinitely. If nobody acts on it, it eventually expires and the held action is discarded — it does not run.

This is the branch people forget, because a dropped action looks like nothing happening rather than like a failure. Practically:

• Route approval links somewhere people actually look. An approval sitting in a channel nobody reads is a silently dropped action.
• Expect the agent to have moved on. By the time a stale approval is noticed, the task it belonged to has usually been abandoned. Re-run the task rather than hunting for the expired event.
• If actions are expiring routinely, the policy is wrong. Approval is for exceptions. If a routine daily action needs approving every time, either allow it and rely on the audit log, or narrow the rule so it only catches the genuinely risky cases.

Choosing between Deny and Require approval

Require approval is the right choice when the action is sometimes legitimate and a human can tell the difference quickly. It's the wrong choice when:

• The action is never acceptable — use Deny, and don't make someone reject it repeatedly.
• The action is time-sensitive and the approver isn't reliably available — you've built a system that fails by default.
• The volume is high — approval fatigue means people start approving without reading, which is worse than having no gate at all.

After the fact

Approved and rejected actions both appear in your audit log, alongside actions that were allowed outright. Reviewing what's been approved over a few weeks is the best signal for which rules should be relaxed to Allow and which should be tightened to Deny.