A line supervisor on an aerospace assembly line needs two documented signatures to deviate from a torque spec by 5%. The deviation form goes to quality engineering, gets reviewed against the control plan, and either clears or doesn't. The AI agent optimising your build sequence — the one someone in digital transformation connected to the MES six months ago — has write access to production schedules, routing parameters, and build orders. One of these has a control plan. The other has a Docker container and good intentions.

What over-permissioned actually means on your shop floor

The numbers landing this quarter — 60% of enterprise AI agents over-permissioned, adoption accelerating roughly fourteenfold — read like IT security headlines. In a manufacturing plant, they aren't. An over-permissioned agent isn't a data breach risk. It's an uncontrolled process change vector. Every industry conversation right now treats agentic AI as the next operational layer: scheduling, routing, parameter tuning, predictive maintenance triggers that adjust machine settings. F1 teams are deploying it. Siemens is scaling it. The adoption curve is real. What's missing from every one of those conversations is the question a quality auditor would ask: who approved this process change, and where is the trail?

Over-permissioned in enterprise IT means an agent can read data it shouldn't or send emails with borrowed credentials. Real problems, yes. But when I walk into a plant, the question isn't what the agent can see — it's what it can change. An agent with write access to the MES isn't reading your production data. It's altering your production reality. It can reroute a build sequence so that a sub-assembly hits a station configured for a different variant — different torque program, different pressure test parameters, different inspection criteria. It can compress curing times or skip a buffer step your PFMEA identified as a risk control. And it can do all of this without triggering a single deviation flag because, from the system's perspective, nothing deviated. The system executed a command from an authorised account.

The problem isn't malicious AI. I don't lose sleep over that. The problem is an agent optimising for an objective function nobody mapped to your quality constraints — schedule throughput against the minimum dwell time your paint process needs for adhesion, for instance. The agent doesn't know it's making a process change. It thinks it's reducing idle time.

A process change that nobody authorised isn't an innovation — it's a nonconformance you haven't detected yet.

The two frameworks that both miss it

Here is the structural gap. Your IT security team audits human accounts. They check role-based access, privileged identity, MFA coverage. They are not looking for a service account running an inference model that can write to a manufacturing execution system, because nobody told them that counts as a process authority. Your quality team audits process compliance. They walk the floor with checklists against AS9100 or IATF 16949. They review deviations, nonconformances, corrective actions. They are not looking for an agent in the schedule because nobody told them the schedule was machine-generated outside the deviation process. The agent sits in a gap between two audit frameworks designed for a world where every process change had a human name on it.

I spent my CEH training learning to think like the person trying to break a system rather than the one defending it. The mindset transfers directly: where is the control that doesn't exist? When I built MultiPS — the multi-model platform running 63 models in parallel with consensus synthesis — the first architectural decision wasn't about model selection or output quality. It was about what the models could not do. Every model operates under a constrained permission set by design. No model executes an action without a validation gate. The consensus mechanism isn't just about answer accuracy — it's a structural control. If models disagree, the system doesn't act. Least privilege isn't a principle you bolt on afterwards. It's the foundation you start with, or you don't have it.

That same thinking needs to enter the plant.

Mapping agent permissions to the authority you already have

The answer isn't to ban agents from operational systems. That ship has sailed, and you'd be surrendering genuine capability. The answer is to map agent permissions to the approval authority structure you already have. If a schedule reroute requires a production manager's sign-off when a human initiates it, an agent initiating that same reroute requires the same authority — documented, logged, and reviewable.

  • Read access to MES, ERP, quality dashboards — low risk, broadly available to agents, same as it is for operators on the floor.
  • Parameter adjustments within validated ranges — require a control plan linkage. The agent operates inside a corridor quality engineering has already approved, and the corridor boundaries are enforced by the system, not by the agent's judgement.
  • Process changes outside validated ranges — full deviation process. No exceptions. If it would need a human signature, it needs one regardless of whether the request originated from a neural network or a night shift lead.

This isn't invented from scratch. Your access control framework already understands the concept. Your deviation process already understands the concept. The governance tools emerging from IT security vendors will help with credentials and agent-level access. They won't know your control plan from your conveyor schedule. That mapping is yours to build.

Last audit cycle, we drove a 50% reduction in EASA findings through disciplined application of existing quality controls — nothing exotic, just rigour applied consistently. The next cycle will be different. Auditors are already encountering AI-initiated changes during evidence reviews and asking questions the frameworks weren't written to answer. When an auditor asks who authorised a process change and the answer is "the scheduling algorithm," you have a finding. You just don't know it yet.

Key takeaways

  • Map every agent with write access to a manufacturing system against your existing approval authority matrix — if it can change a process parameter, it needs a defined equivalent to human sign-off.
  • Separate agent permissions into read, bounded write within validated corridors, and deviation-triggered requiring a human gate — the same structure your control plan already uses.
  • Brief your IT security team on what constitutes a process change in your plant, not just a data access event — they are currently auditing for the wrong risk category.
  • Build the agent permission matrix before the next external audit cycle — the first major finding for an uncontrolled AI-initiated process change will set the regulatory tone for the entire industry.

The first major audit finding for an uncontrolled AI-initiated process change hasn't landed yet. It will. When it does, the question won't be what the agent did — it'll be who gave it the access, and why nobody in quality was told that a piece of software now holds the same operational authority as a production manager. Your deviation process took decades to build. Your agent permissions took an afternoon to configure. That asymmetry is where the next finding lives.