A support agent reads a ticket. Buried in the message is a line the customer did not write. The agent does not read it as text, it reads it as an instruction. Eleven seconds later it has exported the customer table, read the payment vault, moved money, and closed the ticket.
Nobody broke in. The agent had every permission it used. Every log line says authorized.
I built Execlave because I have felt this gap firsthand. As a software engineer integrating agents into real systems, I kept watching the same thing happen: the pilot works, everyone is impressed, and then the agent is given access to real data and real tools — and it runs straight into security, compliance and accountability problems that nothing in the stack was built to answer.
Every tool I found watched agents after the fact. Traces, evals, dashboards, all retrospective. None of them could refuse the call. Governance only works if it sits directly in the execution path, so that is where we put it.
Execlave is a runtime gate between your agents and the systems they touch:Enforce — every action is evaluated against your policies before it executes. 20 policy types and four enforcement modes — block, warn, monitor, require_approval. Allow, deny, or hold for a human.Prove — every call, payload and verdict is kept, cryptographically signed and replayable. You reconstruct an incident from the record, not from guesswork.Stop — a kill switch for one agent, a team, or everything, in one click.Report — decisions map to SOC 2 Type II, EU AI Act, ISO 27001, GDPR, HIPAA, PCI DSS and NIST AI RMF as signed evidence, exported in one file.Where it is honest about its limits: a gate is only as good as the policies you give it. We ship 19 types and sensible defaults, but your first week is spent deciding what your agents are actually allowed to do. We would rather say that than pretend it is magic.
There is a free plan for evaluation — one agent, 500 traces, no card — so you can point it at something you built and see the gate work before talking to anyone. It is non-commercial; production starts at $199/mo. Thanks to @fmerian for the hunt.
I am in the comments all day. If you are running agents with production access, I especially want to hear what you have had to block by hand — that is the list we build against next.
PH 用户
Congrats on the launch @bhaumik_lathiya @rishitmavani!
Really interesting problem as agents start taking more actions in real systems. Excited to see this future.
Curious how you test agent behavior before production today, especially scenarios that are difficult, expensive, or risky to reproduce against real infrastructure?
PH 用户
Looks intereting. Congrats team!
PH 用户
Hey Product Hunt! 👋
Maker here. I'm co-founder of @Execlave , and I want to tell you why we actually built this.
The moment it clicked for me wasn't a big breach story. It was how ordinary the failures were.
In conversation after conversation with teams putting agents into production, the same thing kept coming up: nobody was afraid of the model going rogue. They were afraid of the boring stuff.
A permission someone forgot to revoke. A spend limit that lived in a doc but never in the code. An agent that did exactly what its access allowed, at 3am, when no one was watching.
And almost everyone had the same setup: a clear policy, and no way to enforce it on the running agent. They could tell you what the agent was supposed to do. They couldn't stop it when it didn't.
That gap, between the governance people write down and what actually holds at runtime, is what convinced us this is a company and not a feature. As agents start taking real actions inside real systems, "we have a policy" stops being enough. Something has to be able to say no at the moment it matters.
That's the problem we care about.
Two things I'd genuinely love feedback on: if you're running agents in production today, what actually stops yours from doing something it shouldn't right now? And does the "policy on paper vs enforcement at runtime" gap match what you're seeing, or not?
Would love to hear how you're thinking about it.
PH 用户
Really interesting approach to AI agent governance. Putting policy enforcement directly between autonomous agents and real-world systems feels especially important as agents become more capable. The runtime controls and audit trails are a strong combination.
A support agent reads a ticket. Buried in the message is a line the customer did not write. The agent does not read it as text, it reads it as an instruction. Eleven seconds later it has exported the customer table, read the payment vault, moved money, and closed the ticket.
Nobody broke in. The agent had every permission it used. Every log line says authorized.
I built Execlave because I have felt this gap firsthand. As a software engineer integrating agents into real systems, I kept watching the same thing happen: the pilot works, everyone is impressed, and then the agent is given access to real data and real tools — and it runs straight into security, compliance and accountability problems that nothing in the stack was built to answer.
Every tool I found watched agents after the fact. Traces, evals, dashboards, all retrospective. None of them could refuse the call. Governance only works if it sits directly in the execution path, so that is where we put it.
Execlave is a runtime gate between your agents and the systems they touch:Enforce — every action is evaluated against your policies before it executes. 20 policy types and four enforcement modes — block, warn, monitor, require_approval. Allow, deny, or hold for a human.Prove — every call, payload and verdict is kept, cryptographically signed and replayable. You reconstruct an incident from the record, not from guesswork.Stop — a kill switch for one agent, a team, or everything, in one click.Report — decisions map to SOC 2 Type II, EU AI Act, ISO 27001, GDPR, HIPAA, PCI DSS and NIST AI RMF as signed evidence, exported in one file.Where it is honest about its limits: a gate is only as good as the policies you give it. We ship 19 types and sensible defaults, but your first week is spent deciding what your agents are actually allowed to do. We would rather say that than pretend it is magic.
There is a free plan for evaluation — one agent, 500 traces, no card — so you can point it at something you built and see the gate work before talking to anyone. It is non-commercial; production starts at $199/mo. Thanks to @fmerian for the hunt.
I am in the comments all day. If you are running agents with production access, I especially want to hear what you have had to block by hand — that is the list we build against next.
Really interesting problem as agents start taking more actions in real systems. Excited to see this future.
Curious how you test agent behavior before production today, especially scenarios that are difficult, expensive, or risky to reproduce against real infrastructure?
Maker here. I'm co-founder of @Execlave , and I want to tell you why we actually built this.
The moment it clicked for me wasn't a big breach story. It was how ordinary the failures were.
In conversation after conversation with teams putting agents into production, the same thing kept coming up: nobody was afraid of the model going rogue. They were afraid of the boring stuff.
A permission someone forgot to revoke. A spend limit that lived in a doc but never in the code. An agent that did exactly what its access allowed, at 3am, when no one was watching.
And almost everyone had the same setup: a clear policy, and no way to enforce it on the running agent. They could tell you what the agent was supposed to do. They couldn't stop it when it didn't.
That gap, between the governance people write down and what actually holds at runtime, is what convinced us this is a company and not a feature. As agents start taking real actions inside real systems, "we have a policy" stops being enough. Something has to be able to say no at the moment it matters.
That's the problem we care about.
Two things I'd genuinely love feedback on: if you're running agents in production today, what actually stops yours from doing something it shouldn't right now? And does the "policy on paper vs enforcement at runtime" gap match what you're seeing, or not?
Would love to hear how you're thinking about it.