Cyber Security Month: Coexisting with AI

Last week, at the onset of our Cybersecurity Month blog series, “The Barn Door is Open”, we argued that banning Artificial Intelligence (AI) outright is an illusion of control rather than actual defense. AI tools arrive through a browser, through Software as a Service (SaaS) vendor update, and embedded inside hardware you have already procured. Blocking web URLs does nothing to address the other two entry points.

The real challenge is architectural: Where can a model sit, what is it allowed to reach, and who remains accountable for what it produces?

In December 2025, the Cybersecurity and Infrastructure Security Agency (CISA) and the Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC) published Principles for the Secure Integration of Artificial Intelligence in Operational Technology. These guidelines provide an actionable framework to rein in unmanaged AI use and learn how to co-exist with it.

Three Doors AI Uses to Enter

In our broader Cybersecurity Month blog series, we outlined the common pathways AI takes into a utility. Those entry points look like:

Direct Web Access (Shadow AI)

An employee opens a public generative AI chat tool in a browser and pastes in a paragraph of operational notes. The traffic travels over a standard web connection to a short list of known addresses. Secure web gateways and browser policies can log it or block this traffic relatively easily. This is the shadow AI most organizations focus on and is by far the easiest of the three to govern.

Embedded in Sanctioned SaaS

When an AI assistant lives inside approved business software (such as Microsoft 365), its traffic blends seamlessly into the routine authorized application sessions. There is no new address to block, and network perimeter inspection sees only standard traffic with a trusted vendor rather than the prompt payload inside it. Governing this door requires controls at the application layer: admin consoles and the audit logs.

Endpoint and Operational Technology (OT)

A model built into the operating system, running on an engineering workstation, or embedded in an OT device may never generate traffic that your network tools would notice. Nothing crosses the boundary you are watching. Oversight at this layer relies on asset management, configuration audits, and rigorous procurement vetting rather than network filtering.

The first door is the easiest to watch. It is often the only one that organizations measure. The problem is larger than that view shows. IBM's 2026 Cost of a Data Breach Report found that unapproved AI use played a part in 43% of the breached organizations it studied. The year before, the figure was 20%. If you only inspect web gateway logs, you are measuring a fraction of the exposure while mistaking it for the whole picture.

As one travels deeper through the network, visibility drops significantly further down into an industrial environment. In the enterprise and business layers, AI traffic and activity leave a clear trail in web proxies while passing through web gateways, DNS logs and SaaS audit trails, so one can have some visibility. At site operations and supervisory control, an AI model running locally leaves little trace. At the controller and field-device level there is often no agent to install and no log to read, so the sole visibility into AI activity on those devices is what the vendor explicitly discloses.

Figure 1 shows the three ways AI enters a utility, and how easy each one is to see.

Model Placement

Your organization already possesses the foundational structure to contain AI safely: segmented network zones and conduits, the Purdue Levels, and the established boundary inspection rules for traffic.

A model at Level 4 can still use plant data, for example data from the historian. The data comes up to the model. The model does not reach down for it. A replicated historian or a scheduled export in the demilitarized zone (DMZ) between Levels 3 and 4 gives the model a copy to read. The model never connects to Level 3 or below. It has no access to devices or their configuration.

An AI model in a conduit will travel between the supervisory control layer and the corporate layer. A replicated historian, a scheduled export, or a message broker in the demilitarized zone between Levels 3 and 4 hands data upward, allowing the model to read the copy as part of these processes. Although this may be useful, allowing an AI assistant to query or issue commands from the OT layer creates a high-risk conduit into the process that must be strictly authenticated, documented, secured, authorized and continuously monitored, like any other corporate application that reaches information in that layer.

Where the model runs is a critical decision that requires a clear view of your organization’s network: a vendor-hosted application sends prompts and context outside your network’s boundary, so the egress path and the vendor's data retention policies and training terms serve as your primary defense and become the security controls you will use to regulate usage.

An alternative is self-hosting (private cloud), which keeps the data inside your perimeter and shifts the burden of model hardening, vulnerability management, patching and high computational infrastructure costs onto your internal team.

Figure 2 maps the location where AI may sit in a utility and marks where these processes will flow across the DMZ.

Tool Access

The National Security Agency's Artificial Intelligence Security Center published an information sheet on Model Context Protocol security in May 2026. It names tools invoked on the fly, implicit trust between components and shared context as systemic risks the protocol does not inherently solve. Weak access controls, token lifecycle gaps and thin audit logging sit alongside them.

Every tool an agent can call is a path to data or to another system. Treat it like any other connection. Name it, give it one job, require it to log in, and log its use. The OWASP Top 10 for Large Language Model Applications ranks prompt injection as the top risk. Our AI Security Series explained this attack. A tool that returns text from an attacker is one way to deliver it.

Access control is where many organizations fall short. Of the organizations in IBM's 2026 study that had an AI-related breach, 92% did not have proper access controls for AI, such as role-based access and multifactor authentication.

Keeping It Reined In

To co-exist safely with AI across a utility, governance must be backed by verifiable telemetry. An approved tool catalog only works if network, identity, and host logs actively confirm what is running. Maintain your approved tool catalog on a quarterly review cycle, accelerating reviews whenever vendor terms change, models update, or integration scopes expand.

Map the telemetry to each door.

Each door AI uses leaves records of its use in a different place.

• On Direct Web Access: Evidence is in DNS query logs and web gateways. A lookup for a named AI service shows that a device reached it. The prompt itself only becomes visible where TLS inspection is switched on for that traffic; without it, the gateway records the name of the service and the amount of data sent, but not the prompt. Netskope's Cloud and Threat Report 2026 found that the average organization records 223 data policy violations a month that involve generative AI. Allow only the AI services that your organization has approved, usually one or two, and block all other AI services at the web proxy and in DNS. A log alone does not protect you. It shows that data left. It does not stop it. Turn on inspection for the approved services so that you can see what goes out. If you use Microsoft Purview, network or browser data loss prevention (DLP) can also record use of AI apps that your organization has not deployed. These records appear as AIAppInteraction entries in the audit log. You must turn on pay-as-you-go billing to get them.
• On embedded software: Evidence sits in the tenant. Microsoft Purview’s audit log for Copilot and AI applications records which user interacted with Copilot, when, and which files, sites or other resources it accessed to answer, under the CopilotInteraction record type. Non-Microsoft AI apps registered in the tenant are logged as ConnectedAIAppInteraction entries. In Entra ID, the delegated and application permissions granted to enterprise applications show which third-party AI tools have been consented into mailboxes and files. Microsoft notes that revoking a grant does not stop users from consenting again, so the review needs a user consent setting behind it.
• On Endpoint and OT: Evidence is in the endpoint inventory. Microsoft Defender Vulnerability Management builds its software inventory from the same signals Defender for Endpoint uses for detection and refreshes it every three to four hours. On Linux it lists only software installed through native package managers such as rpm, dnf and yum, so a model runtime unpacked by hand will not appear. Controllers and field devices that cannot run an agent stay outside this view entirely and will require vendor disclosure.

Tune the content detectors to your own material:

Asset inventories, relay settings, network ranges and one-line diagrams are what matter in a utility, so build your rule set around these types of confidential data.

Reining the horses in is not the same as putting them to work. The next part of our mini-series covers where to go from here.

References