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.

Interesting approach. Runtime enforcement is the part most people skip — they focus on logging what happened but don't prevent bad actions in the first place. The policy engine + kill switch combination makes sense for that.

I've been running ~2,400 multi-agent dispatches and came at this from the opposite direction: I started with staging gates (propose → human review → execute) as the runtime layer, then realized I also needed a forensic layer for when things slip through or when I need to understand patterns over time.

Curious about a few things:

- How granular are the JSON policies in practice? I found that "agent X can use tool Y" breaks down fast when agents chain tools in unexpected ways. The sequence matters more than individual permissions. - The hash-chained audit trail — how do you handle schema evolution? After a few months of production, what you want to log changes significantly. Hash chains make adding fields tricky without breaking the chain. - What happens when an agent crashes mid-action? With the hash chain, do you risk a corrupted tail entry that invalidates subsequent verification?

The runtime vs. after-the-fact distinction is important. Ideally you want both — prevent what you can, reconstruct what you couldn't prevent. Nice to see someone tackling the prevention side seriously.

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.

The hash-chained audit trail is a nice touch — append-only logs are underrated for agent governance. Curious how you handle the policy definition UX for teams without security backgrounds. JSON rules are expressive but require knowing what to block in advance. Most developers don't know their risk profile until after something goes wrong — which is part of why I think automated scanning before policy definition matters. Does AgentBouncr have any way to suggest policies based on what tools the agent actually has access to?

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.

The permission control and policy engine angle is interesting, Article 14 (human oversight) explicitly requires the ability for authorized persons to intervene, override, or stop the AI system. Having that built into the agent framework layer makes sense.

One thing I'd think about: how does this map to the documentation requirement? Under Annex IV, you need to document exactly what oversight mechanisms exist, how they work, and under what conditions they activate. The governance layer generates the evidence, but someone still needs to turn it into the structured documentation format that regulators expect.

This is the gap I see across most of the compliance tooling, runtime enforcement tools (like this) and documentation tools (Holistic AI, Annexa, ComplyAct) solve different halves of the problem. The teams that will have the smoothest conformity assessments are the ones connecting both.