A Policy Is Not Blocking

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

​

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: 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 carries the full contract — authentication, request and response shapes, and what to do with each decision.

​

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