Most agent frameworks treat governance as an afterthought — log what happened, review it later, hope nothing went wrong. I built the opposite: a middleware that evaluates every tool call before execution and blocks it if the policy says no. After shipping this and getting feedback from people running thousands of multi-agent dispatches, the pattern that keeps coming up is the same: teams build agents, deploy them, something breaks, and then they start thinking about what the agent should have been allowed to do. How it works in practice: An agent wants to call approve_payment with amount: 12000. Before the tool executes, the policy engine checks: is this agent allowed to call this tool with these parameters? The answer is deterministic — no LLM involved, no prompt engineering, just JSON rules evaluated in <5ms. typescriptconst result = await governance.evaluate({ agentId: 'claims-agent', tool: 'approve_payment', params: { amount: 12000 }, }); // result.allowed = false // result.reason = "Payments over 5000 require manual approval" Every decision — allowed or denied — gets recorded in a SHA-256 hash-chained audit trail. If someone tampers with an entry, the chain breaks and verification fails. If something goes seriously wrong, the kill switch blocks all tool calls synchronously in <100ms. Works even when your LLM provider is down, because the governance layer doesn't depend on it. What I learned from production:

Auto-Discovery turned out to be more useful than I expected. Agents call tools you didn't plan for. The system registers unknown tools automatically — so you get a live inventory of what your agents actually do, then tighten policies based on real data instead of guessing upfront. Permission Score (ratio of allowed vs. actually-used tools per agent) surfaces over-permissioning fast. Most agents have access to way more tools than they need. The compound error problem is real. 90% accuracy per step sounds great until you chain 4 steps and you're at 66%. Per-step governance catches failures that end-to-end testing misses.

Stack: TypeScript, 1,264 tests, works with LangChain / Vercel AI SDK / CrewAI / n8n / anything that calls tools via HTTP. Framework-agnostic by design. Source-available under Elastic License v2 (use it, modify it, embed it — just can't offer it as a competing hosted service). Code: https://github.com/agentbouncr/agentbouncr Site: https://agentbouncr.com npm: npm install @agentbouncr/core

Interesting idea. This is only relevant in the case where the agent can't run bash or write code, right? (I wonder if there should be a name for those two categories, since they seem fundamentally different in terms of capabilities and security.)

Good question. It works in both cases, but differently. Agents that can't run bash/write code (most production agents today — they call defined tools like approve_payment, send_email, query_database): The policy engine evaluates each tool call against rules. Straightforward — you know the tool surface, you define what's allowed. Agents that CAN run bash/write code (coding agents, infrastructure agents): This is where it gets interesting. The governance layer treats execute_shell or write_file as tools like any other. You can deny them entirely, or use condition operators to restrict parameters — e.g. path: { startsWith: '/etc/' } → denied, command: { contains: 'rm -rf' } → denied. It's not a sandbox — it's a policy gate before the sandbox. You're right that these are fundamentally different categories. The first has a bounded tool surface. The second has an essentially unbounded one. For unbounded agents, governance shifts from "enumerate what's allowed" to "enumerate what's definitely not allowed" — a denylist approach rather than an allowlist. The policy engine supports both ({ tool: '*', effect: 'allow' } with specific deny rules on top). The naming distinction is interesting. I've been thinking about it as "bounded agents" vs. "generative agents" — the first calls predefined tools, the second generates its own actions. Governance architecture is different for each, but both need it.