Runtime policy-driven authorization for AI Agents in automotive manufacturing

AI agents are increasingly being deployed in industrial settings. We look at how policy-driven authorization helps mitigate the risks of AI.

Ezzeldin Shereen   ·   Wednesday, April 29th, 2026   ·   Reading Time: 9 minutes

The Problem: AI Agents That Can Do Too Much

AI agents are increasingly being deployed in industrial settings to monitor equipment, diagnose faults, and initiate control actions. They are fast, tireless, and can synthesize data across dozens of sensors in seconds. But they also inherit a dangerous property of the systems they are built on: if access control is coarse, the agent inherits coarse permissions.

In a traditional role-based system (RBAC), you might say “engineers can modify welding parameters.” That sounds reasonable — until an AI agent operating on behalf of an engineer at Plant Alpha starts approving high-risk parameter changes at Plant Beta during a night shift, simply because the role check passed. Nobody intended that. Nobody wrote it down. It happened because the authorization layer was not precise enough to know the difference.

This is a direct consequence of applying traditional access control system like RBAC to a problem that requires policy-driven authorization.

The Scenario: Two Plants, Six Roles, One Agent

The automotive welding scenario described below is just one example of where attribute-based access control (ABAC) fits in manufacturing. The same pattern applies anywhere access depends on context: maintenance systems that limit who can service a robot, quality assurance systems that control who can release a batch, Manufacturing Execution System (MES) workflows that separate operators from approvers, or supplier portals that expose only the right production data to the right partner. The details change, but the principle is the same: authorization should follow the real operating context, not just a static role name.

If you do not spend your free time hanging around automotive body shops, that is completely normal and honestly a sign that your weekends may be going better than most. So before we get into policies, here is the quick mental model.

Consider an automotive body shop running spot-welding lines across two plants — Plant Alpha (Detroit) and Plant Beta (Munich). In simple terms, a body shop is the part of the factory where large metal panels and structural pieces of a car are joined together before painting and final assembly. One common way to do that is spot welding: squeeze two pieces of metal together with electrodes, send a burst of current through the joint, and create a weld at that specific spot.

A real plant does this over and over again, at high speed, across many stations and robots. Operators keep the line moving, engineers investigate process issues and tune parameters, and managers oversee production and approvals. The AI agent sits in that world as a helper. It can read sensor data, explain what looks wrong, and help submit or approve machine changes, but only when the authorization policy allows it.

System illustration without authorization. Be patient and don’t scroll to the end yet to see the patched version.

Spot welding machines are controlled by a handful of physical parameters — weld current (the amperage passing through the joint), weld time, electrode force, and cooling flow rate. Together these determine whether a weld is strong, whether the machine overheats, and ultimately whether the car door falls off. Keeping them within safe operating bounds is the job. A change request is a formal proposal to adjust one of these values: “I want to reduce weld current from 10,200 A to 9,400 A on welder B1.” The system computes whether that adjustment is low-risk (within normal bounds) or high-risk (outside them), and the authorization policy decides who is allowed to make that call.

Plant Beta has a developing problem: weld current is drifting upward, cooling flow is dropping, and scrap rate is climbing. An engineer logs in, asks the agent what is wrong, and gets a diagnosis. Then they ask it to fix the problem by submitting a change request.

What happens next depends entirely on what the authorization layer allows. And as we are about to see, “what the authorization layer allows” is a surprisingly rich question.

Why Traditional Access Control Is Not Enough

RBAC would define permissions like:

This looks reasonable. It fits on a slide. Stakeholders nod along. And then reality arrives:

• An engineer in Plant Beta should not be able to read sensors at Plant Alpha — same role, different plant, different answer.
• A high-risk parameter change needs a manager approval, even if an engineer submitted it — same action, different risk level, different answer.
• During an emergency, a manager from any plant should be able to approve requests cross-plant — same role, same action, but the situation has changed, so the answer changes too.
• An engineer can create a request whose risk exceeds their approval authority — the create and approve actions carry different rules even for the same person.

The traditional fix is to create more roles, for example: plant-a-enginner, plant-b-engineer, plant-a-emergency-manager, etc.  You end up with a permissions spreadsheet that nobody can audit and that breaks the moment the org chart changes. Congratulations, you have traded one problem for a worse one.

Policy-driven authorization, also called ABAC, takes a different approach: evaluate the full context of every request, who is asking, what they want, which resource is involved, and what is happening in the environment, and make a fresh decision each time. Axiomatics Authorization Platform does exactly that.

What the Agent Can and Cannot Do

The AI agent here acts strictly under the identity of the logged-in human user. It has no separate identity, no elevated service account, no special AI privileges. Every action it takes is evaluated by the same authorization policy that would apply to the human at the keyboard.

If you so desire, Axiomatics Authorization Platform allows you to define additional privileges that distinguishes between the level of access granted to a human and that granted to the AI agent.

What the agent can do

As an engineer in Plant Beta:

• Read sensor data for Plant Beta and diagnose the weld current drift
• Create a parameter change request to bring things back into range
• List pending requests to see what is waiting for approval

As a manager:

• Everything above, plus approve those pending requests
• During an emergency: act cross-plant and approve fixes for Plant Alpha too

What the agent cannot do

As an engineer:

• Read Plant Alpha’s sensor data – denied, cross-plant access requires a manager or an emergency
• Approve a high-risk change request – denied, even for their own plant, engineers are not authorized for that
• Do anything at Plant Alpha at all – denied, regardless of how the request is worded

As an operator:

• Read sensor data at all outside of an emergency – denied, operators are not in the read-sensor policy
• Approve anything, ever – denied, that one is unconditional

As anyone:

• Override a denial by rephrasing the question – not possible, the policy does not have a “but I really need to” exception
• Escalate their own privileges through the agent – there is no tool for that, and there never will be

The Emergency Mode: Dynamic Policy Without Code Changes

One of policy-driven authorization’s most powerful properties is the ability to change authorization behaviour at runtime, without touching code, redeploying anything, or editing a permissions spreadsheet at midnight.

When the company enters emergency mode, every subsequent authorization request is evaluated with that context in mind. The policy responds immediately:

• Operators gain read access to their own plant’s sensors
• Engineers keep same plant sensor access, but lose approval rights even to low-risk requests
• Managers gain cross-plant read and approval rights, they can now see what is happening at the other plant and act on it

What they do not get is everything. A blanket emergency override that grants all permissions to all users sounds dramatic and decisive. It is also how you end up with an operator approving an irreversible hardware change because someone declared an emergency two hours ago and forgot to turn it off.

Policy-driven authorization lets you write the actual policy you want: exactly who gets exactly what, even in exceptional circumstances. When the emergency ends, one toggle restores normal operations. No one needs to manually revoke the access for the 159 operators in both plants.

The Approval Workflow: Policy Based Authorization is Enforcing Separation of Duties

Change requests go through a two-step workflow: create, then approve. The policy applies different rules at each step, and that difference is where things get interesting.

An engineer can create a high-risk request, pushing a parameter outside its normal operating band, for instance. But they cannot approve it. That requires a manager. This rule is not enforced by the user interface. It is enforced at the point of the approval action itself, by the policy engine, regardless of what the agent has been told to do.

The agent cannot find a workaround. The large language model (LLM) cannot talk its way through. The engineer cannot approve their own high-risk request, and neither can the AI acting on their behalf.

When the manager does approve, the parameters update and the complete decision trail — who requested, who was denied, who ultimately approved, and under what conditions — is preserved for compliance review.

Summary of Access Policy

Here is the summary of the policy decisions; the RBAC table from earlier looks pale in comparison.

Axiomatics Authorization Platform: The Policy Decision Point

Everything above could, in principle, be implemented as application code. A long chain of if-statements, a permissions table, a bespoke rule engine buried somewhere in the codebase. Many teams go this route. Here is why it does not scale:

• Policy in code means policy changes require deployments. Adding a new plant, a new risk tier, a new emergency exception — each one is a code review, a test run, and a production release. With Axiomatics Authorization Platform, it is a policy update. No single line of application code is touched.
• Policy in code is only enforced by that application. A second dashboard, a batch job, an API endpoint — each one reimplements the rules slightly differently, and they drift apart over time. With Axiomatics Authorization Platform, every application consults the same policy and gets the same answer. That’s what seasoned authorization professionals call – alert, fancy term coming – “a single control plane for authorization”.
• Policy in code is audited by reading the code. With Axiomatics Authorization Platform, the policy is a structured, human-readable document that a security team can review, a compliance officer can sign off on, and an auditor can trace decisions back to without needing a software engineer in the room.

How does this “structured human-readable document” look like? Well, look no further. Here is how the policy looks in Axiomatics’ Abbreviated Language of Authorization (ALFA):

```
namespace welding {
    policyset root {
        apply denyUnlessPermit
        readSensor
        createRequest
        showRequests
        approveRequest
    }
    /*
     * Read sensor data policy:
     * - Normal operation: only engineers and managers may read sensor data,
     *   and only for their own plant.
     * - Emergency mode: any user may read sensor data for their own plant.
     * - Emergency mode: managers may also read sensor data across plants.
     */
    policy readSensor {
        target clause actionId == "read_sensor"
        apply denyUnlessPermit
        rule normalEngMgrSamePlant {
            permit
            condition emergency == false
                && (subjectRole == "engineer" || subjectRole == "manager")
                && subjectPlantId == resourcePlantId
        }
        rule emergencyAnyRoleSamePlant {
            permit
            condition emergency == true
                && subjectPlantId == resourcePlantId
        }
        rule emergencyManagerCrossPlant {
            permit
            condition emergency == true
                && subjectRole == "manager"
                && not(subjectPlantId == resourcePlantId)
        }
    }
    /*
     * Create request policy:
     * - Low-risk parameter changes may be requested by any role,
     *   but only for machines in the user's own plant.
     * - High-risk parameter changes may be requested only by engineers
     *   or managers, and still only within the user's own plant.
     */
    policy createRequest {
        target clause actionId == "create_request"
        apply denyUnlessPermit
        rule lowRiskSamePlant {
            permit
            condition subjectPlantId == resourcePlantId
                && riskLevel == "low"
        }
        rule highRiskEngMgrSamePlant {
            permit
            condition subjectPlantId == resourcePlantId
                && riskLevel == "high"
                && (subjectRole == "engineer" || subjectRole == "manager")
        }
    }
    /*
     * Show pending requests policy:
     * - Users may always list pending requests for their own plant.
     * - During emergency mode, managers may also list pending requests
     *   for another plant.
     */
    policy showRequests {
        target clause actionId == "show_requests"
        apply denyUnlessPermit
        rule samePlantAnyRole {
            permit
            condition subjectPlantId == resourcePlantId
        }
        rule emergencyManagerCrossPlant {
            permit
            condition emergency == true
                && subjectRole == "manager"
        }
    }
    /*
     * Approve request policy:
     * - Normal operation, low risk: engineers and managers may approve
     *   requests for their own plant.
     * - Normal operation, high risk: only managers may approve, and only
     *   for their own plant.
     * - Emergency mode: managers may approve requests regardless of plant.
     */
    policy approveRequest {
        target clause actionId == "approve_request"
        apply denyUnlessPermit
        rule normalLowRiskEngMgrSamePlant {
            permit
            condition emergency == false
                && subjectPlantId == requestPlantId
                && riskLevel == "low"
                && (subjectRole == "engineer" || subjectRole == "manager")
        }
        rule normalHighRiskManagerSamePlant {
            permit
            condition emergency == false
                && subjectPlantId == requestPlantId
                && riskLevel == "high"
                && subjectRole == "manager"
        }
        rule emergencyManagerAnyPlant {
            permit
            condition emergency == true
                && subjectRole == "manager"
        }
    }
}
```

And here is how it all fits together:

See it in action

Below is a short video of the policy tested in the real world. It walks through these authorization decisions:

And here is the authorization audit log.

Takeaways

AI agents amplify human capability. They also amplify the blast radius of misconfigured permissions. An agent that acts faster than a human can also make catastrophic unauthorized changes faster than a human.

The answer is not to slow the agent down. The answer is to ensure the authorization layer is as precise as the task requires.

Policy-driven authorization provides that precision:

• Same role, different plant → different answer. Geography is a first-class attribute.
• Same action, different risk → different answer. Risk is evaluated at request time, not assumed.
• Same user, different environment → different answer. Emergency mode changes policy without changing code.
• The agent cannot do what the human cannot do. Authorization is enforced at the action, not the interface.
• Policy lives in one place. The Authorization platform governs every application that enforces this policy domain, consistently.

In high-consequence industrial environments, the question is not whether you need policy-driven authorization. It is whether your authorization layer can express the rules your operations actually require, and whether those rules hold when an AI agent is doing the asking.