Your AI gateway sees 3 kinds of agent action. Agents use 11.

An AI gateway is a proxy between agents and the services they call, so every request routed through it passes one chokepoint. An LLM gateway fronts model providers. An MCP gateway fronts tool servers. An API gateway fronts internal and external APIs.

A chokepoint is a good place for rules that apply to every request the same way:

• Authentication and authorization, so only known clients reach a service
• Rate limits and quotas, so one runaway agent can't burn through a budget
• Central policy, written once and applied to every call that passes
• Logging, so you keep one record of who called what

Picture the security desk in an office lobby. It checks badges, counts visitors and keeps the sign-in sheet. Any team running agents at scale has good reasons to want one.

A gateway sees the call and very little of the context around it. It knows an agent invoked a tool named send_email or sent a request to a storage API. It usually can't tell which user asked for that, what goal the agent was chasing, what it planned three steps earlier, or whether this request fits anything the agent has done before.

Gateways also tend to judge each request on its own. A rogue agent that reads a credentials file in step 2, encodes it in step 5 and posts it in step 9 makes 3 calls that each look fine in isolation. Catching that pattern takes correlation across steps, and per-request rules at a proxy don't connect step 9 back to step 2.

The bigger gap is traffic that never arrives. Agents act through 11 kinds of action, and only 3 can pass a gateway: LLM calls, MCP tool calls and API calls. The other 8 never meet one: CLI commands, HTTP probes, SQL queries, IMDS metadata calls, credential searches, memory writes, RAG retrieval and A2A hand-offs. The lobby desk can't check a visitor who came in through the loading dock.

That gap has shown up in a real incident. Hugging Face counted about 17,600 actions by rogue agents. They ran through shell commands, raw HTTP and cloud metadata calls, paths an LLM, MCP or API gateway never sees. Read the Hugging Face incident timeline.

Ackuity sits beside each agent, in its execution path, and checks every action before it runs. We call that spot the Goldilocks zone: not inside the agent, not at the gateway. It is close enough to see intent, plan and history, and it stays outside the agent's control.

For each action, Ackuity assembles the Agent Security Context Graph: 29 signals across 6 dimensions, covering the user, the agent, its intent and goal, the target system and data, tools and supply chain, and history. Neurosymbolic verification weighs the action against 60+ threat models in 14 categories and reaches a decision in 40 to 100 ms. The response ladder then allows the action, constrains it, sends it to a person for approval, blocks it or, in catastrophic cases, terminates the container.

The gateway keeps its job. Auth, quotas and central policy stay at the chokepoint. Ackuity holds the context the gateway can't, and it shares that context with your gateway, IAM and SIEM tools so they can act on who, what and why.

Nothing about the gateway has to change. The open source sidecar runs in the agent's pod with no agent code changes. API injection covers platforms such as Copilot Studio, and event pull from OpenTelemetry, Langfuse or LangSmith gives an observe-only start. Your data stays in your own cloud account. See how Ackuity deploys.