Re:Show HN: AgentBouncr – Governance layer for AI agents
by Soenke_Cramme on Wednesday February 25, 2026 @11:52AM
(#47154111)
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.
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.