What policy controls#
Every Sidekick action is checked against three gates before it runs:
- Tool-call gate — is this tool allowed at all in this workspace?
- Approval-required list — does this specific tool need a human OK?
- Budget gate — would this action exceed the workspace cost or token cap?
If all three pass, Sidekick runs the action. If any fail, Sidekick either pauses for approval or refuses, depending on the policy.
Trust levels#
Trust levels are presets that wire the three gates for common operating shapes:
| Level | Tool-call gate | Approval-required tools | Best for |
|---|---|---|---|
| Supervised | Read-only by default | Almost everything | New workspaces, sensitive data |
| Balanced | Reads + low-risk built-in writes | Risky built-in tools (cancels, deletes, sends, credential and policy changes) and every built-in connector action that is not a read | Most teams |
| Autonomous | Most tools allowed | None by default; the untrusted-content rule below still applies | Trusted internal use cases |
| Custom | You define | You define | When presets don't fit |
Choose a level in Settings → Rules. You can switch any time; the new policy takes effect on the next action.
What's always approval-gated#
One rule holds at every trust level, including Autonomous: after Sidekick reads content from a connected app or MCP server, every consequential action that follows within the same conversation (or routine run) requires human approval. An action that is not tied to a conversation or routine run at all is treated the same way and is refused until it is started from one.
- What counts as consequential — anything that sends, shares, writes, updates, deletes, cancels, books, or deploys. An action on a built-in connector counts as consequential unless it is known to only read, so a new or unclassified action is held, not allowed. An MCP tool counts as consequential unless the vendor's read-only claim was pinned in its admitted manifest; the content it returns is still treated as untrusted.
- Why — content from connected apps and MCP servers is treated as untrusted, so an instruction hidden in an email or document cannot trigger one of these actions on its own.
- How long — the hold lasts 30 minutes from the read.
These rules also apply at every trust level:
- Any tool on your approval-required list needs approval before it runs.
- Calls to MCP tools admitted with an approval policy other than none need approval before they run.
- Any tool covered by the classified-tool untrusted-content check described in Policy Controls needs approval before it runs.
- Any tool that is not on the workspace tool-call allowlist is rejected before it runs.
Balanced holds every built-in connector action that is not a read, whether or not Sidekick has read anything first. Drafts, labels, archiving and read-state changes are held too, and so is any action nobody has classified yet. Supervised holds them as well. Autonomous does not, unless the rule above applies or you add the tool to your approval-required list.
Sidekick can never raise its own autonomy — it can only ever ask for tighter checks, not looser ones.
Tool-call approval flow#
When an action needs approval:
- Sidekick pauses and surfaces an entry in the Approvals inbox
- The entry shows the tool, the inputs, and the policy basis
- An owner or admin approves or rejects
- Sidekick resumes (or aborts) based on the decision
- The full approval trail lands in the Evidence Vault
Budget-driven approvals#
Budget gates trip when an action would push the workspace over its cost or token cap (configured in Settings → Spending limits). The approver sees the projected spend and can approve, reject, or raise the limit.
See Approvals governance for the approver-side workflow and Approval workflows for cross-team routing.