Launching today
Lunen.ai
Build AI agents your whole team can run, and control
124 followers
Build AI agents your whole team can run, and control
124 followers
You've used ChatGPT and Claude for real work. They just do the task. No record of what they touched, no approval on the risky step, nothing you could hand your security team. Great UX, zero governance. Enterprise tools flip it: total control, an interface nobody wants to open. Lunen is what automated AI should be, the clean UX and the full transparency, not one or the other. Now in early access.
Lunen.ai
The "2FA checkpoint" framing for risky calls is the interesting part to me. Most agent tools either gate everything behind a human click or trust the model fully — you're doing something in between. How is the read vs. write / auto-allow vs. approve line actually drawn? Is that a threshold an admin configures per tool/data source, or does Lunen infer it from the action type itself? And for scheduled agents running unattended — if a write needs approval and nobody's there to click it, does it just sit and wait, or fall back to a pre-set policy?
Lunen.ai
@tarandeep_singh11 great question, every agent in Lunen gets a policy. It can be you building the policy per agent, or your admin configuring them for you. We made the policy engine flexible for authoring and narrowed to the tool level for most granularity for least privilege access required. We designed it this way so Lunen can fit into your organizations standard practice for policy decisions, as well so a non-technical user can easily build agents with the support of their own teams.
For scheduled agents, if any action reaches a policy where the effect is approval, the agent will simply pause until proper permission is granted.
Would love to see a side-by-side replay of the agent's exact tool calls with diffs against what it intended to do, makes post-hoc review way easier when something feels off.
Lunen.ai
@fakkelek20444 thanks for the comment! When you're building an agent in Lunen, we craft an exact execution plan with detailed tool calls which you see in the blueprint on the right-side panel in the UI. This makes it easy to keep track of the final plan while chatting with Lunen in plain language. On post run, you can see per-session details on what the agent did against the plan for exactly that kind of debugging. We put a lot of effort into our execution, including wrapping your plan in a DAG. Tool drift is always a risk though with any dynamic server and so this kind of UI can be very helpful!
Congrats on the launch, Mike. The control layer is the part most agent builders skip, and it is the first thing a regulated buyer asks about. I run a HIPAA-compliant AI suite for clinicians, and "who can run what, with which data" is half of every security review we go through. How granular do the permissions get, can an admin scope which data sources an agent touches per team member? And can the audit log be exported to hand to a compliance team during a review?
Lunen.ai
@clemente_lopez1 Hey! Permissions can be scoped to the connected service via MCP as well as each individual tool call that MCP service offers. Everything is explicitly denied by default, so you select what is allowed, and what requires approval. This can all be configured for which specific user is allowed to build agents with which specific policy. Yes, audit logs can be exported absolutely!
The approve-the-risky-step checkpoint is exactly what's missing from most agent tools — they fire and you reconstruct what happened afterward. Before wiring this into a real workflow I'd want to know where the action record actually lives: a hosted store only, or something I can export or self-host to hand the security team? And is the approval gate rule-based per action type, or does a human get pinged on every write?
Lunen.ai
@noctis06 Great questions, the audit record can be exported absolutely. And the approval gate is entirely up to you, you can scope is as narrow as each individual tool type on an specific MCP service. This allows you to determine what is a gated rule versus what's allowed. We designed it this way because context matters, and no two agents are the same risk level.
@mikerudolph Per-tool-type scoping per MCP service is the right granularity — that is the knob that lets me auto-allow reads and gate writes without babysitting every call. The thing I would check next: does the exported audit record capture the approval decision itself — who or what approved, and which rule matched — or just the action that ran? For a security review the decision trail matters more than the action log.
One thing that would help my team a lot is a side-by-side replay viewer that shows what the agent did step by step with diffs, so I can review an overnight run in a few minutes instead of digging through logs. That kind of timeline with redo and undo per step would make the whole governance story actually usable day to day.
Lunen.ai
@cafermqyf thanks for the comment! You can fully see the session as it played out in our UI in an exact timeline view, but we haven't figured out redo/undo at the step level yet. That's a very cool thought!
Having built self-hosted MCP agents, governance is always the bottleneck: defining unattended vs. human-in-the-loop actions and auditing the aftermath. You can ignore this solo, but it kills enterprise adoption.
The "allow reads, approve writes" approach with unified audit logs targets this perfectly, though I'm curious if it survives a real security review.
For anyone running agents in production: where do you draw the line for human intervention? That’s the boundary I find hardest to define.