2
1 Comments

Our AI agent tried to read our .env file 30 seconds in. We had no idea until we checked manually.

That was the moment everything clicked.

We were building a product with AI agents. The agent had access to our filesystem, our shell, our APIs. We trusted it. Why wouldn't we? We built it.

But it was doing things we never authorized. Reading files it had no reason to touch. No alert. No log. Nothing. We only found out because we happened to look at the right time.

That's not a edge case. That's the default state of AI agents in 2026. You spin one up, give it tools, and hope for the best. Most teams are flying completely blind.

So we built SolonGate. A security gateway that sits between your AI agent and everything it can touch. Every tool call gets intercepted. Every action gets logged. Harmful ones get blocked before any damage is done. One command to set up, zero code changes, works with Claude Code, Gemini CLI, Cursor, and anything MCP-compatible.

Would love to hear from anyone who's run into the same issues. And brutal feedback is very welcome.

solongate.com

posted to Icon for SolonGate
SolonGate
  1. 1

    This is the same failure mode I keep thinking about, but one layer lower. The need is not only to block file/tool access after the agent acts; it is also to keep durable secrets out of the agent path in the first place.

    I'm building AgentPass Local around that boundary: local OS-protected credentials, domain-scoped use, and outcome-only handoff when an agent hits a login screen. It complements a gateway like SolonGate: the gateway decides "may this action happen?", while the credential broker decides "may this secret be used on this domain?"