A dashboard isn't agent governance: the case for pre-action gates

A study from the Cloud Security Alliance and Token Security, published in April 2026, found that 65% of organizations had at least one security incident caused by an AI agent in the past year. 61% of those incidents involved sensitive data exposure. 41% resulted in unintended actions across business processes.

If you run coding agents with real tool access — Claude Code, Cursor, Codex, Gemini CLI, Cline — that number should change how you think about "agent governance." Because most of what gets sold as governance today is a dashboard. And a dashboard is the wrong tool for this job.

Detection is not prevention

A dashboard tells you what the agent did. It logs the rm -rf, the leaked key, the force-push to main, the DROP on a production table — and then it shows you a nice timeline of the damage.

The problem is timing. An autonomous agent acts at machine speed. By the time the incident shows up on your dashboard, the bucket is already empty and the key is already in someone's logs. You didn't prevent anything; you generated a postmortem.

Security engineering has a word for the thing that stops a bad action before it happens: a control. That's what's missing from most agent tooling.

"But I have CLAUDE.md / .cursorrules"

Instruction files are useful, but they are suggestions the model can ignore. They live in the prompt, they compete with everything else in context, and a long session or a clever injection routes right around them. They are not enforced. The agent can read "never touch production" and then touch production, and nothing physically stopped it.

What you want is an enforcement boundary that sits between the agent's intent and the executed action — one that doesn't depend on the model choosing to comply.

Where a pre-action gate sits

This is the idea behind a pre-action gate. Concretely, in the agent ecosystem, it's a PreToolUse hook: before any tool call executes, the hook intercepts the command and evaluates it. If it matches a block rule, the call never runs.

The implementation detail that matters for security people: the gate decision should be deterministic and contain no model call. A literal pattern match, then an AST match, then a scoped rule lookup. No LLM on the enforcement path means there is nothing for a prompt injection to negotiate with — you can't jailbreak a regex.

  Agent tries:   aws s3 rm s3://prod-backups --recursive
  Gate:          BLOCKED - before the tool call ran
                 rule: never bulk-delete prod buckets
                 source: your thumbs-down from last week
                 tokens spent on this repeat: 0

That's the whole shape of it: the dangerous call is evaluated and stopped locally, on the machine where the agent runs, with no round-trip to a server and no inference cost on the hot path.

Turning corrections into rules

A static denylist you maintain by hand covers exactly the patterns you remembered to write. The more interesting version is a learning loop.

This is what ThumbGate — an open-source, MIT-licensed, local-first implementation — does. One thumbs-down on a bad agent action becomes a permanent prevention rule. Thumbs-up reinforces good patterns. The rule corpus sharpens from real outcomes instead of requiring you to hand-write a regex for every new mistake shape.

Two things a hand-rolled hook structurally can't do:

1. Cross-agent propagation. A permissions.deny pattern lives in one agent's config and stays there. A gate that distributes over MCP means a thumbs-down once in Cursor blocks the same pattern in Claude Code, Codex, Gemini CLI, and Cline in the next session — no copy-paste between configs.
2. A learning loop. Corrections from any agent harden every agent automatically, and semantically-near patterns get pulled into scope via local CPU-only embeddings (no external API).

Built-in checks cover the usual money-pits out of the box: force-push and protected-branch pushes, .env secret exposure, destructive lock-file edits. You add your own from feedback.

The part compliance people care about

Every gate decision — block, allow, reroute — is written to an audit trail with the rule version and a timestamp. That gives you a record of what the agent tried to do, not just what it did. For regulated workflows, that distinction is the whole game.

Try it

npx thumbgate init   # auto-detects your agent, wires the hooks, ~30 seconds
npx thumbgate capture down "Never run DROP on production tables"

The next time any connected agent tries to run DROP on production, the check fires before the tool call executes.

Where this fits (and where it doesn't)

A pre-action gate is not a replacement for code review, tests, or least-privilege credentials — it's the execution boundary that the rest of your controls assume exists. It's also not a model fine-tuner; it doesn't change weights, it blocks actions. If your agents only ever run in a sandbox with no real side effects, you may not need it yet. The moment they get shell access, deploy rights, or production credentials, the calculus changes.

The honest summary: a better dashboard doesn't make agents more reliable. The hard part isn't visibility — it's the boundary between a generated intent and an executed action. That boundary is where governance actually happens.

Repo (MIT, local-first): https://github.com/IgorGanapolsky/ThumbGate

If your team is giving agents real shell or API access, I'd genuinely like to hear how you're gating it today — what's worked, what's over-fired, what you'd want from an enforcement layer.