> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spojit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Governance

> Control what your AI agents and workflows are allowed to do: which tools they can use, which hosts they can reach, and which actions need a human's approval.

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.

<Note>
  Only **Owner** and **Admin** roles can configure workspace governance. Per-connection permissions can also be set by anyone who can edit that connection.
</Note>

## 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](/platform/settings#audit-logs).

## 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:

| Class           | What it covers                                                                   |
| --------------- | -------------------------------------------------------------------------------- |
| **Read**        | Looking things up: search, get, list. Safe to run freely.                        |
| **Write**       | Creating, updating, or sending: create a record, update a price, send a message. |
| **Destructive** | Deleting or removing: delete, remove, purge.                                     |

For **Write** and **Destructive**, pick one of:

| Setting              | Behaviour                                                                   |
| -------------------- | --------------------------------------------------------------------------- |
| **Allow**            | The agent may use these tools without interruption.                         |
| **Require approval** | The run pauses and waits for a person to approve before the action happens. |
| **Block**            | The agent may never use these tools.                                        |

<Tip>
  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.
</Tip>

### Destination hosts

For tools that fetch a URL (such as the **HTTP Requests** connector), you can control which external hosts an agent may reach:

| Setting              | Behaviour                                                             |
| -------------------- | --------------------------------------------------------------------- |
| **No restriction**   | Agents may reach any host (default).                                  |
| **Allow only these** | Agents may reach only the hosts you list. Everything else is blocked. |
| **Block these**      | Agents may reach anything except the hosts you list.                  |

List one host per line. Wildcards are supported, for example `*.example.com`.

<Note>
  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.
</Note>

### Approvers

When you set a class to **Require approval**, choose who can approve. Approvers work the same way as the [Human approval node](/workflow-editor/nodes/human): 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](#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:

| Setting                                | Options                                      | Default                |
| -------------------------------------- | -------------------------------------------- | ---------------------- |
| **A tool is blocked**                  | Let the agent continue, or Stop the workflow | Let the agent continue |
| **An approval is rejected or expires** | Stop the workflow, or Let the agent continue | Stop the workflow      |

* **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](/workflow-editor/nodes/human) 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](#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](/workflow-editor/nodes/human) step (also configurable in [When an action is denied](#when-an-action-is-denied)).

<Tip>
  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.
</Tip>

**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.