Approving agent actions

Approvals are the human gate between an agent proposing an action and performing it. Your decision becomes part of the audit record. This guide shows how to make it well.

What you are looking at

Every approval request should tell you three things:

1. What: the exact action and its parameters (the action itself, not a summary).
2. On what: the target system, record, or scope.
3. Why: the agent’s justification linking the action to your session goal.

If any of the three is missing or vague, treat that as a reason to pause, not to guess.

How to decide: five checks

Run these in order. All five must pass for an allow:

• What: do you understand the exact action? If not, deny or ask for clarity.
• On what: is the target inside your session’s scope and the right org? Wrong target is the classic failure.
• Why: does the justification connect to your stated goal? “Because it might help” is not a justification.
• Blast radius: what changes if you allow? Is it reversible? Customer-visible? Cross-system? Irreversibility raises the bar.
• Policy fit: does allowing match what this environment intends? When in doubt, the stricter reading wins.

Decide in this order: first check that what, on-what, and why are clear (if not, deny and request clarity). Then check the target is in scope and the right org. Then check the blast radius is acceptable. Any failed check means deny; all checks passing means allow. Both outcomes are recorded: a denial is a first-class outcome, and an allowed action runs and is recorded.

Allow, deny, redirect

• Allow when all five checks pass. Your approval is part of the record, so own it.
• Deny when anything is off: unclear action, wrong target, weak justification, unacceptable blast radius. Denials are healthy, first-class outcomes. A tenant with zero denials is rubber-stamping.
• Redirect when the goal itself drifted: end or rescope the session instead of approving piecemeal. Do not approve your way out of a misscoped session.

After the decision

• Allowed: watch the result land in the transcript; confirm it did what was proposed.
• Denied: the agent must work another way or stop that line of action. If it re-proposes the same action without new justification, end the session and report it.
• Either way: your decision and (ideally) a one-line reason are recorded. Someone, you next week or an auditor next quarter, should be able to reconstruct why.

Habits of good approvers

• Decide at request time; do not batch ten approvals with one click.
• Keep a personal bar: if you cannot explain the action back, deny.
• Track patterns: the same denial three times means the environment, goal, or policy is wrong. Escalate with examples, not impressions.
• Never approve to “see what happens” on irreversible actions.

Operators supervising many sessions: the Platform ops path builds on this. Builders designing what gets gated: FDE approvals.