Approvals · Vardhold docs

When a rule says ask, the agent waits and a person decides. Denying is one click. Allowing needs proof that a person, not the agent, said yes.

What a person sees#

When an action needs approval, the tray app opens a Vardhold window on the desktop of the person using the PC. It shows what is needed to decide well:

The agent and what it wants to do, with the full command, path, host or MCP tool. Secrets in it are redacted, and very long targets are shortened with a note saying so.
The rule that asked, and its severity.
Where the request came from, the agent's trust, and how the same request was decided before.
A countdown to the rule's timeout.

The same request appears on the dashboard's Approvals page, and optionally as a desktop notification when the dashboard is in the background.

The three answers#

Answer	Effect	Confirmation
Deny	The agent is told no, with the reason	None: one click
Allow once	This action runs; the next one asks again	Administrator
Always allow	This action runs, and a rule allowing exactly this request is added to the policy	Administrator

Before you choose Always allow, the window shows the exact rule it will add. The rule matches only this agent, this action and this exact target, and it is placed directly above the rule that asked, so protections higher in the policy (Vardhold's own files, credentials) still win. Where an exact rule cannot be written safely, Always allow is not offered.

Why allowing needs an administrator#

AI agents run as the same Windows user as the person at the PC, so anything that user can reach, an agent can reach too, including the tray app's window. That is why the tray app on its own can only make protection stricter.

When you click Allow, Windows shows a User Account Control prompt on the secure desktop. Then an elevated Vardhold window states exactly what will change. Only Confirm in that window sends the decision. Ordinary programs, agents included, cannot click or type into either window.

For the strongest guarantee run AI agents under standard user accounts, or set UAC to Always notify. In its default setting, UAC is a convenience for administrator accounts rather than a hard boundary. See Hardening checklist.

When nobody answers#

Each ask rule has a timeout (timeout_seconds, 5 to 3600) and says what happens when it runs out (on_timeout). The default policy waits 60 seconds and then blocks. Rules without their own timeout use the approvalTimeoutSeconds setting.

The agent's request waits for the answer, so an unanswered approval holds the agent rather than letting it carry on. Engaging the kill switch denies every pending approval at once, and if the Vardhold service stops while a request is waiting, the request is blocked, whatever the rule's on_timeout says. Every approval is closed exactly once and recorded.

Audit trail#

Every approval is sealed in the audit log: the request, who decided, how (deny, allow once, always allow, timeout or kill switch) and when. Rules added by Always allow appear in the policy history as a new version, like any other policy change.

Fewer prompts#

Approvals work best when they are rare enough to be read. If people see the same prompt often:

Use Always allow for routine, exact requests.
Narrow the rule: match the project folder with outside_cwd, or a specific agent with agent.
Use verdict_trusted so agents you have reviewed get log where others get ask.

The dashboard's dry run shows how a policy change would have decided recent activity, so you can see the prompts you remove before you apply it. See Write a policy.