AI Security in Oil & Gas — Series Introduction

AI Security in Oil and Gas: Series Introduction

What Oil and Gas Needs to Ask Before the Next AI Agent Goes Live

I recently spent an evening at an exclusive oil and gas industry roundtable with operators and executives who are actually using AI in the field. Not pilots and not slide decks. Actual agent deployments, in the back office and in the field, delivering real ROI, and nearly every one of them running on Claude, GPT, or Gemini underneath. Agents answering production questions that used to take an engineer weeks. Agents reading morning reports and flagging when NPT starts trending on a particular rig. Agents flagging AFE budget overruns in real time (shameless eXovy plug here) so there are no surprises at the end of the job.

The entire room was bought in. Genuinely, unreservedly bought in, in a way I have not seen any industry be about a technology in a very long time.

AI security did come up a few times during the discussion. Everyone agreed it mattered, but nobody could point to a control they'd built before their agents went live.

When working with other industries, here are the two questions I always want answered:

1. What happens when one of these agents reads data it was never meant to trust?
2. What happens when an agent follows an instruction nobody at the company gave it?

This is by no means a criticism of the room. It's a gap I've noticed in the conversation the oil and gas industry is having as a whole right now, and it's worth closing early, because two questions stand between a deployment that keeps earning trust and one that costs you the program.

Neither is complicated. Both are easier to ask before an agent goes live than after.

The technology adoption pattern is backwards from last time

This sector took its time with standardizing data and adopting cloud computing compared to other industries I've dealt with, and everyone has their version of why.

• The data was too big to move.
• The applications were old and the vendors only supported them on-prem.
• Nobody wanted production data sitting on somebody else's servers.

Most of those arguments had some legitimacy to them, and most of them ended the same way: we'll look at it next budget cycle. A decade went by.

AI has gone the other way, and for two good reasons.

The value is legible and the ROI traceable in a way cloud and data engineering never quite were, especially when getting CFO signoff. An agent that answers a completions question in 5 seconds instead of 5 days sells itself to the engineer, and the engineer sells it upward. In other words, getting those enterprise Claude licenses approved is a no-brainer.

The second reason is the one worth sitting with. This sector doesn't have the compliance brakes that slowed everybody else down.

What the compliance brake actually did

Healthcare has HIPAA. Banks have SOX. Those frameworks are frequently annoying and occasionally absurd, and it's easy to read them as pure overhead. But they do something useful: they force us to ask questions before anything gets wired together. Where does this data go, and who can reach it?

Teams in those sectors have moved slower on AI because somebody in their legal, compliance, or security department made them answer those two questions. Although that delay cost them time, it also bought them a map of where their data lives and who can touch it, which is the exact thing every company should have, no matter the industry, before you let any agent loose.

Oil and gas has plenty of regulation, but none of it is about this. The Railroad Commission cares what you report, not whether the data you're integrating has a governance layer. PHMSA cares about the physical safety of your pipelines, not which permissions your agent authenticates with. API 1164 and the ICS frameworks have serious things to say about segmenting operational technology from everything else, but none of them were written with an AI agent sitting on the other side of that line.

So in other words, nothing in this industry slows down the first bad integration. And the first bad integration is usually the one that teaches everybody the lesson.

I want to be clear that none of this is an argument for slowing down. The tools are good. Adoption is the right call, and the operators moving now will have a real advantage over the ones who wait for a framework to tell them it's safe.

Brakes are what let you go fast

A race car's brakes don't make it slow. They're what let it be fast. Take them off and you don't win, you go into the wall before turn one. Every bit of speed a driver carries into a corner is speed they're willing to carry only because they know they can scrub it off.

Controls on an AI deployment work the same way. They aren't there to slow the business down. They're what lets you point an agent at production data without it becoming an incident report, and what lets you say yes to the next six use cases instead of freezing everything after the first one goes wrong.

The two questions

I'm going to spend the next several posts on five specific ways these agent deployments go wrong and how oil and gas operators can protect themselves. They look different on the surface, but nearly all of them come back to the same two conditions we opened with.

• What data can it read?
• What can it write to?

Neither is harmless on its own. But the combination is what turns a bad document into a bad outcome: one supplies the instruction, the other carries it out.

Ask both before the next agent goes live. The rest of this series is what happens when nobody did.

The series

1. Prompt injection. Why a model can't tell your instructions from the document it just read.
2. Excessive agency. How agents end up with permissions nobody remembers granting.
3. Bad data in, bad data out. No attacker required. Somebody indexes a superseded procedure and the model answers from it with total confidence.
4. Insecure output handling. When an agent writes a query, a script, or a set of cost codes and something runs it with no human in the loop and no validation in between.
5. Shadow AI. Engineers plugging well logs and AFE costs into personal ChatGPT accounts, why a ban makes it worse, and why an enterprise agreement doesn't close the gap you think it does.

In case you're wondering, governance is the solution to all five. Classify your data so people know what's safe to use, control what gets indexed, and carefully review what systems an agent has access to.

TechVora works with energy operators on identity, access, and securing AI deployments through governance techniques. If you're standing up agents against production systems and want a second set of eyes on the permission model before it goes live, get in touch.

We're also building eXovy, our own AI tool for tracking field cost overruns in real time. Which means we've had to answer both of these questions ourselves. It safely reads invoices and field tickets from a dozen vendors, and it never posts anything without a human approving it.