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:

• Product quality
• Production continuity
• Equipment safety
• Maintenance schedules
• Material consumption
• Energy usage
• Worker safety
• Regulatory compliance

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:

• PLC telemetry
• Sensors
• Industrial gateways
• Historians
• MES data
• Equipment status
• Production metrics
• Energy consumption
• Quality measurements

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.

• A predictive-maintenance agent might identify: “Vibration and temperature patterns on Pump 14 have deviated from the historical operating range.”
• A quality agent might identify: “The defect rate on Line 3 has increased following a change in operating conditions.”
• An energy agent might identify: “Power consumption during this production cycle is significantly above the expected range.”

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:

• “Inspect Pump 14 within the next maintenance window.”
• “Reduce Line 3 operating speed by 5% while the quality deviation is investigated.”
• “Schedule maintenance for the next available production downtime.”

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:

• Change machine setpoints
• Modify production parameters
• Update process recipes
• Change production schedules
• Adjust equipment configurations
• Modify MES workflows

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

• Which system?
• Which resource?
• Which parameter?
• Which value range?
• Under which conditions?
• For how long?
• With whose approval?

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:

• A clearly defined identity
• A narrowly scoped purpose
• Access to only required systems
• Explicit operational boundaries
• Policy enforcement
• Approval controls where appropriate
• Strong authentication
• Detailed audit logging
• Continuous monitoring
• A clear emergency stop or revocation mechanism

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.

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:

• OT layer: Machines, PLCs, sensors, industrial control systems
• Industrial data layer: Gateways, historians, event streams, contextualized production data
• Manufacturing application layer: MES, EAM/CMMS, production planning and quality systems
• Enterprise and AI layer: ERP, cloud data platforms, analytics, AI agents

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:

• Read asset history
• Read maintenance records
• Create work orders
• Update work-order status

It may not need to:

• Delete maintenance records
• Modify asset configuration
• Change production schedules
• Approve maintenance expenditure

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.

• During normal operation, it might be allowed to recommend adjustments.
• During a planned maintenance window, it might be permitted to execute a broader set of changes.
• During an emergency, its permissions might be reduced or revoked entirely.

The permission model could consider:

• Production line
• Plant
• Equipment type
• Operating state
• Maintenance window
• Time of day
• Parameter range
• Production order
• User or workflow initiating the request
• Current risk state

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:

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?

• If the answer is: “An entire production environment.”, that’s a strong signal that the agent’s permissions should be reconsidered.
• If the answer is: “Telemetry from three approved machines and maintenance requests for those assets.”, the blast radius is much more manageable.

Blast-radius thinking can be applied to:

• Data sources
• Plants
• Production lines
• Equipment
• APIs
• Tools
• Parameters
• Transaction values
• Time windows

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:

• Which agent initiated an action
• Which identity it used
• Which data it accessed
• Which tools it called
• Which systems it interacted with
• What recommendation it generated
• What policy allowed or blocked the action
• Whether human approval was required
• What changed as a result

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.

• Which model should we use?
• Which agent framework?
• Which cloud platform?
• Which data architecture?

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.