Skip to main content
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. An Audit rule cannot stop anything, and it cannot be the reason a command was allowed either. Warn is a prompt, not a stop, and what it does depends on the tool: A Warn policy on Cursor or Augment Code never stops anything, and on Codex it stops the command outright rather than asking. If you need the command stopped everywhere, set the action to Block. Where you want a Slack confirmation step, use Require Slack Approval, which goes to the developer by default.
A policy change takes effect immediately and governs every session from then on. Nobody needs to restart their agent or their terminal.

​
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 in the Tool Coverage card. 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. Hooks can also be installed but switched off by your organization’s own Claude settings (disableAllHooks or allowManagedHooksOnly); see check 1.9 in Usage Not Showing Up. A tool also needs a full restart after hooks are first installed.

​
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. Reasons a pattern that looks right still misses:
  • The command landed in a different family. Reading a credential is classified as access_password or environment_exposure, not read_file; TRUNCATE is Database Admin, not Database Write; a force push is recorded as operation push, the same as a plain one. Check the family Unbound actually assigned in Analytics → Agentic Use before assuming the pattern is at fault.
  • The command was never assigned a family. A command Unbound cannot place in a family is allowed rather than blocked, so a family-based rule cannot be relied on to catch one. A Custom-family rule still fires, because it matches the command line itself — that is where to put a rule that has to hold no matter what.
  • The pattern was read as the wrong type. *prod*|*production* is read as regex, not two globs, and is not valid regex — so it matches nothing. Force the reading with glob:, regex: or exact:.

​
5. It happened through the agent’s own file tools

The file families cover an agent’s built-in read, write, edit and delete tools as well as the shell — but which of those tools exist differs per agent. Codex has only a patch tool; Copilot has no delete tool. So a delete_file rule catches Codex deleting with rm and not with its own tooling. If a rule has to hold on every agent, pair it with the shell route or use the Custom family, which covers an agent’s own file actions as well as the shell.

​
6. 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.

​
7. 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 Allow (“Operations run as usual”) — the default — work continues uninterrupted, so a network problem looks exactly like a policy that did not fire. Block stops work instead.

​
8. An MCP policy has lost its service

An MCP policy matches the service it names. If the service column on the policy row is empty, the policy no longer targets anything and quietly matches nothing. Open it, pick the service again, and save.

​
9. A probe policy does not gate its own probe

An MCP Probe policy verifies a connector’s identity by calling one of its tools. Probe gating is a platform-level setting that Unbound turns on for you. If an MCP Probe policy gates nothing, ask support whether it is enabled for your deployment. That tool is never gated by the policy itself. Every other tool on the server is gated normally.

​
10. A custom agent is not calling the hook

Supported tools call Unbound automatically. A custom agent or framework has to do it itself:
  • No valid API key. The call must carry your key as a Bearer token. A call with no key, or with a key Unbound rejects (wrong, rotated or revoked), 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.
  • The tool it reports isn’t one Unbound recognises. Unbound honours a fixed set of coding-tool names — Claude Code, Claude Cowork, Cursor, Copilot, Codex, Augment Code, Pi and OpenClaw. A call reporting anything else is still evaluated, but per-tool behaviour such as how a Warn resolves may not be what you expected.
Tool Policy Hooks carries the full contract — authentication, request and response shapes, and what to do with each decision.
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.

​
11. On Pi, the MCP call did not go through a supported adapter

MCP rules reach pi only for calls made through pi-mcp-adapter, version 2.21.0 or later. An older adapter, or a different MCP extension, makes the call without asking Unbound, and nothing in pi says so. Check the adapter version on the device. Pi lists what is covered.

​
12. The developer is not monitored

On Policies → Users → Individuals, the Monitoring column shows whether a person is monitored. A person who is Not monitored, individually or through a group, has no policies applied and nothing logged. Turning monitoring back on takes up to a minute to apply.

​
Still not blocking

Collect these before contacting support:
  • 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