Soenke_Cramme

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.

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

Good question — this was actually one of our biggest design challenges. Policy UX: The JSON rules are the developer-facing format (and what the SDK uses). For teams without security backgrounds, the Enterprise Dashboard has a visual Policy Builder where you pick agent, tool, effect (allow/deny/require approval), and conditions from dropdowns. No JSON editing required. We found that CISOs want to read the JSON (it's auditable), but they don't want to write it. Auto-suggesting policies: Yes two mechanisms:

Auto-Discovery: When an agent calls a tool that isn't in its registered toolset, the system registers it automatically and logs it. So you get a live inventory of what tools your agents actually use, without defining anything upfront. Permission Score: This tracks the ratio of allowed tools vs. actually used tools per agent. If an agent has access to 15 tools but regularly uses 3, the score surfaces that. It's the data you need to tighten policies; "this agent is over-permissioned, here's what it actually needs."

So the flow is: deploy agent → auto-discovery builds the tool inventory → Permission Score shows the gap → you write (or click together) a tighter policy based on real usage data. Scan first, then define — which sounds like what you're describing.

Great questions — and 2,400 multi-agent dispatches gives you a perspective most people don't have yet. The staging gates pattern you describe (propose → review → execute) is exactly what our requireApproval effect does on the policy side, so we're thinking about this similarly. On your three questions: Policy granularity / tool chaining: You're right that individual permissions break down with chaining. Today, policies operate per tool-call with 11 condition operators — so you can express "agent X can call approve_payment only if amount < 5000" with param-level checks. But sequence-aware policies ("agent called tool A, therefore tool B should be restricted") aren't there yet. What we do have is the Permission Score, which tracks allowed-vs-actually-used tools per agent over time — that gives you the data to tighten policies iteratively. Sequence-level governance is on the roadmap because you're not the first to raise this. Hash chain schema evolution: Each entry hashes its own content + the previous entry's hash. So when you add new fields to future entries, the chain doesn't break — older entries stay valid with their original schema, newer entries include the additional fields. The chain verifies that no entry was tampered with after the fact, not that all entries have identical schemas. In practice this has worked fine, but I'll admit we're months into production, not years. Mid-action crash: The audit entry records the governance decision, not the tool execution result. It's written before the tool runs — so by the time the agent crashes mid-action, the chain already has a valid entry saying "this tool call was allowed/denied at timestamp T." No corrupted tail. If you need to know whether the tool actually completed, that's the orchestrator's job — we deliberately stay in the governance layer. Your point about wanting both prevention and reconstruction is exactly right. We handle the prevention side; the audit trail gives you reconstruction data, but a full forensic layer on top (like what you built) would complement it well.

Hi HN, I built AgentBouncr because I couldn't find a governance layer for AI agents that actually enforces rules at runtime, rather than just observing what happened after the fact. The problem: AI agents call tools autonomously. Most frameworks (LangChain, CrewAI, Vercel AI SDK) focus on making agents capable — but none of them answer "what is this agent allowed to do?" with deterministic enforcement. AgentBouncr sits between the agent and its tools. Every tool call goes through a policy check before execution. Every decision is logged in a tamper-evident audit trail (SHA-256 hash chain). If something goes wrong, a kill switch stops all agent actions in <100ms. Core components:

Permission Layer — agents can only use tools their policy allows Policy Engine — JSON-based rules with conditions, rate limits, approval workflows Audit Trail — append-only, hash-chained, W3C Trace Context Injection Detection — pattern-based, bilingual (EN/DE), configurable Kill Switch — deterministic, works even when the LLM API is down

Tech: TypeScript, 1,264 tests (671 framework + 593 enterprise), SQLite default (zero config), PostgreSQL for production. Vendor-agnostic — works with any agent framework. The core framework is Source-Available (Elastic License v2) — you can use it, modify it, embed it. The enterprise layer (dashboard, API server, compliance reports) is commercial. I built this as a solo founder. The EU AI Act (enforcement starts August 2026) was the initial motivation, but the governance gap exists globally.

Site: https://agentbouncr.com Code: https://github.com/agentbouncr/agentbouncr npm: npm install @agentbouncr/core

Happy to answer any questions about the architecture, licensing decisions, or the EU AI Act angle.