The AI enterprise security blueprint — from perimeter to agent-aware control
A 13-slide reference architecture for securing AI across endpoint, network, data, and agent paths. The full framework.
We published a complete reference architecture — 13 slides — for securing AI in the enterprise. Not a product pitch. A framework. This post walks through the entire blueprint: from how the trust boundary evolved, to the six control planes, to the eight edge cases that break naive AI security, to the crawl-walk-run deployment roadmap.
Four eras of enterprise security
The trust boundary has shifted three times, and AI is the fourth shift.
The Perimeter Era: castle-and-moat trust. Users mostly on-site. Network location drove access. HQ, LAN, VPN, firewall.
The Cloud and SaaS Era: apps leave the data center. Users everywhere. SaaS and internet traffic explode. Visibility fragments.
The Zero Trust / SASE Era: identity and context become central. Verify explicitly. Least-privilege access. Inline inspection at the edge.
The AI-Native Era: humans and agents both create traffic. Local copilots and agents run on workstations. Model and API traffic crosses enterprise boundaries. Policy must follow data, devices, and agent actions.
The network did not disappear — it became the transport fabric for identity-aware, data-aware, and agent-aware control.
Every AI action becomes a flow
Prompts, files, retrieval, completions, logs, and tool calls all traverse networks as inspected or uninspected traffic. The packet-level view of an AI interaction follows six stages: user or agent intent, application layer (browser, desktop app, API client), transport and encryption (TLS 1.3, DNS, QUIC/HTTPS, certificates and keys), policy enforcement (secure proxy, ZTNA, SWG, CASB, firewall, model gateway), destination (SaaS application, private application, public LLM, data store, internet tool or service), and return path (response, completion, file or artifact, telemetry, audit event).
At each stage, security needs to answer: who is the subject? What device and posture? What data is inside? Where is it going? What action follows?
AI security is not only model security — it is packet visibility plus identity, content, destination, and action context.
What runs on a corporate workstation now
The endpoint is no longer just a user device — it is a runtime for browsers, security agents, copilots, plugins, and local AI agents. A modern corporate workstation has four layers, each with security implications for AI.
The application layer: browser, Office/IDE, chat client, automation tools. The OS layer: Windows/macOS/Linux, process identity, files, keychain and tokens. The security agent layer: EDR/XDR, DLP, MDM/UEM, browser agent, ZTNA client. The network layer: DNS, TLS, proxy, VPN/split tunnel, Wi-Fi/home network.
Four questions matter: can it read files? Can it call tools? Can it use tokens? Can it send data out? Every path from the workstation leads to local files, APIs and tools, private apps, or public LLMs. OS-level agents matter because they decide what code runs, what data is touched, what network path is used, and what evidence is collected.
The new traffic graph
Enterprise communication is now human-to-AI, app-to-AI, and agent-to-agent — not just user-to-app. The managed workstation (user, browser, local AI agent, device posture) talks to a security edge / access broker (policy enforcement, identity and context, session control) which mediates traffic to enterprise applications and data (SaaS, private apps, structured and unstructured data) and to external cloud LLM services and internet AI agents.
North-south traffic still matters. East-west data access still matters. But AI-bound traffic adds entirely new paths and return flows. Security teams need visibility into every path: browser, API, endpoint, and machine-to-machine.
Remote workforce — the perimeter became a set of paths
Users work from homes, branches, airports, and unmanaged networks — but still access private apps, SaaS, data, and AI services. Connection options range from ZTNA clients (brokered, identity-and-device-aware) to browser isolation (inspected) to SASE / security edge (device-aware) to VPN/split tunnel (direct-to-internet) to direct internet with no controls (unmanaged device, unsanctioned AI).
Remote workforce edge cases that break security: personal device uploads a file, split tunnel bypasses inspection, browser extension calls an LLM, developer script uses an API key, offline work syncs later after policy context changed.
Remote work turns the network into a policy routing problem: every path needs identity, posture, data, and destination context.
Reference architecture — six control planes
The reference architecture has six layers, each with specific tooling:
1. User and Device: managed endpoint, browser, local AI agent, EDR/XDR. Action: authenticate. 2. Identity and Posture: SSO/MFA, device trust, risk signals, least privilege. Action: inspect. 3. Security Edge: ZTNA, SWG, CASB, FWaaS, RBI. Action: authorize. 4. Apps and Data: SaaS, private apps, structured data, unstructured data. Action: redact. 5. AI Control Plane: model gateway, prompt/response policy, redaction/DLP, approved model routing, agent governance. Action: observe. 6. Operations and Assurance: SIEM/XDR, UEBA, audit trail, incident response, continuous policy tuning. Action: respond.
Six design principles: never trust network location alone. Verify user + device + session. Inspect AI-bound traffic inline. Protect data before it leaves. Govern agent actions explicitly. Correlate telemetry end to end.
Example workflow — a local AI agent assists an employee safely
An end-to-end usage flow showing where control points are applied in seven steps:
1. Employee asks the local agent to summarize a proposal. 2. Identity and device posture are checked. 3. Agent retrieves only approved internal files. 4. Traffic is routed through the security edge and AI gateway. 5. Sensitive content is classified, filtered, or redacted. 6. Approved LLM returns a response; output is scanned. 7. All actions are logged and correlated for SOC review.
Controls triggered at each step: ZTNA, DLP, CASB, API security, audit logging, policy enforcement.
The goal is not to block AI use — it is to make AI use visible, governed, and safe.
Why AI changes the threat model
When agents, models, and data interact across boundaries, the attack surface expands in six new ways:
1. Data Leakage: sensitive prompts, files, or outputs leave approved boundaries. 2. Shadow AI: unsanctioned tools bypass policy and create blind spots. 3. Agent Overreach: local or cloud agents gain excessive permissions or act unsafely. 4. Prompt Injection: external content manipulates model behavior or downstream actions. 5. Identity and Token Abuse: stolen sessions, API keys, or OAuth tokens are misused. 6. Visibility Gaps: browser, API, encrypted, and machine-to-machine traffic escape inspection.
What changes operationally: access must be continuous, not one-time. Inspection must include content and context. Policies must cover both humans and agents. Logging must connect endpoint, network, and AI events.
Eight edge cases that break naive AI security
The hard problems are not the happy paths — they are bypasses, mixed trust, delegated actions, and delayed visibility.
1. Split Tunnel Bypass: AI traffic exits outside the security edge. 2. Browser Extension AI: extension reads page data and calls external services. 3. Local Model Offline: sensitive data is processed without network visibility. 4. Developer API Key: script or IDE plugin calls models directly. 5. Agent Tool Abuse: agent uses file, email, shell, or browser tools beyond intent. 6. RAG Overreach: retrieval pulls data the user should not expose. 7. Token Reuse: OAuth/session/API tokens are replayed by automation. 8. Delayed Sync: offline work is uploaded later after policy context changed.
The control pattern for each: detect the path, bind identity + device, classify content, then allow, redact, isolate, or block. Edge cases prove why AI security must combine endpoint control, network enforcement, data governance, and auditability.
Policy decision logic — from packet to business risk
A modern AI security decision is not a single allow/block rule — it is a context calculation. Six inputs feed an AI-aware policy engine: identity (user, role, group), device (managed, posture, location), application (browser, app, API, agent), data (classification, secrets, regulated content), destination (private app, SaaS, LLM, tool), and action (read, upload, execute, summarize, send).
The policy engine evaluates risk score, guardrails, data rules, agent permissions, and model routing. Outputs range from allow, allow + log, redact, route to approved model, isolate session, require step-up auth, block, to open incident. Telemetry and SOC (logs, detections, outcomes) feed back to tune policy continuously.
The right question is not "is this packet allowed?" — it is "is this identity, device, data, destination, and agent action acceptable right now?"
Where modern security products fit
No single tool solves the problem — value comes from policy continuity across layers.
1. Endpoint Layer: MDM/UEM, EDR/XDR, browser security, local runtime controls. 2. Identity Layer: IAM/SSO, MFA, PAM, conditional access. 3. Access / Edge Layer: SASE, ZTNA, SWG, CASB, FWaaS. 4. Data Layer: DLP, DSPM, encryption, key management, data classification. 5. AI-Specific Layer: model gateway, prompt policy, model allow-list, agent governance, output scanning. 6. Operations Layer: SIEM, SOAR, UEBA, NDR, threat hunting.
The winning architecture is integrated: identity, network, data, and AI controls should share policy and telemetry.
Crawl, walk, run — a deployment roadmap
A practical roadmap for securing AI use on corporate machines and across the network.
Crawl (0–90 days): inventory AI use cases and tools. Approve sanctioned models. Route web and API egress through policy. Enable baseline logging.
Walk (90–180 days): adopt ZTNA and device posture checks. Add DLP and data classification. Introduce model gateway and prompt controls. Secure high-value data paths.
Run (180+ days): govern agent actions and permissions. Automate response and remediation. Correlate endpoint, network, and AI telemetry. Continuously tune policies and guardrails.
Key metrics at each stage: percentage of AI traffic visible, percentage of AI tools sanctioned, sensitive data egress blocked, risky agent actions prevented, mean time to investigate AI events.
The network is still the transport layer — but resilient AI security requires continuous trust, inline inspection, and end-to-end observability.
Telemetry fabric — making AI use observable end to end
Security operations need one story that connects endpoint events, network flows, data movement, model interactions, and agent actions. Six telemetry sources feed a unified AI security timeline: endpoint (process, file, agent activity), identity (login, MFA, role, risk), network/edge (DNS, TLS, proxy, ZTNA, firewall), data (DLP, classification, access logs), AI gateway (prompt, response, model, tool call), and SOC (SIEM, XDR, SOAR, case management).
The timeline correlates, enriches, sequences, and provides context over time. It drives two outputs: policy updates (adjust rules, guardrails, entitlements, detections) and automated response (block, isolate, revoke, contain, notify).
A mini investigation storyline: user asked, agent retrieved, data was redacted, LLM responded, SOC reviewed.
Visibility is not a dashboard — it is the ability to reconstruct who did what, with which agent, to which data, through which path, and why.