Site icon Kartaca

Should an AI Agent Be Allowed to Touch the Factory? A Security Model for Industrial AI Agents

kartacabilisim

Should an AI Agent Be Allowed to Touch the Factory? A Security Model for Industrial AI Agents

For decades, industrial environments have been built around a clear separation of responsibilities. An operator can monitor a production line. A maintenance engineer can diagnose equipment. A controls engineer can change machine parameters. A plant manager can approve certain operational decisions.


The permissions are designed around the potential impact of each action. Now AI agents are beginning to enter that environment. An industrial AI agent can read production telemetry, analyze anomalies, identify potential causes, recommend maintenance actions, create work orders, and, increasingly, interact with operational systems. That creates a new security question for manufacturers:


How much authority should an AI agent have inside the factory? The answer can’t simply be “whatever access the application needs.”


An AI that observes a production line doesn’t need the same permissions as an AI that changes a production parameter. That distinction becomes critical as manufacturers connect AI agents to OT systems, manufacturing execution systems, enterprise applications, data platforms, and industrial equipment.


The opportunity is significant. So is the potential blast radius of getting the permissions wrong.


The Factory is Becoming An Agentic Environment

Manufacturers have already spent years connecting machines, sensors, MES platforms, ERP systems, historians, data warehouses, and cloud environments. Those connections created the foundation for industrial analytics. AI agents add another layer.


Instead of simply collecting and visualizing data, an agent can potentially interpret what it sees and take the next step. Consider a production anomaly. A traditional monitoring system might detect that a machine’s vibration has exceeded a threshold.


An AI agent could go much further:

  1. Read sensor data
  2. Compare current behavior with historical patterns
  3. Identify a potential fault
  4. Analyze related production conditions
  5. Recommend an inspection
  6. Create a maintenance request
  7. Check spare-parts availability
  8. Schedule maintenance
  9. Potentially modify an operational setting

Every step can create value. Every step can also require a different level of authority. The agent that needs permission to read vibration data shouldn’t automatically receive permission to change the machine producing that data.


The Industrial Least-Privilege Problem

The principle of least privilege is familiar in cybersecurity. Give an identity only the access it needs to perform its intended function. In an industrial environment, that principle has another dimension: physical consequence.


Changing a value in a cloud database and changing a parameter in a production system can have very different consequences.


An incorrect change to an operational system could affect:


This means agent permissions should reflect not only what an agent can technically access, but also what could happen when it acts.


A useful industrial AI permission model can be built around six levels:


Read → Analyze → Recommend → Request → Change → Execute


The further an agent moves along this spectrum, the more restrictive its controls should become.


Level 1: Read production telemetry

The lowest level is observation. An agent can retrieve information from approved sources such as:



At this stage, the agent isn’t changing anything. This is where many manufacturers can begin experimenting with industrial AI.


For instance, an agent could monitor vibration, temperature, pressure, throughput, or cycle times and identify unusual patterns. Its access should still be scoped.


A predictive-maintenance agent doesn’t necessarily need access to every production line in every plant. It might only need read access to specific assets, data streams, or production areas. That gives manufacturers an immediate application of least privilege:


Give the agent access to the telemetry required for its job, not the entire industrial data environment.


Level 2: Analyze anomalies

The next level gives the agent permission to process and interpret data. This is where AI becomes particularly useful.



The agent is generating intelligence. It still doesn’t need permission to change the underlying system. This separation matters because analytical and operational authority are distinct. An agent can be highly capable at identifying a problem while remaining completely unable to change the production environment.


Level 3: Recommend an action

Now the agent can turn its analysis into a recommendation.


For example:


Recommendations can be valuable because they reduce the amount of interpretation required from engineers and operators. But recommendations should remain distinguishable from execution.


The agent can explain what it believes should happen. A human or policy-controlled system can determine whether that action should actually occur. This distinction becomes particularly important when the recommendation affects production, safety, or equipment.


Level 4: Create a maintenance request

The next step is operational, but still relatively contained. An agent can create a maintenance request in an EAM or CMMS system based on its analysis.


For example:


Agent detects anomaly → Analyzes equipment → Recommends inspection → Creates work order


The agent has now moved beyond information processing. It is creating a business or operational record. But the potential impact is still bounded.


Creating a maintenance request doesn’t directly modify a machine. That makes it a useful intermediate step for manufacturers exploring agentic workflows. The agent can perform meaningful work while the actual intervention is handled by an authorized human or an operational process.


Level 5: Change an operational system

The risk changes significantly when an agent can modify a production or operational system.


Imagine an agent that can:


At this point, a simple application-level permission isn’t enough. Manufacturers need to define exactly:


Consider a temperature setpoint. An agent might be allowed to adjust it within a predefined range. For example:


Allowed: 180°C to 190°C
Outside policy: Human approval required


That creates a controlled boundary around the agent’s authority. The agent can act autonomously where the business has explicitly decided that autonomy is acceptable.


Level 6: Execute an OT action

The highest level is direct interaction with operational technology. This could include actions that have immediate physical consequences. At this level, the security model needs to be extremely deliberate.


An agent that can directly execute an OT action should have:


Critically, the agent should never acquire these permissions simply because they’re technically convenient. The fact that an API exposes a function doesn’t mean an AI agent should be allowed to call it.


An Industrial Agent Permission Matrix

Manufacturers can make these boundaries more tangible by mapping agent capabilities against authority levels.


Agent Action Authority Example Control
Read production telemetry Automatic Read-only access to approved data sources
Analyze anomalies Automatic Scoped data and compute access
Recommend an action Automatic Recommendation logged for review
Create maintenance request Automated Limited write access to CMMS/EAM
Change operational parameter within approved range Controlled automation Policy-based limits
Change parameter outside approved range Human approval Explicit authorization required
Modify critical production configuration Human approval Segregation of duties
Execute high-impact OT action Highly restricted Multiple controls and explicit approval

This matrix should be created before the agent is connected to production systems. It turns an abstract security discussion into an engineering decision.


IT and OT Shouldn’t Have the Same Permission Model

One of the biggest challenges in industrial AI is the IT-OT boundary.


A cloud-based AI platform might need access to manufacturing data. That doesn’t mean the AI platform should have direct access to operational controls. A safer architecture can separate the layers. For instance:



The AI agent can often operate on contextualized industrial data without receiving unrestricted access to the underlying control environment. When an action needs to move back toward OT, it can pass through controlled interfaces and policy enforcement points. This separation helps reduce the blast radius of an agent compromise or unexpected behavior.


Don’t Give An Agent the Keys to Every System

Industrial workflows are interconnected. A maintenance agent might need to interact with the CMMS, inventory system, production data platform, and ERP. That doesn’t mean it needs access to every function exposed by those systems. Consider an agent with access to a maintenance platform.


It may need to:


It may not need to:


The same principle applies to tools and APIs. If an agent doesn’t need a function, don’t expose the function to the agent. As agentic architectures increasingly use tool-based interactions, including MCP, manufacturers should treat each tool as another permission boundary.


Google Cloud’s July 2026 IAM guidance shows how least privilege can be enforced through narrowly scoped roles, IAM Conditions and Deny policies, including fine-grained controls over MCP services and tools. Google’s documentation also recommends using IAM attributes to prevent read-write access to MCP tools on important resources where appropriate.


In industrial environments, this points toward a more granular model: an agent might be allowed to call a telemetry tool but denied access to a tool that changes a production parameter.


Context Should Influence Authority

The same agent may require different permissions depending on the circumstances.


Imagine a production optimization agent.


The permission model could consider:


This is where Google Cloud IAM Conditions can provide more granular access controls.


Instead of defining access as: “The optimization agent can modify production systems.”, the policy can become: “The optimization agent can modify approved parameters on Line 4, within defined limits, during an approved maintenance window, using the designated operational interface.”


That’s a very different security boundary.


Human-in-the-Loop Doesn’t Mean Human-for-Everything

A common reaction to industrial AI risk is to require human approval for every agent action. That can make the system too slow to deliver meaningful value. Industrial environments already automate many operational processes and control actions. A more practical approach is to distinguish between actions with different levels of operational impact.


For example:


Action Potential model
Read telemetry Automatic
Detect anomaly Automatic
Analyze root cause Automatic
Create maintenance request Automatic within policy
Recommend parameter change Automatic
Apply minor parameter adjustment Automated within approved range
Change critical process parameter Human approval
Modify safety-related configuration Restricted or prohibited
Execute high-impact OT action Explicit approval

This creates a graduated model of autonomy. The agent gets more freedom where the risk is manageable and encounters stronger controls where the consequences are greater.


Design for the Blast Radius

Manufacturers should ask a simple question for every agent: If this agent’s credentials were compromised, what could it change?



Blast-radius thinking can be applied to:


Production agents should use dedicated agent or workload identities wherever practical. Google Cloud recommends separate identities for production MCP workloads so permissions can be limited independently and agent activity can be attributed in logs.


A predictive-maintenance agent shouldn’t automatically inherit the permissions of an operational-control agent simply because both are part of the same AI platform.


Monitor What the Agent Actually Does

Permission design answers one question: What can the agent do?

Monitoring answers another: What did the agent actually do?


Manufacturers should be able to trace:


This creates an operational audit trail. It also helps identify permission creep. An agent might begin with read-only access and gradually gain additional capabilities as its use case expands. Regular reviews can determine whether those permissions are still justified.


Start with the Action, not the Agent

When manufacturers evaluate industrial AI, it’s tempting to start with the technology.



Those are important decisions. But security starts with the workflow. Before connecting an agent to a production environment, define:


  1. What business or operational problem is the agent solving?
  2. What data does it need?
  3. What systems does it need to access?
  4. Which tools does it need?
  5. What can it recommend?
  6. What can it change?
  7. What can it execute?
  8. Which actions require approval?
  9. What limits apply to autonomous actions?
  10. How will every action be monitored and audited?

Only then should those requirements become identities, permissions, policies, APIs, and technical controls.


From Industrial AI to Controlled Autonomy

The future factory won’t simply contain more AI. It will contain AI that can increasingly interact with the systems running the factory. That creates enormous potential.


An agent could identify a developing equipment problem before failure. It could correlate signals across production systems. It could prepare maintenance actions. It could optimize processes within defined boundaries. And eventually, some agents may execute operational actions with limited human intervention.


But autonomy needs a boundary. An AI that observes a production line doesn’t need the same permissions as an AI that changes a production parameter.


A practical way to model industrial agent authority is:


Read → Analyze → Recommend → Request → Change → Execute


Each step should have its own permission boundary, risk assessment, monitoring, and approval requirements. This approach allows manufacturers to move toward agentic operations without treating every AI capability as an unrestricted operational identity.


Building a Secure Foundation for Industrial AI

Agentic AI can connect data, analytics, enterprise workflows, and industrial operations in ways that weren’t practical before. But the architecture underneath those agents matters just as much as the model itself.


Kartaca helps manufacturers build cloud, data, AI, and IIoT architectures that connect industrial environments with modern data and AI platforms while keeping security, governance, and operational control at the center.


Whether you’re exploring predictive maintenance, production optimization, intelligent quality control, or industrial AI agents, the starting point should be clear: Give the agent enough authority to create value, but no more authority than the workflow requires. That’s how manufacturers can move from AI experimentation toward controlled, scalable industrial autonomy.


Contact us today to explore what controlled agentic AI could look like for your manufacturing environment.


Author: Gizem Terzi Türkoğlu

Published on: Oct 26, 2026



Exit mobile version