Approve agent actions in the dashboard

The /approvals page is your queue. Every time an agent calls a scope you’ve marked require_approval, a card lands here.

What you see

Page title: Pending Approvals. Subtitle: “Auto-refreshes every 5 seconds.” An amber {N} pending badge appears in the header when there’s anything to action.

The first time you visit, a banner offers to enable push notifications — see Push notifications.

When the queue is empty:

✓ No pending approvals All agent actions are within approved permissions.

A pending card

Each card shows:

The agent name
The platform and the specific scope being attempted
A summary of what the agent wants to do (action + first-line of the request payload)
An expiration timer — 10 minutes from creation by default
Two buttons: Approve (green) and Deny (red)

Approve

Click Approve. The card flips to a brief “Processing…” state while AgentValet re-executes the original call to the platform.

What happens behind the scenes:

The decision is written to the approval row
The platform call runs with the stored credential
The platform response is captured into result_json
The agent (which has been polling /v1/approvals/:id) gets the result on its next poll

You’ll see the card disappear when the call finishes. If the call itself fails (network error, platform 5xx, etc.), an error toast surfaces and the row’s execution_error field is populated for forensics.

Deny

Click Deny. The card disappears. The agent gets status: denied on its next poll and surfaces the denial to whoever’s talking to it.

Nothing is sent to the platform.

What gets audited

Every decision writes a row to the audit log:

approval.approved (with the platform response status in metadata)
approval.denied

You can also see denied + expired approvals in Audit → Policy Decisions.

Approving on the move

For when you’re not at your desk: push notifications and mobile passkey cover the same workflow.