SolonGate
Security Gateway for AI Agents
73 followers
Security Gateway for AI Agents
73 followers
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.
This is the 2nd launch from SolonGate. View more
SolonGate
Launched this week
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.
Free Options
Launch Team / Built With
SolonGate
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?
SolonGate
@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
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.
@hazy0 Hello there, that's exactly the framing we landed on, and funnily enough we just shipped it.
Denied actions already land in the same audit store your traces come from, each with the matched rule id, the policy reason, the decision and the eval time, so you can pipe them straight into whatever observability stack you already run.
On top of that we just added a policy drift view: it groups denials by rule over a window and compares it to the previous one, flagging rules that just started firing or whose volume suddenly spiked. So instead of only counting failed tool calls, you can actually alert on a rule that's drifting.
The reason and matched rule id are stable per rule today. Making the triggering layer a first class field (authorization vs rule vs risk) is our next
step, so you'll be able to slice telemetry by layer too. Right now the cloud build is the policy layer; the risk and judge layers are coming.
Would genuinely love to see what this looks like once you pipe denials into your trace store. That's the exact workflow we're optimizing for.
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?
Hello Luca. Both, and that's exactly the point. SolonGate sits at the execution layer, so every tool call gets evaluated against policy in real time rather than trusting the agent's identity once at login.
Per action: each call is checked against deterministic rules covering the tool, the permission, and constraints on paths, commands, filenames and URLs. You can default to deny, whitelist only what's needed, and route specific actions to human approval.
Role scoped: rules also gate by trust tier (untrusted, verified, trusted) and permission scope (read, write, execute, network), so the agent's role decides what it can even attempt.
On blast radius specifically: instead of handing the agent a standing key, an allowed action receives a short lived capability token scoped to that exact permission and tool. The real secret stays behind the gateway, so the agent never holds broad persistent access. Every decision, allow or block, which rule fired and why, lands in the audit log.
So you get the granularity of per action control with the manageability of roles, instead of having to choose one.
best product ever (i made it)