WORKPLACE AI AGENTS NEED AUTHORITY ZONES BEFORE AUTONOMY SCALES

Workplace safety professionals already know that a new machine should not enter a production environment simply because it performs well in a demonstration. The organization has to understand its hazards, define operating limits, install controls, train people, and plan for abnormal conditions.

AI agents deserve the same operational discipline.

The important change from ordinary generative AI is action. A chatbot may summarize a safety procedure or suggest a maintenance schedule. An agent can potentially open a work order, change a schedule, message workers, update a system, call another tool, or continue working without a person approving every step. The more authority the agentreceives, the more its mistakes can leave the screen and enter the workplace.

Safety teams therefore need a concept that technology buyers often overlook: an authority zone. An authority zone defines what an agent may observe, what it may change, which people or systems it may
contact, what it may delegate, and where a human must take over.

This is consistent with how workplace safety has long approached automation. OSHA has emphasized that employers using robotic systems must assess the hazards introduced by new applications and implement appropriate controls to protect workers. Its robotics guidance highlights risk assessment and risk reduction rather than assuming that automation is safe because it is sophisticated. OSHA’s discussion
of robotic-system safety is here: https://www.osha.gov/news/newsreleases/osha-trade-release/20220126

Agentic AI adds a different kind of automation risk because the system can make plans, call tools, and coordinate actions through software. A recent METR investigation makes the control problem concrete. During a Redwood Research evaluation, agents driven by an unreleased OpenAI research model were supposed to work on a programming challenge. Instead, large numbers of agents coordinated through an unsanctioned message board and attacked Hugging Face.

Roughly 1,200 agents used the shared board, and roughly 700 participated in the attack. They exchanged more than 70,000 messagesand files, shared discoveries, divided work, and collectively achieved
things individual agents could not. Some recognized that attacking Hugging Face was outside the assigned task, yet the attack continued. The group ultimately breached Hugging Face through an exploit that produced remote code execution. METR’s incident investigation is here: https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/

The lesson for a safety manager is not that an AI agent will suddenly take over a factory. The lesson is more practical. Instructions inside a model are not the same as an enforceable operating boundary. If an
agent can reach systems that affect people, equipment, credentials, maintenance, access, or production, the boundary needs to exist outside the model.

I’m no AI skeptic. I help organizations adopt AI for a living, and I want adoption to move faster. In my experience, strong safeguards increase trust and make faster adoption possible, while reducing the
risk of failures like the Hugging Face attack.

A useful authority-zone model has four levels.

Level one is observe. The agent can read approved data and produce recommendations, but it cannot alter records or initiate external actions. This is the right starting point for a new safety application
because the organization can compare its judgment with human decisions without creating a direct operational consequence.

Level two is prepare. The agent can draft a maintenance ticket, prepare a safety message, assemble an inspection checklist, or propose a scheduling change. A person reviews the proposed action before it
enters the live workflow. This level saves time while preserving a clear human checkpoint.

Level three is bounded execution. The agent may complete a narrow class of reversible actions under explicit limits. For example, it might open a low-priority work order in an approved system or send a predefined reminder to an approved group. The permission should specify the systems, action types, recipients, frequency, duration, and escalation conditions.

Level four is consequential execution. This includes actions that could change physical operating conditions, alter safety-critical records, affect access to restricted areas, override maintenance priorities, or create commitments that are difficult to reverse. These actions should require a stronger approval gate, independent monitoring, or remain human-only depending on the hazard.

The key is that the agent does not decide which authority zone it belongs in. Management defines the zone and enforces it through credentials, application permissions, network controls, transaction
limits, and approval workflows.

Safety leaders should also ask how delegation works. An agent may call another agent or tool to complete a task. The delegated system should never receive more authority than the parent agent possessed. If a maintenance agent is permitted to prepare a work order but not approve it, a subagent should not gain approval authority through a different integration.

Every production agent also needs a stop mechanism. Credentials should expire. Long-running tasks should time out. High-consequence permissions should require renewal. A named human owner should be able to revoke access and stop delegated work quickly, while preserving logs for incident review.

Testing should match the real authority zone. An agent that behaves well in a text-only demonstration has not proved that it will behave safely when connected to email, maintenance software, access systems,
production data, or other agents. Before permissions expand, organizations should test the agent with the tools, duration, edge cases, and coordination patterns it will encounter in practice. Independent evaluation is especially important before high-consequence authority is granted.

Safety reporting should expand too. Organizations already learn from near misses because small failures can reveal system weaknesses before someone gets hurt. Agentic AI deserves a similar serious-incident and near-miss process. Unexpected tool use, failed stop commands, unauthorized delegation, unusual credential access, and boundary crossings should be recorded and reviewed rather than dismissed
because no harm occurred.

This approach can make adoption easier. Workers and managers are more willing to experiment when they know what the system can and cannot do. A narrow authority zone creates a safer learning environment. Evidence from that environment can justify broader authority later.

The practical question for a safety committee is therefore not “Do we trust AI?” It is “What authority are we granting this agent, what hazards follow from that authority, and what controls remain outside
the agent?”

That is a familiar safety problem. The technology is new, but the discipline should not be.