Shadow AI in Oil and Gas: SCADA Context, Shift Logs, and Model Routes

At 5:42 a.m., a pipeline controller pastes a handover note into an AI assistant. The goal is to make it shorter for the incoming shift. Behind the browser, the SCADA display shows a pressure trend and two inhibited alarms. The prompt contains station names and a manual value, plus a maintenance window and the technician on call. One HTTP request can move live operating context to a provider that operations security never approved.

Shadow AI in oil and gas concentrates risk in compact prompts. The same model route can carry control-room notes and integrity findings, along with production data or drilling plans. Emergency procedures and vendor access instructions can leave that way too.

TL;DR

• Oil and gas shadow AI can expose SCADA context and controller handovers. Unauthorized model requests can also carry alarms and maintenance findings, plus pipeline integrity data and emergency procedures.
• NIST SP 800-82 Revision 3 treats OT as a distinct environment with performance and reliability requirements. Safety requirements also apply to oil and gas SCADA, including pipelines.
• PHMSA's control-room rules require written procedures for controller roles and handovers. The rules also cover change coordination, plus SCADA information and alarm management.
• DeepInspect controls authenticated HTTP AI traffic routed through it. OT protocols and local inference remain outside its boundary, as do direct browser bypass and physical control actions.

Operational meaning survives copy and paste

Removing the document title does not remove the operational picture. A station name beside pressure and alarm status can reveal how the system is behaving, especially when the prompt also includes valve state and maintenance timing. An engineer can expose a pipeline segment and anomaly location by asking a model to rewrite an integrity note. A drilling prompt may carry formation data and planned depth, together with vendor performance and an unreleased schedule.

The shadow AI pillar explains how unauthorized providers bypass procurement and policy. Oil and gas adds safety and production context. The sensitive object may be only a few lines copied out of a historian export or turnover log, not a complete SCADA screen.

I would block production operations data from general-purpose model routes by default. A public standards assistant can earn a narrow exception. Current alarm and asset context deserves an explicit workflow. That workflow needs a named owner and approved endpoint.

NIST defines the OT constraint

NIST SP 800-82 Revision 3, published in September 2023, provides guidance for securing operational technology while addressing performance and reliability requirements, along with safety requirements. NIST includes SCADA among OT examples. It also describes SCADA's use for monitoring and controlling oil and natural-gas distribution, including pipelines.

That context changes the shadow AI decision. A prompt containing a configuration snippet or alarm summary may reveal operating conditions even when it sends no command back to OT. The AI request still travels over HTTP to an LLM, where a routed enforcement point can inspect it before transmission.

The gateway remains outside the control loop. It never replaces segmentation or OT asset management. Safety systems, controller procedures, and incident response keep their assigned roles. The gateway has one bounded job: decide if an authenticated user or agent may send this detected content to this model endpoint for this purpose.

PHMSA makes control-room context concrete

PHMSA's 49 CFR 195.446 control-room management rule applies to covered hazardous-liquid pipeline facilities whose controllers monitor and control operations through SCADA. It requires written control-room procedures integrated with operating procedures.

The rule identifies information that deserves careful handling. Operators define controller roles during normal and abnormal conditions. Emergency conditions are included. They record shift changes and handovers. They provide necessary SCADA information, test internal communications and backup systems, manage alarms, coordinate changes, and incorporate operating experience.

An unauthorized summarization request can contain pieces of that regulated operating process. The issue is narrower than claiming the AI service controls the pipeline. It received operational context outside the approved handling path. Before the request leaves, policy should detect alarm language and station or line identifiers. It should also detect manual values, maintenance windows, emergency terms, and handover patterns.

Engineering and field work create separate prompt profiles

Integrity teams handle inspection findings and corrosion data, along with defect locations, repair decisions, and pressure calculations. Maintenance staff use equipment histories and work orders. Their prompts may include exact asset identifiers and failure evidence. Planned outages can appear too. Those data classes need a stricter destination rule than public engineering references.

Production and subsurface teams add well logs and reservoir interpretations. Their records can also contain drilling parameters, chemical programs, and forecast assumptions. Commercial sensitivity can be high even when the data has no OT connection. Policy should bind those classes to project identity and approved purpose rather than stretching an OT label across every oil and gas record.

Contractors create another route. A service company may receive a work package and paste it into its own model tenant. The operator's proxy sees nothing when the request occurs entirely in the contractor environment. Contract terms and onboarding must cover that path, supported by approved-tool rules and contractor telemetry.

The AI governance for energy and utilities article covers the broader use-case inventory and governance program. This article owns the unauthorized HTTP request that exits before those controls attach.

Identity and purpose belong beside the payload

A managed oil and gas request should carry the authenticated human or agent identity, together with the source application. Relevant context may include the business unit and asset or project. Role and approved use matter too, as do the data owner and sensitivity label. The application owns the accuracy of those attributes. Shared credentials produce a shared principal. That weakens the investigation record.

Prompt classification can detect SCADA terms and alarm descriptions. It can also find controller handovers, station naming patterns, integrity anomalies, coordinates, equipment identifiers, and emergency procedures. Vendor remote-access instructions and work-order details are detectable too. Policy checks the destination against those detections, then applies identity and purpose.

The HTTP-layer policy enforcement guide explains this decision point. A public API-documentation request may proceed to an approved model. On the same route, a request containing a live alarm summary can be denied under the active policy version.

Discovery layers cover the routes a proxy never sees

DeepInspect inspects authenticated HTTP AI traffic deliberately routed through its proxy. A company-built maintenance assistant or engineering agent can use that path. The gateway can then stop a prohibited prompt before it reaches the model provider.

A consumer chatbot opened through an unmanaged browser may bypass the configured route. Secure web gateways and enterprise-browser controls can restrict that surface. Endpoint telemetry and DNS monitoring add discovery, while egress analysis and managed-device controls provide further enforcement around it.

Local models and non-HTTP transports remain outside the gateway. So do Modbus and OPC UA, along with DNP3 and proprietary fieldbus traffic. Direct SCADA commands stay outside as well. Physical actions and safety-system logic do too. Keeping these exclusions on the architecture diagram prevents a request control from becoming a claim of universal OT protection.

Request evidence should avoid creating another historian

For each routed model request, record the person or agent and source application. The record should also contain the approved purpose, detected category, intended endpoint, policy version, timestamp, and outcome. Link a permitted response to the request. Preserve denials because they show the payload stopped before transmission and may reveal a workflow that needs a sanctioned alternative.

Retention needs an explicit design. Copying every prompt and response into an audit store can create a second repository of operational and commercial data. Classification and fingerprints may provide sufficient evidence when paired with controlled references and selected content under company records rules. Access to any retained payload should follow its source classification.

The request record complements historian and SCADA records, plus work-management, integrity, and incident records. Provider logs supply another adjacent source. This bounded evidence proves the policy event on the managed HTTP route. It makes no claim about what occurred on an industrial protocol or which field action a controller took.

DeepInspect

DeepInspect sits inline between authenticated oil and gas applications or agents and HTTP-based LLM endpoints. The application supplies identity and operational context. DeepInspect classifies routed prompts and responses, then evaluates role and destination against versioned policy. It can permit or deny the traffic. When policy allows it, DeepInspect can redact the traffic before the request reaches the model.

Each decision creates an identity-bound audit record for the managed request path. Direct browser bypass and local models remain outside this boundary. The exclusions also cover contractor-internal inference, non-HTTP traffic, industrial protocols, and physical control actions. OT safety, pipeline integrity, controller procedures, and field operations remain with their assigned systems and qualified owners.

Book a technical deep dive at deepinspect.ai.