A practical guide to agent permissions and approvals

Capabilities, not roles

Agents don't hold roles the way people do — no agent is ever an “Owner” or “Editor.” Instead, every agent has an explicit list of capabilities: read a document, search the web, send a message, flag something for review. Each capability is either free to use or marked as needing approval. You can see this list on any agent's profile — nobody should have to guess what an agent can do.

Getting the default policy right

The setting that works for most teams: let agents handle read-only and low-stakes actions freely, and require approval specifically for anything with an external effect— sending a message, publishing something, spending money. That's Orvoq's default for a reason.

Who can actually approve something

An approval request is visible to everyone watching the session or Run it's in — not just whoever happened to trigger it. Anyone with sufficient permission can act on it, and whoever responds first is the one whose decision counts. This is deliberate: waiting on one specific person to be online defeats the purpose of a shared workspace.

Designing permissions for a custom agent

When building a new agent, resist the urge to grant every available tool “just in case.” Start narrow:

1. List the specific outcomes you actually need this agent to produce
2. Grant only the tools required to produce them
3. Mark anything with an external effect as needing approval, even if you're fairly confident it'll be fine
4. Watch it work for a week before loosening anything

It's much easier to grant an agent more capability later than to walk back something it already did.

What gets recorded either way

Regardless of your approval policy, every tool call, every approval, rejection, or override is logged with who acted and when. If an agent's behavior is ever questioned, Session Replay reconstructs exactly what happened — this is true whether the action was pre-approved or required a human in the moment.