Every AI tool is a new connection
The conversation around AI and cybersecurity has become all too common, but it often overlooks the architectural reality. Adopting AI is not simply installing new software, but more like opening a new set of doors to your factory. Every cloud-connected AI deployment requires outbound data paths, inbound endpoints, and credentials being issued.
Recent industry numbers did confirm the risk this sits on top unmistakable. Ransomware attacks against industrial organizations rose 64% year over year, with manufacturing accounting for more than two-thirds of all victims. That represents 119 ransomware groups impacting over 3,300 industrial sites in a single year, according to Dragos 2026 OT/ICS Cybersecurity Report.
The plant is already a target. The only question that matters for any new AI deployment is whether it widens that attack surface.
Why the threat model is shifting toward systemic operational risk
To answer this question, you have to look at how threat actor behavior is evolving.
Factory OT is governed by continuous availability and physical safety, making regular update cycles nearly impossible, leaving them riddled with unpatched vulnerabilities. Consequently, detection capabilities on the floor remain severely limited, with 88% of industrial networks currently lacking effective host-level detection and response coverage (per Dragos). Threat actors know this, and their tactics have shifted accordingly.
TCS’s 2026 Cyber Threat Landscape Report confirms: Incidents originating in enterprise IT are now designed to cross directly into production. Attackers use the IT network as a gateway into OT simply because factory systems can’t detect or respond at IT speed. To maximize disruption, they are targeting virtualization infrastructure, like ESXi hypervisors, allowing them to take down multiple workloads simultaneously while bypassing traditional endpoint defenses.
When detection is structurally weak, prevention has to move upstream, to the architecture itself. In other words, when your house cannot count on catching a burglar once they’re inside, the smarter move is not installing doors you don’t need in the first place.
The three exposures AI adoption adds
So what exact doors does adding AI open? Every AI deployment fundamentally alters the shape of your network by introducing three distinct exposures.
First, outbound data flows.
When an AI system relies on external processing, highly sensitive telemetry (continuous production video, real-time cycle times, yield metrics…) must physically leave the site. Notably, this continuous connection creates a two-way bridge. Hybrid cloud adoption has introduced new attack pathways, with threat actors using VOIDLINK malware to pivot directly from compromised cloud workloads into on-premise industrial environments.
Second, inbound dependencies.
Cloud-connected AI inherently requires open doors from the outside in. To function, factories must maintain active public cloud endpoints and third-party vendor remote access. TCS’s 2026 Report names exploitation of internet-facing applications and abuse of remote access services among the most common entry paths into manufacturing networks. This is a severe vulnerability.
Third, machine identities.
Deploying an autonomous AI agent creates a new, non-human “user” on your network requiring API keys and access privileges to operational databases. Every new identity is a set of digital keys that can be hijacked by threat actors. The scale of this credential expansion is staggering: UK businesses are adding roughly 10,000 identities monthly, according to SailPoint data cited by Make UK. That footprint becomes a liability, as credential theft and session hijacking have overtaken malware as the primary intrusion mechanism industry-wide, per TCS. Fueled by infostealers like Lumma Stealer harvesting authentication tokens at scale, stolen machine credentials allow threat actors to mimic legitimate network access and slip past security monitoring tools undetected.
Crucially, not all of these vulnerabilities are inevitable consequences of using AI. They are structural choices. The extent of your outbound flows, inbound endpoints, and machine identities is dictated entirely by your chosen architecture.
Where the technical risk becomes a business one
What these three exposures put at risk isn’t only operational uptime. It compounds directly with how attackers now monetize industrial access.
According to the TCS’s 2026 Report, adversaries are shifting toward extortion-first attack models. Rather than triggering a detectable system encryption, threat actors now prioritize the silent exfiltration of high-value intellectual property (engineering blueprints, CAD designs, proprietary formulas…) and apply pressure through public disclosure threats.
On the manufacturing floor, this data sensitivity is tied directly to legal contracts and competitive advantage rather than basic internal privacy. The core assets targeted during these exfiltration campaigns include:
- Customer product images: Visuals of unreleased products expose intellectual property (IP) and risk market leaks.
- Operator videos: Footage of workers triggers strict regional privacy laws and labor union compliance.
- Line performance data: Yield rates, cycle times, and throughput numbers are usually protected by strict Non-Disclosure Agreements (NDAs).
For specific industries, such as EMS and ODM plants, the production data an AI vision system touches belongs to global brand customers, not the factory itself. Therefore, moving this data to a third-party cloud violates customer contracts before it even triggers a cybersecurity breach. It is a contractual question before it is a security one.
Cloud vs. On-premise: Measuring the exposures
Protecting those sensitive data ultimately needs us to come down to network architecture. When measuring the two primary AI deployment models against those three network exposures, the trade-offs are clear.
Cloud vs. On-premise AI Architecture Comparison
A cloud-dependent system adds all three by design. To deliver real-time insight, it must continuously ship production video, cycle data, and yield metrics off-site. To stay functional, the factory must leave inbound cloud endpoints and vendor remote-access channels open permanently. And the plant no longer manages only its own risks; it inherits every vulnerability in the supplier’s system, along with all the machine credentials required to operate it.
An on-premise architecture neutralizes the first two exposures entirely and safely contains the third. Because data processing and AI inference happen on dedicated servers inside the factory walls, the system adds zero outbound data flows and requires no inbound public endpoints. And while the AI system still requires its own machine identities to function, those digital credentials remain strictly confined behind your firewall. By sitting inside your existing OT segmentation, the deployment can run on fully isolated networks, ensuring your digital keys are never exposed to the outside world.
Processing locally is a structural trade-off, not a magic shield. By choosing an on-premise model, the plant assumes full responsibility for managing software patches internally and ensuring the physical security of the edge servers on the shop floor. But in exchange, you retain absolute authority over your network doors.
HOP: Built to stay inside the plant
PowerArena’s Human Operation Platform (HOP) is an AI vision system designed specifically to analyze human operations on the assembly line. Because it handles the most sensitive visual data a factory produces, we built it to stay entirely inside the plant.
HOP runs on dedicated edge servers deployed physically on your shop floor. All video feeds, cycle times, and production metrics are processed and stored locally. There is no cloud round-trip required for the AI to function. Because it is built to operate within your existing OT segmentation, it does not require a single inbound public endpoint to do its job.
To be clear, HOP is not a cybersecurity product. It will not secure your existing networks or patch your firewalls. What it is, instead, is a highly capable AI deployment that refuses to add a new door for attackers to open. You gain the operational visibility of an autonomous vision system without expanding your attack surface. You can even configure HOP to export only high-level data to your secure IT dashboards, ensuring the raw video and line-level data never leave the facility.
Governance: A checklist for the plant floor
Global OT security spending is projected to reach $30.9 billion in 2026, according to IIoT World’s 2026 OT Cybersecurity Guide. But throwing capital at the problem does little good if the fundamental architecture question is never asked.
Currently, only 23% of manufacturing companies employ a dedicated Chief Information Security Officer, according to Make UK. That means, at most facilities, the decision to deploy a new AI tool rests with a Plant Manager or a Regional IT Lead.
To ensure the safety of your plant, here’s the architecture checklist to ask any industrial AI vendor:
- Where exactly is the data processed?
- What specific data must leave the site for the system to function?
- What inbound remote access or continuous update channels do you require?
- What new machine credentials or identities does this system create on our network?
After all, governance cannot be merely an abstract company policy. It has to function as a filter applied at vendor selection, before deployment.
Architecture is a decision, not an afterthought
The manufacturers who navigate the next wave of automation successfully will be the ones who treated architecture as a strategic choice made before deployment, not a detail discovered after an incident report. You cannot control the number of attacks targeting the manufacturing sector, but you absolutely can control the number of external doors you install on your factory floor.
When you evaluate an AI vendor, is “where does our data go” on your checklist? And more importantly, who owns that question in your plant?
Curious how your team is approaching this.
Further reading:
Table of Contents
