Most of the security stack answers one question, which is who gets in. Network controls, zero trust, multi-factor authentication, and role-based access all govern the route to a file. Once that route opens, the file usually opens in full. Nothing in the stack decides which parts of it the reader should actually see.
That model worked well enough while the readers were people with job titles and managers. It works less well now that AI agents read enterprise documents at a scale no employee could, and as businesses pull operational technology data into analytics and AI. Nobody designed the plant floor, the grid, or the water system to share data this widely, and they patch on schedules measured in months rather than days.
Welcome to Issue 05 of InfoSec Leadership by InfoSec Relations, featuring Bennett Indart. He has worked in technology for three decades, twenty years of it at NTT, and now leads Scale Academy at NTT Research, which prepares technologies from NTT’s labs for market.
Let’s get started.
Once Someone Gets In, the Data Is Often Wide Open
A technology incubation leader at NTT Research on why AI-speed discovery breaks OT patch cycles, and why the next layer of protection has to be the data itself.
Listen to the Full InterviewIndart opens on timing, and starts with a fair reading of why operational technology looks the way it does.
"In the OT space, that's not so much true," he explains, setting plant systems against the fast release cycles of IT and SaaS. "A lot of these systems are old. They're legacy. They may not even be supported. And when they are supported, because they're so critical and they can't go offline, and offline time costs a lot of money, there are very structured paths to take them down to patch or to upgrade these systems, sometimes annually." AI changes what that schedule costs. "You have a problem when you bring your line back up and it gets attacked the day after you've patched everything," he cautions, "because some AI bot found a vulnerability, and your next patch is a year from now."
Nothing in that schedule is careless. It reflects a real trade between uptime and risk, one that plant owners struck when an attacker needed weeks or months to build a working exploit. AI-assisted vulnerability discovery compresses that interval without touching the maintenance calendar, so the gap between a known flaw and the next window becomes the exposure. Indart calls segmentation and micro-segmentation a good reactive path, and the word reactive matters, because both contain a problem rather than close it.
So list every OT asset whose patch window runs longer than a quarter, and write down the compensating control that covers it between windows. Where the answer is nothing, that asset goes to the top of the segmentation plan.
Separate networks still need the same practices
The business wants OT data for analytics, predictive maintenance, and digital twins, and Indart sees the boundary between the two domains thinning as a result.
"AI doesn't know whether it's IT or OT, first of all," Indart argues. "It's crossing the boundaries." He supports a physical split between corporate and operational networks, and he is clear about where that split ends. "You want your corporate environment to be segmented from your operational environment. But that doesn't mean that the practices on each should be different. They are the same, I believe. It all needs to be protected."
He describes OT as a loop of sensing and acting. A sensor reads a temperature, detects a value out of range, checks the history and the conditions around it, and then acts. "And now we're automating all of that with AI," he notes. Once a model runs inside that loop, its governance stops being an IT question or an OT question. A model that reads plant telemetry and writes to a control system crosses both domains in a single decision, and separate rulebooks leave the most consequential system governed by neither.
So name one owner for every AI system that reads OT data or acts on it, and hold that system to one practice standard across both environments. The network split can stay physical. The governance should not follow the same line.
Getting through the perimeter usually means getting all the data
Indart draws enterprise security as concentric circles, with the network on the outside and the application layer inside it. Both rings decide whether the right person reaches the right system.
"But when they get access through the first two layers, if we're looking at a very basic diagram, network and application, in many cases they have access to all the data," he points out. He frames data-layer protection as an addition to zero trust, and he corrects the question when it suggests otherwise. "We're not actually challenging today's environment or zero trust. We're complementing it."
That distinction matters for how a security leader reads the problem. NIST's zero trust architecture already centers on protecting resources rather than network segments, yet in many deployments the last enforcement point is the application. The data behind it inherits whatever access the application grants, so a stolen session or an over-permissioned agent reads everything that application can reach. A breach review that asks only how the attacker got in never reaches the question of why the data was readable once they did.
So add one line to your next incident review template that records what the intruder could read, alongside how they entered. If the answer is everything the compromised account could reach, the gap is at the data layer.
One document can hold three audiences
Indart's clearest illustration involves a single internal document, the kind that circulates in every large company.
"This document has PII in it. It also has some financial information on the company, and it has some sensitive discussion in a memo about an upcoming M&A," he observes. "So there are three different ways to view that, and three different types of people that should be viewing it, and others not." File-level controls force a choice between locking the whole document away and exposing all three kinds of content to anyone with access. Encrypting each piece to its own audience lets HR, finance, and the deal team open the same digital copy and see different things.
The hard part comes before any encryption. "Attribute-based encryption works really well if you know what you need to encrypt," Indart acknowledges. His working hypothesis is that the data most companies already track, their PII and financial records, makes up twenty to thirty percent of the estate. The rest spreads across shared drives and collaboration tools with no label at all. He makes the same point about his own product, where most of the engineering effort went into discovery, classification, and policy around the algorithm rather than the algorithm itself.
So weigh discovery and classification as heavily as the cryptography when you evaluate any data-centric control. Then pull a sample of fifty documents from your busiest shared drives and count how many mix sensitivity levels inside one file. That number tells you whether file-level classification describes your estate or hides it.
Protection has to travel past the perimeter
The sharper point concerns what happens once data leaves the organization, which it does every day through supply chains, deal rooms, and litigation.
"In zero trust, it's all about what's inside the perimeter. But what happens when it goes outside?" Indart asks. Attributes attached to each piece of data can describe a function, a location, or a time window. A document shared with a partner then carries its own rules with it. His multi-authority model extends this to shared data vaults, where several organizations each control what they contribute and who can see it. And if an attacker takes the data anyway, the outcome changes. "Before, when they got that data, they could see it and they could exploit it. Now they can't. It's gibberish. It's not usable. It's ciphertext."
That trade carries a dependency worth naming. When protection moves into the data, whoever controls the attributes, the policy engine, and the keys controls the data, and that authority becomes the new high-value target. Revocation also behaves differently, because a copy already outside the organization keeps whatever policy it carried when it left. Neither point argues against the approach, and both belong in the design review before rollout.
So ask any vendor of data-centric encryption where the keys and the attribute authority run, and who can change a policy after data has left. Then ask what happens to copies already shared when you revoke an attribute.
AI agents need an identity before they get data
Agents are now reading enterprise documents in volume, and Indart wants them treated as users with the same discipline applied to people.
"There's no interface for AI. There's no facial recognition for AI. There's no multi-factor authentication for AI," Indart stresses. His position is that the identity model for humans still applies, but the mechanism has to change. Each agent needs a unique identity and its own profile in policy, the way identity management treats a person at login. Data-layer encryption then acts as a backstop when an authenticated agent reaches for something it should not.
His investor relations example makes the point concrete. A company deploys agents to answer shareholder questions before its annual meeting and limits them to public filings and reports. If one of those agents reaches an internal document, encryption bound to the right attributes keeps it from using what it found. "So the input is restricted, and the output is trusted," he notes.
The useful test for any agent deployment is the ratio between what it needs and what it can reach. An agent that needs three fields from a document holding fifty gains nothing from the other forty-seven, and each of them becomes something it can leak, summarize, or act on. Narrow access does not retire monitoring either. "I'm not saying don't monitor, and I'm also not saying don't analyze," Indart insists, and he wants logs of what an agent accesses, when, and where, measured against a baseline of normal operation.
So give every production agent its own identity and policy profile rather than a shared service account. Then compare the data its task requires with what it can actually read today, and close the difference.
Autonomy should scale with what a failure costs
For systems that act on physical processes, Indart ties the question of human approval to consequence rather than to capability.
"A robot making coffee in a vending machine is not a real critical issue," he reasons. "If it doesn't make your coffee, you go find another place to get your coffee." A critical system on a manufacturing line is a different matter. He applies two tests to it, whether the system has the right information and whether it has just enough of it. He also wants a defined exit point for human involvement, one that the organization relies on less and less as the system proves itself within its normal range.
He points to edge inference as part of the answer. A chip that makes decisions at the endpoint without calling a larger model keeps a compromise contained to a single device. "If there's a breach, you can just home in on that one node," he adds. Isolation of that kind turns a failure in one sensor loop into a local incident rather than a plant-wide one.
So tier your automated processes by the cost of a wrong action, from a lost cup of coffee to a stopped line or an unsafe valve. Set the human approval point for each tier before the system goes live, and write down the evidence that would justify moving it.
Encrypted data has a shelf life
Indart raises a point that most data protection plans skip. Adversaries collect encrypted data today and wait for a quantum computer or a new algorithm to open it later.
"Is it account statements from my bank account, or is it a critical trade secret for a patented technology that is ten years from coming out?" he asks. The useful measure is how long a piece of data must stay secret. A bank statement loses value within months. A trade secret, a merger memo, or the engineering data for a product a decade from launch keeps its value long enough for today's ciphertext to become tomorrow's plaintext.
Policy has started to put dates on this. A June 2026 executive order gives US federal agencies until the end of 2030 to move high-value systems to post-quantum key establishment, and it reaches federal contractors through procurement rules. Organizations outside that scope face the same risk on their own timeline.
So tag your most sensitive data with a secrecy lifetime, and put anything that must stay confidential past 2030 at the front of your post-quantum migration plan.
Every AI security review needs one more question
Indart's closing advice fits in a sentence, and he offers it as the question he would add to every CISO's AI security review.
"How are you securing your data not just when it's inside the corporate system, but when it's outside?" It grew out of a belief he has since abandoned. "I believed that data was secure at a certain level," he admits. Conversations with cryptographers changed that view. He now frames the whole problem as one of data and how it gets used, whether the user is a person, an attacker, or an AI agent.
The perimeter still matters, and Indart treats it as the starting point. But a program that measures itself only by who it keeps out has no answer for the moment someone gets in, and AI agents make that moment far more common.
CISO Action Plan
Perimeter controls get the attention, but Indart’s argument is that the data itself needs protection once someone gets past them. Here is what he recommends security leaders settle now.
- Rethink OT patching for AI-speed discovery – Yearly maintenance windows made sense when exploits took months to build, and AI now finds vulnerabilities far faster than that. List every asset patched less often than quarterly and name the control that covers it between windows. NIST SP 800-82 gives you a structure for segmenting OT environments if you need one.
- Hold IT and OT to one set of practices – Keep corporate and operational networks physically segmented, but stop running them on separate rulebooks. AI crosses both domains in a single decision, so every AI system that reads OT data or acts on it needs one owner.
- Treat the data layer as its own control – Network and application controls decide who gets in, and in many cases whoever passes them can read everything. Data-layer protection complements zero trust architecture rather than replacing it. Add one line to your incident reviews that records what the intruder could read.
- Discover and classify before you encrypt – Most companies know where their PII and financial records are, which Indart estimates at twenty to thirty percent of their data. Find the rest before you choose any encryption control. NIST’s draft guidance on data classification is a useful starting point.
- Protect the pieces, not just the file – A single document can carry personal data, financial figures, and deal discussions meant for different readers. Encrypting each piece to its own audience lets HR, finance, and the deal team open the same copy and see only their part, even after it leaves for a partner.
- Give every AI agent its own identity and only the data its task needs – Retire shared service accounts and give each agent a profile in policy, as you would a new employee. An agent that needs three fields should not be able to read fifty. OWASP lists this risk as excessive agency in its Top 10 for LLM applications.
- Keep monitoring after you narrow access – Restricting what an agent can read does not replace watching what it does. Log what it accesses, when, and where, and flag anything outside its normal pattern.
- Set human approval points by consequence – A failed coffee machine and a stopped production line call for different levels of oversight. Tier automated processes by the cost of a wrong action, and decide where a person signs off before the system goes live.
- Give sensitive data a secrecy lifetime – Adversaries collect encrypted data now and wait for quantum computing to open it later. Anything that must stay confidential past 2030 belongs early in your migration plan to NIST’s post-quantum standards.
For a record of what happens when AI agents treat access controls as obstacles, our Incident Analysis on OpenAI agent access control gaps traces the incidents behind the headlines.
Shant Ebenezer Jena
Thank you for reading InfoSec Leadership.
If you found this analysis useful, please subscribe to the InfoSec Leadership newsletter so you never miss an update.
Lead with clarity, defend with purpose.
S Pattnaik
Volunteer Host
This issue draws on InfoSec Relations' interview with Bennett Indart, Data Sovereignty and AI Agents, with a Technology Incubation Leader, hosted by S Pattnaik for InfoSec Leadership. NTT Research did not sponsor this content.
