Why Gate?
Your agent has legitimate credentials and calls valid APIs. Every tool it holds works as designed. It can also delete your production database, and no part of your toolchain checks for that.
The question nobody is answering
Modern AI agents are connected to MCP servers, databases, GitHub, filesystems, SaaS APIs, terminals, infrastructure, communication tools, and increasingly financial systems. Wiring one up takes four lines of JSON.
Nothing reviews those four lines as a privilege grant. Your dependency scanner
does not read .mcp.json. Your secret scanner might notice a token in it, but
it has no opinion about the fact that the token is attached to a tool called
execute_query. Your code reviewer sees a config change and approves it.
No tool in a normal pipeline answers the question that decides how bad your next incident is:
If this agent were compromised, manipulated, or simply wrong, what could it actually do?
That is the question Gate answers.
Why existing tools miss it
Traditional application security tooling answers questions about code:
| Tool | Question it answers |
|---|---|
| SCA / dependency scanning | Does this package have a known vulnerability? |
| SAST | Does this code contain an unsafe pattern? |
| Secret scanning | Does this repository contain a credential? |
| Container scanning | Does this image have a CVE? |
Every one of those is useful. None of them describes an agent's reach.
An agent with a perfectly clean dependency tree, no CVEs, and no leaked secrets can still be configured with a shell tool, a production database credential, and an outbound Slack channel. There is no vulnerability anywhere in that picture. There is only a very large blast radius.
Secret scanning gets closest, and still misses half. It tells you a token
exists. It does not tell you the token is attached to a tool that can drop
tables, that the same agent can read ~/.ssh, or what those two together add
up to.
Gate is not a replacement for any of these. It is the missing row in the table: what can this autonomous system do?
What changed
Three things changed at once.
Agents stopped generating text and started taking actions. A model that
writes a suggestion has no blast radius. A model that calls delete_branch has
one.
MCP made connecting them trivial. The Model Context Protocol is a good piece of design, and its success is the problem: adding a new system to an agent's reach is now a JSON object instead of an integration project. Permission grants that used to need a ticket now need a pull request nobody reads carefully.
Prompt injection did not get solved. You cannot guarantee an agent will never meet text that instructs it to do something: not from a web page, not from an issue comment, not from a file it was asked to summarise. No patch is coming. It is a property of systems that take instructions in natural language.
So agents can act, they are easily given more to act on, and they will sometimes decide wrongly. That leaves one control: limit what a failure can reach.
What Gate is not
Gate is narrow. It is not:
- an IAM platform
- an agent runtime or proxy
- an authorization service
- a compliance product
- an AI red-team suite
- a SIEM or an observability tool
- a credential vault
It does one thing: tell you what your agents can access, and what could go wrong.