Agents and approvals

How an agent’s permissions are computed, who can run it, and how each agent action is allowed, refused or sent for approval.

Agents

flowchart LR
  own["Agent's own roles<br/>organization role, memberships, grants"] --> eff["Effective file access<br/>own roles plus the owner's"]
  ownerp["Owner's file permissions<br/>including organization roles"] --> eff
  eff -.->|"If the owner is an org admin *"| pub["Every public workspace (P-02)"]
  o["Its owner"] --> run["Task run as the agent<br/>with its owner's file access"]
  wm["Any workspace member *<br/>of a workspace it belongs to"] --> run
  om["Any organization member *<br/>through an organization task"] --> run
  run --> appr["Approval requests<br/>go to the person who started it"]

1. Every agent has an organization role (member by default), workspace memberships and resource grants.
2. For files and folders, an agent also uses its owner’s permissions, including permissions that come from the owner’s organization role. It can read its owner’s private drive but cannot write to it. If the owner is an organization admin, the agent’s file access covers every public workspace (P-02).
3. For connectors and skill edits, an agent uses the permissions of the person who started the task (falling back to the agent’s owner).
4. Unless the restriction on running another person’s assistant is on, a personal assistant can be run by its owner, by any member of a workspace it belongs to, and by any organization member through an organization-level task *. The run uses the assistant’s owner’s file permissions; its approval requests go to the person who started it (P-01).
5. Agents can be given admin or owner roles, in a workspace or the organization, and can then manage members * (P-07), unless the agent role restrictions are on.
6. Agents never answer approval requests. Agents cannot use secrets while agent use of secrets is off.

Approvals

flowchart LR
  act["Agent action<br/>tool call, API procedure, drive object or connector tool call"] --> tp["In-sandbox tool policy ◇<br/>tool calls, from the agent's preset;<br/>'ask' goes to the application tier"]
  act --> ap["Application tier policy ◆<br/>API procedures, drive, connectors:<br/>deny, then ask, then allow"]
  tp --> allowed["Allowed"]
  tp --> refused["Refused"]
  tp --> req["Approval request"]
  ap --> allowed
  ap --> refused
  ap --> req
  req --> who["Who can answer<br/>the person who started the task,<br/>workspace and organization admins; never an agent"]
  who --> sig["Decision signed by the App<br/>the sandbox can verify it, not create it"]
  sig --> always["'Always allow'<br/>a standing grant for that exact target, person and agent; 90 days"]

1. Presets are set per agent by its owner, by admins of the workspaces it belongs to, and by organization admins. Admins can also set “ask” or “deny” rules on individual resources.
2. Tool calls are decided inside the sandbox from the agent’s preset; only “ask” outcomes reach the application tier. API procedures, drive objects and connector tool calls are decided by the application tier: deny first, then ask, then allow.
3. There is no organization-wide policy layer: an administrator cannot set one rule that applies to every agent (P-05).
4. Approval decisions are signed by the application tier. “Always allow” creates a standing grant for that exact target, for the person and agent concerned, for 90 days.
5. Checks made inside the sandbox can be bypassed by code the agent runs; checks made by the application tier cannot (see Request trace).

For the user-facing steps to set an agent’s permissions and answer approvals, see Decide what agents can do.

Agent policy presets

Agent policy preset	Behavior
Full (default for new agents)	Allows every action, including reading environment files * (P-05)
Connectors	Allows actions inside the sandbox; asks before each connector tool call
Boundary	Allows actions inside the sandbox; requests to the application tier are decided by server-side policy. Outbound network requests are not evaluated while the egress setting is open *.
Guarded	Allows reads, edits and writes; asks before shell commands, web fetches, terminal sessions and writes to git or SSH configuration
Supervised	Asks before every action except reads
Read only	Allows reading files inside the sandbox; refuses changes and drive reads

Which presets your agents use, and any allow, ask or deny rules, are yours to decide (see What your team decides).