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

# A Policy Is Not Blocking

> Why an agent still runs a command your policy was meant to stop, and what to check in order

A policy exists, the command still runs. These are the causes, most common first.

## 1. The action is Audit or Warn

**Audit** logs the action and nothing else — there is no user-facing effect by design.

**Warn** is a prompt, not a stop, and what it does depends on the tool:

| Tool                                                                    | What a Warn policy does                 |
| ----------------------------------------------------------------------- | --------------------------------------- |
| **Cursor**                                                              | Allows. The command runs with no prompt |
| **Claude Code**, run headless — a script, CI, a non-interactive session | Allows. There is no prompt to show      |
| **Claude Code**, used interactively                                     | Asks the developer to confirm           |
| **Copilot · Codex · Augment Code · Claude Cowork**                      | Asks the developer to confirm           |
| **OpenClaw**                                                            | Blocks                                  |

Two of those rows are the usual answer. A Warn policy on **Cursor** never stops anything, and a Warn policy meets **headless Claude Code** with nobody to ask, so it allows the command through.

If you need the command stopped everywhere, set the action to **Block**. Where you want a person in the loop without prompting the developer, use **Require Slack Approval**.

<Note>
  A policy change takes effect immediately and governs every session from then on. Nobody needs to restart their agent or their terminal.
</Note>

## 2. Governance hooks are not installed

Discovery and governance install separately. A machine can be fully discovered — its tools listed, its activity reported — while nothing is enforced on it.

Open **Configure** and read **Governance hooks installed** under Tools Reporting. If it is behind your device count, tick **Govern coding agent actions** in step 2 and run the install command again.

The message *No hooks are reporting yet, so no tool is governed* says the same thing.

## 3. The policy does not reach that developer

On the policy list, check two columns:

| Column          | What to look for                                           |
| --------------- | ---------------------------------------------------------- |
| **Status**      | The policy is enabled                                      |
| **User Groups** | The developer's group is listed, or the policy is org-wide |

The fastest check is from the other end: open the developer on **Users**, and read the **Policies** section of their panel. It resolves every policy that reaches them and names the group or org-wide scope bringing each one. If your policy is not in that list, scope is the answer.

## 4. The pattern does not match

A policy fires only when its **Command Family** and **Target Pattern** match what the agent actually ran. Use **Preview Impact** on the policy to see what it would have caught over recent activity. An empty preview means one of two things — the pattern does not match, or nothing matching happened in the window — so check that the command you expect has actually been run recently before rewriting the policy.

## 5. Enforcement is inactive

If your subscription has lapsed, **policy enforcement stops** along with dashboard access. **Subscription Expired** and **Enforcement Inactive** appear in the dashboard when this is the cause.

## 6. Unbound was unreachable and the policy allowed the work through

**Settings → Policy Enforcement** decides what happens when your agents cannot reach the policy engine. On **Operations run as usual** — the default — work continues uninterrupted, so a network problem looks exactly like a policy that did not fire. **Operations are denied** stops work instead.

## 7. A custom agent is not calling the hook

Supported tools call Unbound automatically. A custom agent or framework has to do it itself, and there are three ways that goes wrong:

* **No valid API key.** The call must carry your key as a Bearer token. A call arriving without one is answered with **allow**, so the agent runs unimpeded and nothing appears in your policy history.
* **Only `deny` is handled.** The hook answers with one of four decisions — `allow`, `deny`, `ask` and `approval_required`. An agent that acts on `deny` alone will run straight through work that was meant to wait for the developer's confirmation or for Slack approval.
* **The hook is not called at all.** Policies never see the tool call, so nothing can match it.

[Tool Policy Hooks](/integrations/api-tool-policy-hooks) carries the full contract — authentication, request and response shapes, and what to do with each decision.

<Warning>
  **OACB is a different system.** OACB tiers harden a coding agent's own configuration on one machine; policies govern what agents may do across your organization. The two enforce separately, and `unbound oacb` commands report only on OACB. If your policy is not blocking, OACB is not the place to look.
</Warning>

## Still not blocking

Collect these before contacting support — they are what an engineer will ask for first:

* The policy name, its **Action**, and its **Command Family** and **Target Pattern**
* The exact command the agent ran, and the tool that ran it
* The developer's email, and whether your policy appears in their **Policies** panel
* What **Governance hooks installed** reads on Configure