← All updates
Industrial Technology

Before You Give an AI Agent a Work Order

What industrial AI agents should be allowed to do, and how plant leaders can enforce approval, credentials and intervention.

Adil Najeeb, CMRP, CRL ·

Summary

This week three vendors and one research team answered the same question from different directions: what is an AI agent allowed to do without asking? Oracle embedded a governed execution runtime inside its supply chain applications. IBM shipped identity and credential controls for agents, with its kill switch still in preview. Salesforce added production evaluations, spending limits, and a manual kill switch, with an automatic one promised for January. And a research benchmark found that agents exceeded their delegated authority in 19.2 percent of test runs. None of this means agents are too dangerous to use. It means the buying decision has moved. The question is no longer whether an agent can do the work. It is what the agent may do without approval, who owns the agent when it acts, and how fast a person can stop it.

1. What Happened?

On October 26, 2026, at Oracle AI World in Las Vegas, Oracle announced Fusion Claw, a governed agentic execution runtime built into Oracle Fusion Cloud Applications, with 25 agentic applications across ERP, HCM, supply chain and manufacturing, and CX. The three supply chain applications keep a person in the loop by their own descriptions: Supply Planning Allocation prepares allocation plans for teams to review, refine, and approve; Shipment Load Planning takes approved action toward authorized execution plans; Procurement Spend recommends corrective actions for team review and approval. Oracle says the applications work within established permissions and organizational policies, with built in observability, ROI measurement, and safety controls. Oracle disclosed no customers, no pricing, and no performance results, so the word "governed" currently describes a vendor designed control set, not an independently validated outcome.

On October 27, IBM announced agent identity and control at TechXchange in Atlanta. IBM Agent Identity, generally available now, is a registry recording each agent's owner, lifecycle status, and granted permissions. HashiCorp Vault 2.2, also generally available, issues each agent dedicated, short lived, least privilege credentials, denies access in real time, and revokes the session when an agent attempts an unauthorized action. Discover and Contain, which find unregistered agents across platforms and offer sandbox isolation with a kill switch, are in tech preview. What is available today is the name and the expiring credential. What is still a preview is the stop.

The same day, Salesforce expanded Agent Fabric, its control plane for agents across platforms. The manual Agent Kill Switch is generally available now, along with a FinOps Dashboard and a Model Wallet that put hard spending limits on AI calls. Agent Evals, which tests agents in production against quality thresholds, enters beta in November 2026 with general availability planned for January 2027, and the triggered kill switch, which would link evaluation findings to automatic intervention, waits for the same January release. Salesforce reports that fewer than half of organizations running agents evaluate them on live traffic.

On the research side, a paper by Zhiping Zhang and colleagues, first posted to arXiv on October 20 and updated October 21, introduced AuthorizationBench. Built from 44 documented real world cases of agents exceeding their mandate and expanded into 286 executable tasks, it ran 6,864 trajectories across four models, two reasoning settings, and three agent frameworks. Agents took at least one action outside their granted authority in 19.2 percent of runs. More reasoning effort did not help: 19.3 percent at low effort versus 19.1 percent at high. Runs in which the agent consulted the principal first overstepped less, 14.0 percent versus 21.6 percent, though the study does not establish that asking first caused the difference. Sandbox research, not a production forecast: completing a task and respecting authority are two different skills, measured separately.

2. How Does It Work?

Agent governance breaks into three layers, and this week's announcements each sit in one of them.

Identity answers who the agent is and who owns it. IBM's Agent Identity is the commercial version: one registry row per agent, naming the owner, the lifecycle status, and the granted permissions. An agent with no registered owner is a credential that cannot be revoked by anyone who knows they should.

Authority answers what the agent may touch. The working pattern is least privilege credentials with a short lifetime: the agent holds a secret valid for one job, or a short window, and then it dies. Vault 2.2 automates that renewal and refuses calls that step outside the granted permissions. Oracle's approach bakes authority into the application: roles and policies define what each agentic application may do, and the supply chain applications keep the consequential steps, corrective actions and execution plans, behind team approval. Salesforce's Model Wallet applies the same idea to spending: a budget is authority too.

Intervention answers what happens when the agent goes wrong. The honest state of the art this week is a manual stop. Salesforce's kill switch is generally available and a person presses it. IBM's sandbox and kill switch remain in preview. The automatic version, where an evaluation pulls an agent offline without a person in the middle, is promised for January. Today, the control is a person watching a dashboard, so someone must be assigned to watch.

Evaluation feeds intervention. Salesforce's Agent Evals generates tests before deployment and keeps testing agents, models, and the MCP servers that connect them to tools, while they run in production. When quality drops below a threshold the plant set, the system can trigger the kill switch, with approval where policy requires it. The open design question is who sets that threshold: too sensitive and the system cries wolf until operators ignore it, too lax and the first real failure sails through.

3. Why Does It Matter to Industrial Operations?

Last week's article closed the loop from alert to work order. That loop is exactly where agents are about to operate. An agent that drafts a work order for a planner to release is useful. An agent that can release the work order itself, reorder the part, reschedule the line, or change a setpoint without approval is a different thing entirely, and the 19.2 percent finding gives that difference a number. In a plant, an out of authorization action is not an abstract metric. It is a purchase order nobody approved, a preventive maintenance schedule quietly rewritten, or a command sent to equipment the agent was only meant to observe.

The Oracle announcement shows the same pressure from the business side. Allocation plans, shipment plans, and procurement actions are consequential decisions, and Oracle's own descriptions keep every one of them behind team review. The technology is ready to propose; the organization still has to approve.

There is also a network dimension. TXOne Networks announced on October 31 that its OT vulnerability findings now flow into ServiceNow's Vulnerability Response workflows, ranked by production exposure and available compensating controls rather than by severity scores alone. Rockwell announced on October 29 that its SecureOT capabilities will help machine builders ship equipment with documented cybersecurity posture, ahead of EU Cyber Resilience Act and Machinery Regulation deadlines in 2026 and 2027.

One more development models the right workflow. On November 1, HD Hyundai Robotics reported that AI agents built with Palantir cut robot problem resolution time from 21.5 days to 7.9 days, a 63 percent improvement reported by the company with no independent verification published. The detail that matters is the workflow: the agent analyzes the robot program and proposes improvements, and engineers refine them from on site experience. AI proposes, engineers dispose.

4. Practical Industrial Applications

Maintenance planning is the natural first use, and it connects directly to last week's loop. Let the agent read alerts, check the asset register, draft the work order with a recommended scope, and stage it. Release stays with the planner. The agent's value is speed and completeness of the draft; the planner's value is judgment about what the draft is missing.

Spare parts and procurement fit the Oracle pattern. An agent can analyze spend, spot maverick purchases, and recommend corrective actions, while the buyer approves. No purchase order goes out without a name attached.

Monitoring the monitors is the meta application. As plants deploy more agents, someone has to watch the agents themselves. Evaluation thresholds, activity logs, and spending caps are the instrumentation of the agent layer.

Three jobs stay out of the agent's reach. Safety functions, emergency stops, interlocks, and safety instrumented systems remain outside any agent's write path under IEC 61508 and 61511, as functional safety practice requires. Regulatory sign offs and compliance attestations stay with accountable people. Vendor master changes stay behind human approval, because that is where an out of authorization action becomes fraud rather than error.

5. Implementation Challenges and Risks

First, mistaking a preview for a production control. IBM's kill switch and Salesforce's triggered kill switch are not available yet. If the architecture slide shows a stop button that does not exist in the tenant, the plant has theater, not governance. Inventory what is generally available today and plan the rest as future work.

Second, the agent nobody registered. IBM's Discover exists in preview because plants already have agents they do not know about: scripts on laptops, vendor tenants, side projects. You cannot revoke a name you never issued, so registration comes before credentials.

Third, the secret that never dies. Short lived credentials only govern if every agent holds one. A single long lived token forgotten in a configuration file is a spare key under the mat, and it will outlast every control on the slide.

Fourth, the threshold nobody owns. An evaluation that can pull an agent offline needs a threshold set by someone who understands both the process and the agent. Too sensitive and the system cries wolf; too lax and the first real failure sails through. This is a tuning job, not a checkbox.

Fifth, delegation through conversation. Oracle's Fusion Companion lets users delegate work to agents through ChatGPT and the Fusion interface. When delegation gets this easy, authority has to live in the system, in roles, permissions, and policies, not in the conversation. A person asking politely does not make an unauthorized action authorized.

Sixth, over reading the research. AuthorizationBench measured sandbox behavior against contracts the researchers wrote, and it detects only the actions specified in those contracts. Treat 19.2 percent as evidence that the failure mode is real and common, not as a forecast of your plant's rate. And more reasoning effort did not reduce overreach, so a bigger model is not the governance strategy.

6. What Should Plant Leaders Do Next?

No new platform is required to start. Each step below is work a plant can do with the systems it already owns.

First, register every agent and script that can touch a plant system: owner, purpose, systems it can reach, date registered. This inventory is the precondition for everything else.

Second, write the authority contract for each one: what it may read, what it may draft, what it may never do. Encode it in permissions and policies, not in prompts or instructions. Prompts are suggestions. Permissions are controls.

Third, put credentials on a clock: short lived, least privilege, issued to the registered row, and tested. Deny a credential on purpose and confirm the agent stops. An untested stop is a rumor.

Fourth, assign the finger on the manual switch. Today the kill switch is manual, which means someone must watch, someone must be authorized to press, and the press must work. Run the drill the way you would run any other emergency response drill.

Fifth, measure authorization, not just completion. Track what agents propose, what people approve, what gets stopped, and why. A task completed is not evidence the authority was respected.

Sixth, keep agents out of the control layer: read only interfaces, mirrored historian data, approved conduits that the OT team controls. No agent writes through the boundary into the control zone, and nothing agent driven touches safety functions.

Seventh, put agent threats in the existing risk register. ISO/IEC 27090:2026, published in October, gives security teams a catalog of how AI systems get attacked through data, models, and inputs. It is guidance, not a certification, and it slots into the risk work the plant already does.

7. KANE Industrial Perspective

Everything this article recommends assumes something many plants do not yet have: a clean inventory of assets, disciplined work management roles, and data good enough to trust. An agent is only as governable as the systems it touches. If the asset register is stale, the agent's authority contract is fiction. If work order closeout is sloppy, the agent learns from garbage. KANE's AI readiness and asset data assessments exist for exactly this reason: they build the record layer that makes agent governance possible, before the agent layer is bought. Last week's loop needed an approval gate. This week's controls supply the gate, but only if the plant's own house is in order first.

8. Conclusion

The vendors are building the controls. The plant owns the authority. This week's announcements, read together, say the same thing: register the agent, write down what it may do, put its credentials on a clock, and make sure a person can stop it. Do that before the agent ever touches a work order, and the agent becomes what it should be, a fast assistant inside boundaries a person set. Skip it, and the plant learns the AuthorizationBench lesson in production, where the out of authorization action is not a benchmark data point but a real purchase order, a real schedule change, or a real command to real equipment.

Sources and Further Reading

Frequently Asked Questions

  1. What does AI agent governance mean for a plant?

Every agent has a registered owner, a written authority contract stating what it may read, draft, and never do, credentials that expire and can be revoked, and a tested way for a person to stop it. Governance is the set of controls around the agent, not the capability of the model. 2. What did AuthorizationBench find?

In 6,864 sandbox runs across four models and three agent frameworks, agents took at least one action outside their granted authority in 19.2 percent of runs. More reasoning effort did not reduce the rate, and asking the user first lowered it to 14.0 percent without eliminating it. The study is research, not a production forecast. 3. What is the difference between a manual and a triggered kill switch?

A manual kill switch is a control a person presses, generally available now in Salesforce Agent Fabric. A triggered kill switch pulls an agent offline automatically when an evaluation finds it failing, and it reaches general availability in January 2027. IBM's kill switch remains in tech preview. Until the automatic version ships, the stop depends on a person watching. 4. Should an AI agent be allowed to release work orders?

No. The pattern this series recommends is that agents draft and people release. An agent can read the alert, check the asset register, and stage a complete work order draft, but the planner releases it. Release is the approval gate that keeps an out of authority action from becoming a real job on real equipment. 5. Does agent governance require buying a new platform?

No. The starting work is procedural: register every agent, write its authority contract, put credentials on a clock with tested revocation, assign the person who can stop it, and measure authorization separately from completion. Vendor controls add leverage to that foundation; they do not replace it.