Skip to content
Back to guides
settings9/14/2026

Set a Spending Cap and an Approval Threshold Before Your Agent Runs Unattended

How to use the workspace agent policy screen in Settings to cap spend per run and require approval before higher-risk actions, before you let an agent operate without someone watching.

settingsagent-policygovernance

Letting an agent run unattended is a reasonable thing to want and a reasonable thing to be nervous about at the same time. The workspace-level Agent Policy screen, under a workspace's settings page, is where you set the actual guardrails instead of just hoping the agent behaves.

What you can set

The policy has three parts:

Forbidden capabilities. An explicit list of things this workspace's agents are not allowed to do at all, by name.

A spend ceiling per run, entered in dollars on the screen (stored under the hood in micro-units, but you never have to think in those). Set it once and every run in the workspace is capped at that amount.

An approval threshold — a point at which the agent must stop and get a human to approve before continuing, with two levels available: at any write action that's lower-risk, or only at higher-risk write actions. Leaving it blank means no approval gate is required.

The rule that makes this safe to hand to an ordinary form

Every field on this screen only narrows what an agent can do — nothing here can widen permissions beyond what's already allowed elsewhere in the system. That logic lives in the policy enforcement code itself, at the point where a run actually gets checked, not in this screen. Practically, that means the worst a mistake on this page can do is be overly restrictive; it can't accidentally grant an agent more room than it already had.

There's a second, less obvious protection here too: if a capability gets renamed or retired elsewhere in the platform, this screen doesn't just drop it from what it shows you. An entry the interface no longer recognizes is preserved and displayed by its raw name rather than silently disappearing — because dropping it would quietly un-forbid something an admin had deliberately blocked.

Who can change this

Writing a policy is admin-only, and it's enforced at the backend, not just hidden in the UI for non-admins. If a save fails because you don't have permission, the screen shows that refusal rather than pretending the change went through — you should never be left thinking you tightened a policy that didn't actually change.

Why this is worth doing before you extend trust

Start conservative: a low spend ceiling, an approval gate on higher-risk writes, and loosen both only as you've watched the agent behave the way you expect. That mirrors the general advice on building trust with agents incrementally — this screen is where that judgment actually gets enforced, not just where it gets discussed.