Control what your workspaces' agents and members can use.
What it governs
A usage policy decides which outside resources a workspace may consume, per category:
| Category | Covers |
|---|---|
| apps | Running apps published by other workspaces or the public grid |
| knowledge | Reading knowledge and skills published outside the workspace |
| mcps | Connecting to and calling MCP servers |
| agents | Chatting with and invoking agents |
| flows | Running flows |
A workspace's own work is never blocked. The policy draws the line at the workspace boundary, not inside it.
Reach
Each category gets a reach, a ladder of how far outside the workspace its usage may go:
| Reach | In settings | Meaning |
|---|---|---|
| public | everything it can see | Anything visible: the open grid, public publishers |
| organization | this organization | Only resources from workspaces in the same organization |
workspace (team in the API) | this workspace only (on the org policy: each workspace’s own) | Only the workspace's own resources |
On top of the reach, the allowed list opens specific exceptions below it and the blocked list closes specific ones above it. Entries pin a specific resource or a publisher (every resource from that workspace). They are stored by identity, not by name, so renames and namespace changes can't dodge them.
Who sets it
- Organization policy: set by org admins under settings → organization → usage policy. It governs every workspace in the org, and workspaces cannot widen it.
- Workspace policy: for standalone workspaces, set by the workspace owner under settings → workspace → usage policy.
A workspace's settings page inside an org shows where the policy comes from and points admins to the org editor.
When something is blocked
The person hits a clear refusal naming the policy, and the attempt lands in the policy editor's blocked attempts feed — grouped by resource, most-hit first. An admin can allow any entry from the feed in one click, so real demand surfaces exactly where the decision is made.
Enforcement
The policy is enforced in the permission layer of the API — the same gate every surface goes through: running apps, reading knowledge, MCP tool calls, agent messages, and flow runs. There is no client-side path around it, and denials are written to the audit log.