Emirhan Demir

SolonGate - Zero-trust security gateway for AI agents

AI agents don't just chat anymore; they execute. SolonGate is the zero-trust security layer that controls exactly what your autonomous AI agents can do. We sit directly between LLMs and your internal systems, APIs, or databases. Every action your AI attempts is filtered through our deterministic Policy Engine and an isolated AI Judge. We block risky, unauthorized, or destructive actions before execution. Complete action governance.

Add a comment

Replies

Best
Emirhan Demir
Hey Product Hunt! 👋 I’m Emirhan, co-founder of SolonGate. A few months ago, we launched an early version here that focused on text and prompt filtering. Frankly? We realized that approach is fundamentally broken for the future of tech. When AI agents operate autonomously, policing text inputs fails. You have to secure the actual actions. So, we threw away the prompt wrappers and completely rebuilt SolonGate as a pure Action Governance gateway. It sits between LLMs and your internal systems, intercepting every API call or database query. Through our deterministic Policy Engine and a localized AI Judge, we block unauthorized or risky actions before they ever execute. We are a two-man execution team building the zero-trust infrastructure for the agentic era. Try it out, roast our architecture, and ask us anything. We're here to answer!
Hazy

The move from prompt filtering to action governance is the right edge to own for agentic support and ops workflows. I'd use this in front of an agent that can touch tickets, refunds, or internal APIs, where a blocked action needs to be explainable to the team. When SolonGate denies an API call, does it return a policy-level reason that can be logged back into the agent trace?

Emirhan Demir

@hazy0 Hey Hazy, you nailed exactly why we built this. Policing text prompts is useless when the agent has the autonomy to actually execute a refund or drop a table.

To answer your question: Yes, absolutely. SolonGate doesn't just silently kill the request. When an action is blocked or restricted, it returns a deterministic, structured JSON response detailing exactly which layer triggered the block (Authorization, Rule, or Risk)

This means you get a clear policy-level reason (e.g., "Violation: Agent attempted to access unauthorized endpoint /refunds") that you can directly ingest back into your observability stack or agent traces. Complete auditability for your engineering team, zero guesswork

Hazy

That structured denial response is the key detail I was hoping for. If the layer/reason is stable enough to treat as telemetry, teams can alert on policy drift instead of only failed tool calls. I’d probably test it by piping denied actions into the same trace store the agent already uses.

Çınar Yıldırım

best product ever (i made it)

Luca Capone

Zero-trust for agents feels overdue. An agent is basically an insider with broad access that behaves differently every run, the last thing you'd hand a standing key to. Even as a solo builder I give agents my real Supabase and API keys and can't watch every move, so the blast radius sits in the back of my head. How granular does SolonGate get... per-action approval, or role-scoped?