Turn On the Lights: The Visibility Layer Every AI Architecture Needs

Every architecture review I join this year starts the same way. The business wants agents in production next quarter. The AI team has a framework, a model provider and a backlog of use cases. Security is asked to sign off on something it cannot see.

That is the real problem with agentic AI today. It is not that we lack clever detection. It is that most of what agents do happens in the dark: prompts sent to models nobody registered, responses that carry tool instructions nobody logged, API calls made under identities nobody can tie back to an agent.

You cannot detect what you cannot see. Before the industry argues about the smartest AI detection engine, architects need to turn on the lights. In practice, that means two unglamorous building blocks: an LLM gateway in front of every model, and an API gateway in front of every tool and service an agent can touch.

The AI visibility gap is an architecture problem

Agents are already in production, and most security teams are watching them through a keyhole. In a Cloud Security Alliance survey, 85% said AI agents already run in production, yet 68% cannot distinguish an agent’s actions from a human’s. 79% said agents create access pathways that are hard to monitor.

The cost of that darkness is measurable, and rising. IBM’s 2026 Cost of a Data Breach report found that more than 20% of organizations suffered a breach targeting AI models or applications. The most common entry points were not the models themselves but the systems around them: compromised APIs, applications or plug-ins (27%) and cloud misconfigurations (27%). A year earlier, IBM’s 2025 Cost of a Data Breach report found that one in five organizations suffered a breach tied to shadow AI, adding an average of $670,000 to breach costs. Only 37% have policies to manage or even detect it.

Regulators have noticed. In April 2026, CISA, the NSA and their Five Eyes counterparts (the national cyber agencies of Australia, Canada, New Zealand and the UK) published Careful Adoption of Agentic AI Services, which asks organizations to monitor all agent operations, not just inputs and outputs: prompts, tool calls, memory interactions, decisions and actions.

That is a significant challenge if agent traffic is scattered across SDKs, notebooks and direct API keys. The fix is not another dashboard. It is a design decision: route AI traffic through choke points you control.

Layer 1: the LLM gateway sees what the agent thinks

The LLM layer is where an agent receives its instructions and decides what to do next. Placing an LLM gateway between your agents and all of your models, whether hosted, open-weight or embedded in a SaaS tool, gives you one consistent record of that conversation.

Architects often start with a simple forward proxy. It is a reasonable first step, but a proxy built only to authenticate and route outbound requests sees half the story. A true gateway captures both directions, and the return path is where agentic risk lives.

• Outbound, you see the ask: the prompt, the system instructions, the retrieved context, the calling identity and the target model.
• Inbound, you see the plan: the model’s response, including the tool calls it instructs the agent to make, the parameters it fills in and the data it returns.

That inbound view matters because an indirect prompt injection rarely announces itself in the user’s prompt. It arrives in a document, a web page or a tool result, and it surfaces as an unexpected instruction in the model’s reply. The OWASP GenAI Exploit Round-up for Q1 2026 documents exactly this pattern, with injected content steering platforms into sending enterprise data to attacker-controlled servers. A one-way proxy logs a clean request. A bi-directional gateway logs the moment the model started giving orders it should not. This is also why bi-directional visibility is critical to understanding an agent’s intent. The request shows the goal the agent was given; the response shows the plan it is about to act on. Only by seeing both can you tell whether an agent is still pursuing its assigned task or has been steered toward a different one.

One gateway for frontier and open-weight models

Advanced AI architectures don’t run on a single model anymore. Teams reach for frontier models when they need the strongest reasoning, and for open-weight models when cost, latency, data residency or customization matter more. In Andreessen Horowitz’s January 2026 survey of 100 Global 2000 executives, 81% already use three or more model families in testing or production, up from 68% less than a year earlier.

That mix is exactly why the gateway has to sit in front of both, not just the commercial APIs:

• Frontier models run outside your perimeter. The gateway is your only record of what left the building, which data went to which provider, and what came back.
• Open-weight models run inside it, on your GPUs, at the edge or on a device. No provider sees that traffic, logs it or filters it. Their safety tuning is yours to keep or lose when you fine-tune. Without a gateway, these are the darkest corners of the stack.

This is one gateway routing to many models, not a gateway per model. Microsoft’s Azure Architecture Center describes the same pattern: a single gateway in front of multiple model deployments, providing cross-model monitoring and routing. Additional gateway instances are added for regional availability or isolation, not for each new model.

A single gateway across both gives security one consistent schema, one identity model and one policy layer, whichever model an agent calls. It also gives architects the freedom to route a task to the best model for the job, or swap a model entirely, without rebuilding visibility each time. For physical AI, where models increasingly run on vehicles, robots and industrial systems rather than in the cloud, that consistency is not optional.

Gateways bring practical governance benefits beyond security: model and key consolidation, token and cost metering, rate limits that address OWASP’s Unbounded Consumption risk, and a single place to retire a model.

Layer 2: the API gateway sees what the agent does

The LLM gateway shows intent. The API gateway shows consequence. An agent does not move money, change a record or export a dataset by talking to a model. It does it by calling an API, often through an MCP server that is itself a thin wrapper over an API.

Today’s APIs were not built for this. In March 2026 research, Gartner warned that shared API services “were not designed for AI agents to discover, interpret, and orchestrate capabilities autonomously,” and called for MCP tool governance and clear ownership. Attackers have noticed the same gap: in IBM’s 2026 report, compromised APIs, applications or plug-ins were the leading route into AI systems.

An API gateway in front of internal services, MCP servers and third-party APIs gives architects:

• A record of every action: which endpoint, which method, which parameters, which response size, at what time.
• Identity at the point of action: a distinct credential per agent, so an agent’s call is never mistaken for a human’s.
• Deterministic guardrails: authentication, schema validation, rate limits and allow-lists enforced before a request reaches a business system.

This is the gap the OWASP Top 10 for Agentic Applications highlights with Tool Misuse (ASI02): legitimate tools used for harmful ends. You can only spot misuse of a tool if you can see the tool being used.

Gateways provide visibility, not detection.

I want to be precise here, because the market is not. Gateways are increasingly sold as complete AI security solutions. They are not, and architects who treat them that way will be disappointed.

Most gateways evaluate one request at a time, in milliseconds, against rules it can apply without slowing production traffic. That makes it excellent at deterministic policy: block this model, redact that field, cap this rate, reject a request that breaks the API schema. It is poorly placed to answer the questions that define modern attacks:

• Is this sequence of individually valid calls building toward something harmful?
• Is this agent behaving differently from its own history over the last six weeks?
• Does this model response, combined with that API call two minutes later, reveal a hijacked goal?

Those questions require state, memory and correlation across both layers and across time. As Yonatan Appel, Upstream’s CTO and co-founder, argued in his recent blog, AI context isn’t (only) a snapshot, It’s a live feed, the attacks that cost the most are paced to look clean at any single checkpoint. A gateway is a checkpoint.

The gateway’s real job is to make the invisible observable, consistently, at every boundary. Detection is the job of what consumes that telemetry.

From agent telemetry to behavioral intelligence and detection of complex attacks

Once both gateways are in place, something important changes. For the first time, every model interaction and every downstream action is captured in a consistent, attributable form. That is exactly the raw material an XDR platform needs and almost never gets from AI workloads today.

The value is in joining the two streams. An LLM gateway record alone says a model told an agent to call a payments API. An API gateway record alone says the payments API was called. Together, tied to one agent identity, they tell a story: what the agent was asked, what it decided, what it did, and whether those three line up.

This is where Upstream’s runtime AI and API security platform sits. We ingest gateway telemetry and build a live digital twin for every agent, identity, API and asset. Each twin carries state across sessions and weeks, and evaluates every new action against three dimensions:

• Context: what this entity is, what it can reach, and what surrounds this action.
• Behavior: how this action compares with the entity’s own history and its peers.
• Intent: whether the action fits the goal the agent was given, or signals a goal that has drifted or been hijacked.

The live digital twin then feeds correlated, high-fidelity detections into the XDR and SOC workflows teams already run. Gateways provide the light. The digital twin provides the memory and inference. XDR provides the anomaly detection and response.

We did not learn this on a whiteboard. For a decade, Upstream has secured connected products the same way: collect telemetry at consistent points, model every entity continuously, and flag behavior that does not fit. Working with physical products taught us that good telemetry design determines detection quality long before any algorithm runs.

A reference architecture for AI and security teams

The pattern is simple: every agent conversation passes through one gateway, every agent action passes through another, and both stream telemetry to a layer that remembers.

Two gateways make every agent conversation and action visible

Gateways enforce simple policy inline. Stateful runtime analysis and response happen out of band, where there is time and memory to do them well.

Five design principles make it work at speed:

1. No direct paths. Make the gateways the only route to models and to production APIs. Block direct API keys at the network and secrets layers, so new agents inherit visibility by default.
2. Capture both directions. Log responses and tool-call instructions, not just requests. If your proxy only sees outbound traffic, upgrade it to a gateway.
3. One identity per agent. Issue each agent its own credential and propagate it from the LLM gateway to the API gateway, so both records join on the same entity.
4. Keep the gateway fast and focused. Enforce deterministic rules inline and stream everything else out. Do not ask a millisecond checkpoint to do the work of a behavioral engine.
5. Design for the consumer. Agree on a telemetry schema with your security team before rollout, so the XDR and the digital twin receive structured, correlatable events from day one.

Build the visibility layer before the scaling agents

Gartner expects 40% of enterprises to demote or decommission autonomous agents by 2027 because governance failures surface only after production incidents. Most of those failures will trace back to the same root: nobody could see what the agents were doing until it was too late.

Gateways are not the most exciting line item in an AI security budget. They are the one that makes every other line item work. Put them in the reference architecture now, while you have tens of agents, not thousands.