Skip to main content
Governance lets you put guardrails around what your AI agents and workflows can do. You decide which kinds of tools they may use, which external hosts they may reach, and which actions must be approved by a person before they run. You set it once for the workspace, and it applies to every workflow and every agent.
Only Owner and Admin roles can configure workspace governance. Per-connection permissions can also be set by anyone who can edit that connection.

​
How it works at a glance

  • Nothing is restricted by default. Governance only affects the things you choose to limit. Until you add a rule, agents keep working exactly as before.
  • The strictest rule wins. You can tighten rules at three levels (workspace, connection, and individual workflow node). When more than one applies, the most restrictive one takes effect.
  • Changes apply within a few seconds of saving.
  • Everything is recorded. Blocked actions, approvals, and policy changes all appear in the Audit log.

​
Workspace policy

Open Settings → Governance to set the default policy for the whole workspace.

​
Tool permissions

Every tool an agent can call falls into one of three risk classes. For each class you choose what agents are allowed to do: For Write and Destructive, pick one of:
If a tool can’t be recognised, it’s treated as a Write. That way a restriction is never accidentally bypassed by an unfamiliar tool.

​
Destination hosts

For tools that fetch a URL (such as the HTTP Requests connector), you can control which external hosts an agent may reach: List one host per line. Wildcards are supported, for example *.example.com.
Host rules apply to tool calls that take a URL. Connectors that always talk to a fixed service (for example a payments or email connector) are governed by the Tool permissions above instead.

​
Approvers

When you set a class to Require approval, choose who can approve. Approvers work the same way as the Human approval node: you build slots, and each slot can be satisfied by a specific person, anyone with a role, or any member of a team. Every slot must be satisfied for the action to proceed. If you leave the approvers empty, workspace Admins approve by default.

​
Approval timeout

Set how long an approval may wait before it expires. If no one acts within that time, the approval expires and, by default, the run stops (this is configurable, see When an action is denied below). Leave it blank to wait indefinitely.

​
When an action is denied

Two settings decide what a run does when governance denies something:
  • Let the agent continue: the agent is told the action wasn’t allowed and adapts, for example it reports what it couldn’t do or takes a different route. The workflow keeps running.
  • Stop the workflow: the run fails at that point and later steps don’t run, the same as a Human approval that isn’t granted.
The defaults suit most cases: a blocked tool is usually something the agent should simply route around, while a rejected approval is a deliberate “no” that should stop the run. Change either one if your workspace needs a stricter or a more permissive stance.

​
Per-connection permissions

Each connection can carry its own, tighter rules. On the Connections page, open a connection and choose Permissions.
  • Narrow which of that connection’s tools may be used.
  • For URL-based connections, restrict which hosts that connection may reach.
Connection rules can only tighten the workspace policy, never loosen it. A tool the workspace blocks stays blocked, and the picker shows it as unavailable with the reason.

​
Per-workflow limits

Inside the workflow editor, an agent node that uses the HTTP Requests connector can list the specific hosts that node’s agent is allowed to reach. This narrows things further for that one node, on top of the workspace and connection rules.

​
What to expect when a rule applies

Blocked action. By default the agent receives a “not permitted” result, mentions it in its answer, and the workflow continues without performing the action. You can change this to stop the run instead (see When an action is denied). Approval required. The run pauses and an approval request appears in the Approvals inbox (and by email, if enabled). When an approver accepts, the action runs and the workflow continues. If it’s rejected or times out, by default the workflow stops and the action does not run, the same as a Human approval step (also configurable in When an action is denied).
If an agent tries to do several approval-required actions in the same step, they’re grouped into a single approval request so you review them together.
Test before you rely on it. The Governance page includes a Test access panel: pick a connection and one of its tools (and, for URL tools, a host), and it shows whether that call would be allowed, need approval, or be blocked under your current policy. It also tells you which setting decided, for example “Set in this connection’s permissions” or “Set in the workspace governance settings”, so you know exactly where to make a change.

​
Tips

  • Start permissive and tighten gradually. Because nothing is restricted by default, you can add one rule at a time and watch the Audit log to see its effect.
  • Use Require approval for high-stakes writes (payments, deletions, outbound messages) rather than blocking them outright, so work can still get done with a human in the loop.
  • Prefer Allow only these host lists over Block these when you know exactly which services a workflow should talk to. It’s a tighter default.