Manage user policies

A policy is a named bundle of allow, deny, and require-approval rules that you assign to a teammate. Every agent that teammate owns inherits the policy’s scope limits — so a member with the read_only policy can never grant their agent a *:write scope, even by accident.

Policies live under Governance → Policies in the sidebar (/policies, admins only). The list shows every policy you’ve defined, plus how many members it’s assigned to.

Create a policy

Click + New policy on the Policies page (or /policies/new directly). The editor has a form on the left and an In plain English summary on the right.

Name and description

Give the policy a name (e.g. Analyst — no PII) and an optional description of what it permits.

Safety presets

One-click switches that apply across every platform, using the built-in tags:

A capability blocked by a preset shows Blocked by safety preset in the grid and can’t be switched on.

What this policy can do

The capability grid lists each platform; expand one to see its capabilities. Every capability has a three-way control:

• Allowed — the member’s agents may use it.
• Ask first — allowed, but each call queues for human approval.
• Blocked — not permitted (the default).

Use Set all N to to change every visible capability on a platform at once, and Search capabilities… to filter the grid. Org guardrails appear above the grid as locked rows marked applies to every policy; expand one to see what it affects, or click Edit on Guardrails →.

Need a scope or tag that isn’t listed? Define scopes under Platforms → Scopes and tags under Governance → Tags — the editor links to both.

Conditions (advanced)

On the Team plan and above, you can add + conditional allow, + conditional deny or + conditional ask rules that target a platform, tag or scope and carry a condition evaluated at call time (for example business hours, or an amount ceiling on the request body). A condition can narrow an allow, or widen a deny or an ask — it never grants. If a condition errors, an allow does not apply and a deny or ask does. On lower plans the section shows an upgrade prompt; conditions already saved keep applying.

In plain English

The right-hand summary recomputes as you edit: how many capabilities are allowed, how many need approval, and a sentence such as “Can read messages… Asks you first before… Everything else is blocked.” If nothing is allowed, it tells you the policy blocks everything — so you don’t save a dead policy by mistake.

Click Save. Each save bumps the policy’s version (the toast shows it, e.g. “Saved (v3)”).

Assign a policy

Policies don’t do anything until you assign them. Open the Team page, find a member’s row, and pick a policy from the dropdown. The change takes effect on the member’s next agent call — there’s no propagation delay. If the new policy is narrower than what the member’s agents already hold, those agents are suspended and you’ll see a banner.

A member without a policy assignment is denied on every call (reason no_policy_assigned) until you assign one.

Edit or delete

Open any policy from the list to re-enter the editor. Save commits the change for every member currently assigned to it; if the change would leave agents holding scopes the policy no longer allows, you’re warned that they will be suspended. Unassigning a member is a separate action on the Team page.

Deleting a policy (Delete in the editor header) is blocked while members are assigned to it — reassign or unassign them on the Team page first, then delete.

What gets recorded

Every call an agent makes is evaluated against the member’s current policy version, and the compliance export records which policy and version decided it (policy_id, policy_version) — so you can answer “what was this person allowed to do then?” later.

Next

• Suggest policies from current access
• Manage org guardrails
• Configure an agent’s permissions