Launched this week
Execlave
The gate between your AI agents and the real world
90 followers
The gate between your AI agents and the real world
90 followers
Execlave is an AI Agent Governance and Enforcement platform (runtime AMP) that sits between autonomous agents and your real systems, enforcing policy before every action instead of after incidents. It gives platform and security teams runtime policy enforcement, kill switches, and audit-ready trails so every agent action is authorized, traceable, and compliant with SOC 2, EU AI Act, ISO 27001, and other enterprise frameworks.
Cloud World Model
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?
Execlave
@mathsociety Great question, Kevin. Two layers today:
Before anything touches real infra, @Execlave test runs an adversarial probe suite straight against the policy engine — privilege escalation attempts, injection payloads, out-of-scope actions — and gates promotion to the autonomous tier on a minimum resilience score (0.9 by default). No real infrastructure needed, so it covers exactly the expensive/risky-to-reproduce cases you're asking about.
Once an agent's live, you can also run it at the "observe" tier — real production traffic, every action evaluated against policy, nothing actually blocked — so you see what would have been stopped before you ever flip enforcement on for real.
Curious how you're thinking about this at Cloud World Model — similar approach, or hitting different walls?
Love the concept. What was the hardest part building this?
Execlave
@barroncaster Honestly, the latency budget. Enforcement runs synchronously in the request path, so if it adds real lag agents feel it and teams just turn it off. Getting policy evaluation down to sub 20ms while still doing more than a naive allow/deny check took a lot of iteration.
Close second was tuning it so it catches real violations without blocking legitimate actions constantly. Too aggressive and nobody keeps it on. Too permissive and it's just theater. That balance took more work than the enforcement mechanism itself.
Voquill
This made me think of DORA. Having governance written down is one thing, but being able to enforce those controls while agents are actually running seems increasingly important.
Execlave
@henry_habib Great connection, Henry, DORA is exactly the kind of framework where this distinction matters most. A written ICT risk policy doesn't help much if you can't show, in the moment, that agents touching production systems actually stayed within scope. That's the gap we're going after: not just documenting what agents are allowed to do, but enforcing and evidencing it while they're actually running. Appreciate you flagging it, definitely a space worth digging into further.
Congrats on the launch! The hard part with agents usually is that you find out about a bad action by reading logs after it already hit a real system, so moving the check to before the action makes sense to me. What happens on the agent's side when something gets blocked? Does it get enough context to retry a different way, or does the run just stop?
Execlave
@alina_petrova3 Thanks, and yes, that's exactly the shift.
On a block the agent gets a structured denial, not a dead end. enforcePolicy returns allowed: false with a violations array, and each violation carries policyId, policyName, policyType, message, and enforcementMode. So the agent knows which control fired and why, enough to reformulate (drop the PII field, use a read-only tool, narrow the scope) and re-submit, rather than just seeing "denied."
Whether the run stops is your choice of integration style. Call enforce directly and you get the result object back to branch on. Use the wrapper and it throws a typed error, PolicyBlockedError carrying the same violations, with subclasses for specific causes (ValidatorDeniedError for a custom-validator denial, ToolIntegrityError for a changed tool descriptor, AgentPausedError for the kill switch). They all extend EnforcementHaltError, and there's an isEnforcementError() helper so your handler can distinguish "governance said no, handle it" from an ordinary runtime failure instead of maintaining its own instanceof list.
Not every violation is a stop, either. warn mode returns the violation as a warning and the action proceeds, which is useful for steering an agent without halting it. require_approval doesn't fail, it returns a pending state with an approvalRequestId the agent polls; approved, it continues.
The honest limit: we give the agent the reason, not the fix. There's no "here's the compliant version of your request", whether the loop can use the denial productively depends on how the agent handles a structured error. In practice, a good message on the policy matters more than people expect.
Execlave
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.
Execlave
@bhaumik_lathiya I found this product very genuine. I think right now everyone is focusing on AI Agents in Production, but only a few are asking the questions related to Governance.
Execlave
@krushil_kotadiya Thanks Krushil, that's exactly the gap we kept seeing. The race is all about getting agents live, and the "what happens when it does something it shouldn't" question gets pushed to later, usually until something goes wrong. Curious, are you seeing agents move into production where you are, and is governance part of that conversation yet, or still an afterthought?
Execlave
Hi Product Hunt — Rishit here.
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.
ProductBridge
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.
Execlave