Aegis-control - Policy enforcement for LLM tool calls.

AI agents don't just generate text anymore — they call tools. They query databases, hit APIs. And right now, almost nobody is governing what those tools can actually do. Aegis Control sits in your LLM request path and enforces policies on tool calls — before they execute. Platform and security teams shipping LLM agents to production who need more than a dashboard. If you're running agents with real tool access, and you need to control and audit what those tools can do, Aegis is for you.

Hey Product Hunt 👋 I built Aegis Control after noticing a gap that nobody seemed to be talking about. Everyone is building LLM agents. Everyone is giving those agents tools — real tools with real consequences. But the entire ecosystem is focused on observability: dashboards, trace viewers, cost trackers. You can see everything that happened. You can't stop anything. Aegis is the enforcement layer that's been missing. It's not another observability platform. It doesn't compete with Langfuse or Helicone — it actually integrates with them. Aegis governs, they visualize. The core idea is simple: treat tool calls as first-class governed objects. Version their schemas. Attach policies to them. Enforce those policies at execution time — not after the fact. In practice that means: A execute_code tool that can never run bash, regardless of what the LLM wants A send_email tool that's blocked entirely in staging environments A query_database tool that's allowed, but only for read operations I'm launching the public beta today with the OpenAI-compatible proxy, OPA policy engine, and a Mastra framework adapter. LangChain and Vercel AI SDK adapters are coming next. Would love feedback from anyone building agents in production — especially around what governance problems are actually painful for your team. Happy to answer any questions below.

Aegis-control - Policy enforcement for LLM tool calls.

Replies