AI Gateways and AI Agents: Building a Layered AI Security Architecture
In most agentic architectures, the AI Model makes the decision and the AI Agent executes it. A layered defense secures every stage, and it starts at the AI Gateway, before the decision becomes an action.
Part 1 of a series. Part 2 puts this into practice: AI Gateway Telemetry in the SOC, turning gateway events into LogRhythm detections.
Over the past year, AI Agents have become one of the defining topics in enterprise AI. As organizations deploy increasingly autonomous applications, understanding what AI Agents do, including which tools they call, what data they touch, and what actions they take, has rightly become an important part of enterprise security. AI Agent runtime monitoring is a genuinely valuable capability.
At the same time, AI security spans several architectural layers, and the agent is only one of them. So alongside "How do we monitor AI Agents?", it's worth asking a complementary question:
But which layer should we secure first?
This article walks through how AI Gateways, AI Models, AI Agents, Identity, and the SIEM work together as complementary controls in a layered AI security architecture.
How an enterprise AI application actually works
To answer that, it's worth taking a step back and looking at how an enterprise AI application actually works. When a user interacts with an AI-powered application, the request is sent to an AI Model such as ChatGPT, Claude, or Gemini. The AI Model analyzes the request, decides how it should be handled, and, if necessary, instructs an AI Agent to perform actions such as searching SharePoint, updating Salesforce, creating a Jira ticket, or sending an email.
That leads to what I believe is one of the most important observations in enterprise AI security. In most agentic architectures, the division of labor is clear:
The AI Model makes the decision. The AI Agent executes it.
At first glance that distinction may seem subtle, but from a security perspective it's fundamental.
If an attacker successfully manipulates the AI Model, for example through a prompt injection attack, the AI Agent simply carries out the decision it has been given. The attack didn't begin when the AI Agent executed the action; it began much earlier, when the AI Model made the decision. Prompt injection is an attempt to manipulate an AI Model into making the wrong decision.
A real-world example: Amazon Rufus
This isn't theoretical. Security researchers at 0DIN disclosed a guardrail jailbreak against Amazon Rufus, Amazon's generative AI shopping assistant. By encoding the request in ASCII decimal, the payload slipped past the text-based safety filters. The AI Model then decoded the numbers and acted on the hidden instruction, returning restricted content (such as instructions for creating illicit substances) that the guardrails should have blocked.


The attack succeeded not because the agent misbehaved, but because the model was manipulated into making an unsafe decision, and everything downstream faithfully executed it.
Security has always moved to the entry point
For decades, cybersecurity has approached similar challenges by protecting traffic before it reaches its destination. We introduced firewalls before traffic entered the network, secure email gateways before messages reached users, and secure web gateways before users accessed the internet. The first line of defense has traditionally been the point where traffic enters the environment, not where the consequences are observed later.
AI follows exactly the same architectural pattern.

Every request sent to ChatGPT, Claude, Gemini, or another AI Model already passes through an API call. That creates a natural control point where security can be applied consistently across every AI-powered application. An AI Gateway can:
- Inspect prompts and detect prompt injection attempts
- Enforce organizational policies
- Prevent sensitive data from leaving the organization
- Inspect responses before they reach users
- Generate security telemetry
Every one of these checks runs before the AI Model makes a decision.
In my view, that makes the AI Gateway the natural place to establish the first layer of security.
But security doesn't stop there
Protecting the AI Model before it makes a decision is only one part of the story. Once a request has been approved and reaches the AI Model, organizations still need visibility into what happens next. Which tools were called? What actions were performed? What data was accessed? Did the workflow behave as expected?
This is where AI Agent runtime telemetry becomes valuable. The AI Gateway gives visibility into the decision point before actions are executed, and where appropriate, protects it. Runtime telemetry gives visibility into what actually happened after the decision was made. These aren't competing technologies; they answer different security questions and together form complementary layers within a broader AI security architecture.
The same principle should apply in both directions. Just as an AI gateway inspects prompts before they reach the model, an agent's outbound actions (the calls it makes to systems like SharePoint, Salesforce, or email) should be routed through an AI gateway acting as an egress policy enforcement point before they execute. Most designs today only observe those actions through telemetry, but observation cannot stop an action that is already underway. For the gateway to be a genuine control point, this enforcement cannot be optional. In enterprise deployments, AI traffic should not bypass a centrally governed AI gateway: every prompt entering a model and every agent action leaving it should pass through a policy enforcement point capable of inspection, authorization, and auditing.

Where does each control fit?
Beyond asking how we monitor AI Agents, an equally useful question is:
Where does each security control fit within the AI architecture?
In my view, every layer has a distinct responsibility:
- The AI Gateway protects the conversation before the AI Model makes a decision.
- The AI Model (ChatGPT, Claude, or Gemini) makes the decision.
- The AI Agent executes that decision by interacting with enterprise applications and data.
- Identity and Access Management (IAM) determines whether those actions are authorized.
- The SIEM correlates AI events with endpoint, identity, cloud, and network telemetry to determine whether the activity is part of a broader attack.
None of these technologies replaces another. Each answers a different security question, and together they create a layered approach to securing enterprise AI.
As AI adoption continues to accelerate, I believe organizations will move away from thinking about individual AI security products and instead adopt layered AI security architectures, much as we've done with networks, cloud, endpoints, email, web, and identity over the past three decades.
The goal isn't to pick one layer. As enterprise AI matures, organizations will need controls before, during, and after every AI-driven action: the AI Gateway securing the decision, runtime telemetry observing the execution, Identity governing what's permitted, and the SIEM correlating it all against the rest of the enterprise. Each answers a different question, at a different stage of the AI lifecycle.
Secure the decision, observe the execution, correlate the whole.
That is what a layered AI security architecture looks like.
References
- 0DIN Threat Intelligence. Amazon Rufus Guardrail Jailbreak via ASCII Decimal Encoding. Disclosed September 8, 2024.
- OWASP Gen AI Security Project. LLM01:2025 Prompt Injection, OWASP Top 10 for LLM Applications.
Stay updated
New detections, threat hunting notes, and AI security research. No spam, unsubscribe anytime.