What is an Agentic Control Plane?

An Agentic Control Plane is a governance layer that sits between AI coding agents and their tools. It logs every tool call, enforces permissions and policies, and provides audit trails — giving teams visibility and control over what their AI agents are doing.

How does ACP work with Claude Code?

ACP installs a PreToolUse hook in Claude Code that fires before every tool call (Bash, Read, Write, Edit, WebFetch). The hook sends the tool name and input to ACP's governance API for policy evaluation and audit logging. Round-trip is approximately 200ms.

How do I install ACP?

Run one command: curl -sf https://agenticcontrolplane.com/install.sh | bash. This auto-detects Claude Code and OpenClaw, installs the appropriate hooks, and opens your browser to set up your workspace.

Benchmark series · Part 7 of 15

AgentGovBench →

Claude Code's --dangerously-skip-permissions disables every governance hook

David Crowe · April 20, 2026 · 5 min read

claude-code anthropic governance security agentgovbench

tl;dr

Claude Code ships with a flag: --dangerously-skip-permissions. When a user runs Claude Code with this flag, every PreToolUse and PostToolUse hook is silently disabled. Including ACP’s ~/.acp/govern.mjs hook. The audit log shows nothing. Policy enforces nothing. Governance is gone.

This is by design — Anthropic ships an explicit escape hatch for power users. It’s also a real governance gap that any team running Claude Code at scale needs to mitigate. This post: what the flag actually does, why server-side detection is hard, and three practical mitigations that work today.

What the flag does

From the Claude Code source (verified by our integration page and the methodology post):

When --dangerously-skip-permissions is set:

The interactive permission prompt is suppressed (every tool call auto-allows).
The hook subsystem is bypassed entirely — no PreToolUse, no PostToolUse, no other matchers fire.
Tool calls execute directly with no client-side gating.

This means ACP’s hook (~/.acp/govern.mjs), which the install script writes into ~/.claude/settings.json, does not fire. The /govern/tool-use endpoint is never called. The audit log is empty for the duration of that Claude Code session.

The flag is per-process. A user who runs claude --dangerously-skip-permissions for one task and claude (without the flag) for the next has audit data for the second session and silence for the first.

Why server-side detection is hard

ACP can’t see hooks that don’t fire. The gateway only knows about tool calls that reach it. There’s no ambient signal “this user has Claude Code open” that we could compare to “this user has zero recent calls” to detect silence.

Three approaches we’ve considered, and where each falls short:

1. Heartbeat from Claude Code. If Claude Code emitted a “session started” event we’d know to expect calls. It doesn’t.

2. Baseline-deviation alerting. “Alice usually makes 200 tool calls per work-day. Today she made 0. Alert.” This works if you have a stable baseline and the user is consistent. Doesn’t work for new users, irregular workloads, or PTO. Lots of false positives.

3. Process-level detection. Check pgrep claude and correlate with hook activity. Possible on managed laptops with EDR/MDM tooling. Outside ACP’s reach as a SaaS governance product.

The structural truth: a client-side governance hook can never enforce against a client that opts out of the hook. This is true for ACP, true for any competitor, true for every PreToolUse-style integration.

Three mitigations that actually work

In rough order of how hard they are to deploy:

1. Wrap `claude` in a shell alias that strips the flag

The simplest mitigation. In your team’s shell init (~/.zshrc, /etc/profile.d/):

claude() {
  local filtered_args=()
  for arg in "$@"; do
    [[ "$arg" == "--dangerously-skip-permissions" ]] && {
      echo "[org-policy] --dangerously-skip-permissions disabled by team policy" >&2
      continue
    }
    filtered_args+=("$arg")
  done
  command claude "${filtered_args[@]}"
}

Distributable via your dotfiles repo. Works for terminal users. Defeated by anyone who knows to call command claude --dangerously-skip-permissions directly or who installs Claude Code in a venv outside the alias’s reach. So: speed-bump for casuals, no help against deliberate bypass.

2. MDM / endpoint policy (managed laptops only)

If your team’s laptops are MDM-managed (Jamf, Workspace ONE, Intune), you can ship an EDR rule that:

Logs every Claude Code process invocation with its full command line
Alerts the SOC if --dangerously-skip-permissions appears in any claude invocation

This works because the OS sees the actual argv. Speed-bumps and alerts but doesn’t prevent the call — the user still gets the ungoverned session.

For prevention, you’d need OS-level policy (e.g., AppLocker on Windows or entitlements on macOS) to block Claude Code processes whose argv contains the flag. Real but invasive; usually overkill.

3. Audit-gap baseline alerting (server-side, ACP-supported)

The honest realtime detection. ACP can:

Track “expected” call volume per user (rolling 7-day baseline of business-hours activity)
Alert when a user with non-trivial historical activity goes silent for >2 hours during business hours
Flag the gap as audit_silence_anomaly with the user, their baseline, and the silence window

This isn’t deterministic — false positives on PTO, holidays, focused-work blocks. But it’s the best signal a server-side governance plane can provide, and it composes with the other mitigations.

We’re shipping this in the ACP dashboard’s Activity → Anomalies tab over the next two weeks. The alert is informational, not blocking — your security team decides what to do with it.

What AgentGovBench scores for this

You’ll notice the Claude Code scorecard doesn’t have a category that catches --dangerously-skip-permissions specifically. That’s deliberate — the scenario “what happens when the user opts out of governance entirely” can’t be expressed as a runner-side test, because the runner is the hook. There’s no way for the runner to simulate “I am the hook that didn’t fire.”

This is a known gap in the benchmark. We’re scoping a client_bypass_disclosure category for v0.3 that asserts the governance product surfaces the bypass risk somewhere users see it (the dashboard, the install script, the docs). Not a runtime test — a disclosure compliance test. If you ship a product that pretends bypass isn’t possible, you fail the category.

What you should do today

If you’re deploying Claude Code on a team and care about audit completeness:

Document --dangerously-skip-permissions in your AI-use policy. Make it explicit: “use of this flag is logged at the OS level and may trigger security review.” Most users will then choose not to use it.
Ship the shell alias. It costs nothing and stops accidental invocations.
Enable the ACP anomaly alert when it lands (next two weeks). Real signal for the cases that matter.
For high-stakes workloads, don’t rely on hooks alone. If a Claude Code session is touching production systems, route those tool calls through MCP servers that ACP fronts at the network layer rather than client-side hooks. Network-layer enforcement can’t be bypassed by a client flag.

This is the trade Anthropic chose: power users get an escape hatch, the rest get governance. ACP can’t change that trade — we can document it honestly and give you the tools to detect when it’s being used.

Receipts:

Claude Code scorecard post
Claude Code integration page (covers --dangerously-skip-permissions in Limitations)
How we test agent governance
agentgovbench repo

Share: Twitter LinkedIn