Configure an agent’s permissions

The agent’s detail page at /agents/:id is where you change what it’s allowed to do.

Open the agent

Agents in the sidebar → click any agent card. The detail page has:

Agent metadata (name, status, created at, SPIFFE ID, rate limit)
The permission matrix — one row per (platform, scope) it holds
Action buttons: Suspend / Reactivate / Delete / Rotate & Issue Install Token / Copy SPIFFE

Add a permission

Use the Add permission button (or whatever the page calls its grant flow). Pick a platform, select scopes, decide whether require_approval is on. Save.

Some rules to keep in mind:

The platform must already be connected on /platforms. If it’s not there, connect it first.
Scopes are platform-native — they look like chat:write, data.records:write, https://www.googleapis.com/auth/gmail.send depending on the platform. See Scopes & permissions for the underlying model.
Each (agent, platform, scope) row carries its own require_approval toggle.

Bounded by the owner’s policy

An agent’s grantable scopes are bounded by the policy assigned to its owner. If the owner’s policy doesn’t allow a given (platform, scope), that row appears greyed out in the picker — you can see it but you can’t grant it. Lift the bound by editing the owner’s policy on the Team page, or assigning a different policy.

Org guardrails sit even higher: a scope denied by a guardrail is unselectable for everyone, regardless of policy.

Revoke a permission

Find the row in the permission matrix and remove it. The agent’s next call using that scope immediately returns scope_not_granted — there is no propagation delay.

If you revoke the last scope on a platform for that agent, the agent loses access to that platform entirely.

Flip the approval toggle

You can change require_approval on an existing permission without revoking and re-granting. Useful when you’ve watched an agent operate safely for a while and want to drop the friction on a specific scope.

Reverse direction (turning approval back on) is just as safe — the next call queues instead of running.

What gets audited

Every change writes a row to the audit log:

permission.granted
permission.revoked
permission.approval_toggle_changed

The action appears in Audit → Actions with you (the owner) as the actor.

When in doubt

The cheapest configuration is read scopes auto-approved, write scopes approval-on, destructive scopes approval-on, suspended by default if you’re not watching. You can always loosen it.