This post is adapted from a session we are presenting at the Cybersecurity Summit in Charlotte in October 2026. The talk is written for a room of CISOs. This version keeps the argument and adds the implementation detail an engineering-minded security leader will want before handing it to a team.
We have solved this twice before
In the early 2000s the question was “which websites may our staff visit?” The answer was URL filtering: sort the internet into categories, put a proxy at the edge, and write a policy with three verbs. Allow, block, log. What was new was the web. The path, user to edge to internet, was not.
Ten years later the web turned into applications inside encrypted sessions, on SaaS platforms, from personal devices. A proxy that could see only a domain name was blind. The answer was not a new network. It was teaching the same edge to see a new thing: the application, and its content once decrypted. Application identification, content inspection, data-loss prevention. Same path, same verbs, a new type of inspection.
AI is the third time. The question is longer now: which AI tools and agents, on whose account, carrying what, reaching what? But the enforcement point is the same edge, with an AI application category and, increasingly, an AI gateway function shipped as a feature of the platform you already run. What has to be inspected has changed: a prompt, a model’s response, an agent’s tool call. Where it is inspected has not.
Two things are genuinely new. The content is natural language, which carries data that regex-era inspection never had to classify, and it arrives with files, screenshots, and whole documents as context. The actor is software: an agent with a service account and a set of tools originates requests on its own judgment. Everything else, the path, the edge, the zone, is the network you already operate.
Three lessons from the earlier eras carry straight over. Categories lag reality, so the default posture for the unknown decides the outcome. You cannot inspect what you cannot see; in the 2010s that meant encrypted traffic, today it means personal accounts and unmanaged devices. And outright bans push use underground; sanction-and-inspect beat block-and-hope both times.
The four AI flows
Every enterprise now carries four distinct AI flows. They have different owners, cross different control points, and fail in different ways. The inventory below is the first thing to fill in, and most organizations can complete flows one and four from memory while flows two and three are blank.
| Flow | What it is | Typical owner | Where it is visible |
|---|---|---|---|
| 1. People → AI applications | Browser assistants, SaaS copilots, meeting bots. Often unsanctioned, often on personal accounts on the same domain as the corporate tenant. | Workforce security | The user edge: SSE, secure web gateway, SASE |
| 2. Applications → model APIs | Product features and internal tools calling hosted models with an API key. Built by developers, rarely inventoried by security. | Cloud and application security | Data-center and cloud egress |
| 3. Agents → tools and data | Autonomous workflows with access to ticketing, mail, databases, and shells, commonly wired through MCP or vendor tool-calling APIs. Fastest growing, least governed. | Nobody yet, in most organizations | East-west, inside the data center or cloud account |
| 4. AI workloads inside | GPU clusters, inference endpoints, vector stores, fine-tuning jobs. New crown jewels, usually built on a research segment and promoted to production in place. | Platform, data science | The zone boundary |
For each flow, record four things: where it exists, who owns it, which control point it crosses, and whether that control can see it today. The blanks are the risk register.
What goes wrong, in OWASP terms
The failure modes are not exotic, and each one has a network signature. The names below are from the OWASP Top 10 for Agentic Applications for 2026 and the OWASP GenAI LLM Top 10 for 2026, so the mapping lines up with what application security teams are already using.
| Failure | Flow · OWASP name | What the network would have seen |
|---|---|---|
| Data leaves in a prompt. A staff member pastes a contract or a customer list into a public assistant. | 1 · Sensitive information disclosure | Upload to an AI application category from a user segment, on a non-corporate tenant |
| Injection becomes an insider. An agent reads a page, an email, or a ticket containing instructions and follows them with its own permissions. | 3 · Agent goal hijack | Agent host opens a connection to a destination it has never used |
| Over-reach becomes lateral movement. The agent’s service account was granted broad access “to make it work.” | 3 · Identity and privilege abuse | One host talking to many sensitive destinations |
| Keys become egress. A leaked or over-scoped provider key is used from outside the intended workload. | 2 · Identity and privilege abuse | Model API calls from an unexpected source |
| Crown jewels on a flat network. The vector store or inference endpoint is reachable from any user VLAN, and anyone who can write to the store can change what the model retrieves. | 4 · Memory and context poisoning | User-segment flows into the AI workload zone; unexpected writers to the store |
Prompt injection deserves one plain sentence, because it shapes the defense. A model cannot reliably distinguish the instructions you gave it from instructions embedded in the data it reads. The defense therefore cannot live in the model. It lives in what the agent is permitted to reach.
The control you already own
Each flow maps to a control most enterprises are already licensed for. What we find in assessments is a configuration and ownership gap, not a capability gap.
| Flow | Control | What it must do | What we usually find |
|---|---|---|---|
| 1 | SSE / SASE | Recognize AI applications as a category, distinguish corporate from personal tenants, inspect uploads and pasted text inline | The category exists and the policy is “allow.” No tenant restriction. DLP profiles not applied to AI applications. |
| 2 | Egress policy at data-center and cloud edge, or the AI gateway feature of that platform | Allow model endpoints only from named workloads, keyed on workload identity or tag, with per-call logging | Broad “any to internet on 443” from application subnets. |
| 3 | Microsegmentation, host-based where the runtime scales, with an agent or MCP gateway in front of the tools where available | Default-deny from the agent runtime, explicit allow per tool by name, alert on any new destination | Agents run on general-purpose servers with the same reach as everything around them. |
| 4 | The zone model and the firewall between zones | Treat GPU, inference, and vector stores as a zone with no inbound from user segments and a short written inbound list from applications | Built on a flat research network, promoted to production in place. |
| All | Flow records and NDR | Baseline who talks to what per host, so a new destination is noticed the day it appears | Logs exist. Nobody baselines the AI hosts specifically. |
On gateways: through 2026 the major edge, firewall, and application-delivery vendors have been shipping AI gateway and MCP gateway capability as features of platforms customers already own. That is the same pattern as decryption and application identification in the 2010s. Treat it as a feature to enable and evaluate, not as a separate product category to procure first.
Identity is the key the policies turn on
Machine identities already outnumber people many times over in most enterprises, and three kinds of identity now originate AI traffic. Human identity is mostly solved: SSO, MFA, corporate tenant. The gap is the personal account on the same application. Workload identity is partly solved: every system that calls a model provider should carry a tag or workload identity so egress policy can allow by name rather than by subnet. The gap is API keys copied into code and shared across workloads.
Agent identity is not solved, and it is where risk concentrates. OWASP’s agentic list maps identity and privilege abuse directly onto its non-human identity list, and the Cloud Security Alliance’s agent identity governance framework makes the same point: agents need their own identity, task-scoped and time-bound, rather than inheriting a person’s session or a developer’s permissions. The practical rule is the one you already use for contractors. Every agent gets a name, an owner, a scope of tools, and an expiry date. Segmentation keyed on IP address will not keep up with agent pools that scale up and down; key it on identity or tag and the policy survives the next redeploy.
Five policies that need no new products
Each policy below is written to be handed to an administrator as-is. The implementation notes assume a current SSE platform, an application-aware edge firewall, host-based or network segmentation, and flow-record collection into an NDR or SIEM.
1. Sanction, then inspect
Policy. Allow a short list of AI applications on corporate tenants. Block the AI application category otherwise. Apply upload and paste inspection to the allowed applications.
Enforcement. The SSE or secure web gateway, for managed devices on and off the network. Prerequisites: the platform’s AI application category, tenant restriction so only corporate accounts authenticate, and the existing DLP profiles attached to the sanctioned applications rather than left on the general web policy. Start by blocking the category and allowing two or three named applications, then watch the request queue. Choose applications on contract terms, enterprise tier and no training on customer data, rather than on model quality.
Pushback. “People will use their phones.” True. The corporate path is the one that carries corporate files in bulk, and closing it removes the volume and the excuse.
2. Model APIs are a destination, not the internet
Policy. Only tagged workloads may reach model endpoints. Keys live in a secrets store. Every call is logged with the caller’s identity.
Enforcement. Data-center and cloud egress, where “any to internet on 443” currently lives. Prerequisites: a workload tag or identity for systems approved to call models, the AI provider category or AI gateway feature on the egress platform so the destination list is vendor-maintained, per-call logging from the firewall or an egress proxy, and a same-day ticket path to get a workload onto the list. The first egress report of “which sources reached model endpoints in the last thirty days” is the flow-two inventory, and it usually contains a surprise.
Pushback. “Developers will route around it.” They will if the block ships before the fast path. Ship the fast path first.
3. Agents get a zone and a list
Policy. Agent runtimes sit in their own segment, default-deny outbound, with tools allowed by name. A new destination is an alert, not a log line.
Enforcement. Host-based microsegmentation where the runtime scales, with the network boundary as the backstop, and an agent or MCP gateway in front of the tool endpoints where the platform provides one. Prerequisites: an inventory of agent runtimes, a named owner per agent, and a written tool list, for example the ticketing API, one mailbox, one database. Build the inventory from three sources: the egress report from policy two, the identity team’s list of service accounts created or extended in the last year, and flow records showing systems that reach ticketing, mail, and database services from a service account rather than a person.
Pushback. “The agent needs broad access to be useful.” It needs specific access to be useful. Broad access is what turns a hijacked agent into lateral movement.
4. The AI workload zone has a door
Policy. No inbound from user segments. A written inbound list from applications. The vector store is treated like the database it is, including on the write side.
Enforcement. The firewall between zones, on premises or in the cloud account. Prerequisites: GPU, inference, and vector stores placed in their own zone, a deny for user segments, a short application allow-list by name, and access control plus logging on who can write to the store. The write side matters because memory and context poisoning is on OWASP’s 2026 list for a reason: whoever can add documents can change what the model retrieves.
Pushback. “The research network has to move fast.” Draw the zone around production, leave the sandbox as a sandbox, and make the path between them a ticket. A short allow-list moves as fast as the ticket queue.
5. Baseline every AI host
Policy. Thirty days of flow records per host, then alert on deviation.
Enforcement. The NDR platform, the firewall’s own log analytics, or the SIEM; any of them can do this if the scope is narrow. Scope: hosts in the agent segment and the AI workload zone, plus every workload tagged for model access. That is dozens of hosts, not thousands. Record peers, ports, direction, and volume for thirty days, then alert on a new peer, a new port, an inbound from a segment never seen, or a volume step-change. Start with new-peer alerts only; AI hosts have unusually regular behavior, and the first exception stands out. Three examples of what fires: an agent host opens outbound SMTP to an external address for the first time; the inference endpoint receives a connection from a user VLAN; an application server calls a model endpoint it has never used.
Pushback. “We already have AI detection.” Ask the vendor to show the alert that fires when an agent host talks to a system it has never talked to before. If they can, and it is scoped to your AI hosts, this policy is done.
Four metrics, and how to compute them
Each metric is a ratio, has a data source the organization already holds, and has a named owner. Report the four together. Individually they are operations numbers; together they are an AI risk posture a board can follow quarter to quarter.
| Metric | How to compute it | Target trajectory | Owner |
|---|---|---|---|
| 1. AI traffic on sanctioned tenants | From SSE logs: sessions to the AI application category on a corporate tenant, divided by all sessions to the AI application category. | Up every quarter. Above ninety percent by the fourth report. | Workforce security |
| 2. Workloads reaching model APIs, and share tagged | From egress logs: distinct sources reaching model endpoints in the quarter, and the share carrying the approved workload tag. | Count becomes known and stable. Tagged share reaches one hundred percent. A rising count is fine if it rises because you found more, not because more appeared untagged. | Cloud and application security |
| 3. Agent runtimes with a named tool list | From the agent inventory: runtimes with default-deny outbound and a written allow-list, over all runtimes found. | One hundred percent. Every unlisted agent is a finding with an owner. | Segmentation, platform |
| 4. AI hosts with a live baseline | Hosts in scope for policy five with at least thirty days of baseline and alerting enabled, over all hosts in scope. | One hundred percent, and stays there as hosts are added. | Security operations |
The first quarter’s numbers will be poor. Say so. The first report is the baseline the next four are measured against, and the direction of travel is what the board should read.
The first ninety days
- Week one. Fill in the four-flow inventory. Ask the firewall team which sources reached model endpoints in the last thirty days; that answer fills in flow two and points at most of flow three. Name one owner per policy.
- Month one. Policies one and two go live on existing platforms. Start the thirty-day baseline on every AI host now, so that policy five can alert by the end of the quarter.
- Quarter one. Policies three and four begin, since they involve segmentation work and take longest. Produce the first four-metric report even if the numbers are ugly.
The schedule slips when nobody owns policy three. Name that owner first.
One governance note, because the same discipline applies when your own team or a partner uses AI on your firewall configurations and logs. Reasonable uses are first-pass policy translation marked as draft, rulebase summaries, anomaly triage ranked for a human, and documentation of decisions already made. The lines to hold: no path from a model to a production policy without a named approver, configurations stay inside an agreed boundary with no training on customer data, a human decides wherever the tool is unsure, and AI-assisted changes are labelled in the change record. Write that boundary into partner contracts, including ours.
AI risk arrives as traffic. Treat it as traffic, on the controls you already own.
Sources
- OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
- OWASP GenAI Security Project: GenAI LLM Top 10 for 2026
- Cloud Security Alliance: Agent Identity Governance Framework
- Citrix: NetScaler MCP Gateway capabilities (July 2026), an example of gateway functions shipping as platform features
- Palo Alto Networks: AI Access Security features, an example of AI application categorization and tenant controls on an SSE platform
Source note: Framework documents describe risk categories and intended controls. Vendor documentation describes intended functions. Verify category coverage, tenant-restriction behavior, decryption dependencies, and alert fidelity in the target environment before relying on any of them.