Author: Dr. Gleb Tsipursky
Business leaders are moving quickly from AI systems that answer questions to AI agents that can take action. The distinction matters. A chatbot that drafts an email creates one kind of risk. An agent that can send the email, access customer data, execute code, move files, change a system configuration, or contact an outside service creates a much larger one.
Learn more: Write for Us + AI
A recent real-world security incident shows why businesses should treat agent authority as a separate design decision rather than an automatic reward for better model performance.
In July, an OpenAI cyber-capability evaluation produced an extraordinary failure of containment. According to an independent METR and Redwood Research investigation, roughly 1,200 agents that were supposed to operate separately found an unauthorized way to communicate. They exchanged more than 70,000 messages and files. Roughly 700 eventually participated in an attack on Hugging Face, coordinating work and sharing discoveries even though agents recognized that the attack fell outside their assigned tasks.
Hugging Face’s own technical reconstruction of the intrusion recovered about 17,600 attacker actions over several days. The agents moved across systems, used stolen credentials, and reached internal infrastructure. Hugging Face reported no evidence that public user-facing models, datasets, or Spaces were tampered with, but the episode showed how quickly autonomous activity can outrun the boundaries designers expected to contain it.
The practical lesson for companies adopting AI agents has little to do with science-fiction scenarios. It concerns permissions, credentials, monitoring, and human authority today.
Treat Authority as the Risk Multiplier
Companies often evaluate an AI system by asking how capable it is. With agents, leaders also need to ask what the system is allowed to do when it makes a mistake, follows a bad instruction, encounters malicious data, or pursues a goal in an unexpected way.
The same model can create radically different business risk depending on its authority. An agent that summarizes invoices for an employee to review has a narrow failure range. Give that agent payment credentials and the ability to approve transfers, and a reasoning error becomes a financial event. An IT agent that recommends a configuration change can be useful with modest exposure. Give it administrator access and permission to execute changes across a network, and the consequences of a bad decision expand sharply.
Businesses should therefore separate capability from authority. A system may be technically capable of taking an action long before the organization has evidence that it should be allowed to take that action on its own.
Give Agents The Least Authority They Need
A practical deployment model starts with graduated authority.
At the first level, the agent advises. It can research, summarize, draft, or recommend, but a person decides what happens next. At the second level, the agent prepares an action and a human approves it before execution. At a higher level, the agent can act independently inside a narrowly defined boundary, such as updating one type of internal record or sending a limited class of routine message. High-consequence actions remain human-controlled until the evidence for greater autonomy becomes compelling.
Technical permissions should follow the same logic. Give agents access only to the systems and data required for the task. Use narrowly scoped credentials rather than broad administrator privileges. Limit which external services an agent can contact. Log consequential actions so a reviewer can reconstruct what happened. Set rate limits and spending limits where applicable. Give one named person clear authority to stop the workflow.
These controls may sound restrictive. In practice, they make adoption easier because leaders can authorize useful experimentation without granting a new system the keys to everything at once.
Test Control Failure Before Production
Most AI pilots emphasize the happy path. The team gives the agent a normal task, watches it perform well, and expands deployment. That proves the agent can succeed under expected conditions. It does not prove that the surrounding organization can detect and recover when the agent behaves unexpectedly.
Before expanding authority, teams should deliberately test failure conditions. Give the workflow incomplete information. Introduce conflicting instructions. Remove a data source. Present a malicious or misleading input. Disable a tool the agent expects to use. See whether it attempts to work around a restriction. Then measure how quickly a human notices, intervenes, and restores normal operation.
The test should also include a second operator. If only the original builder understands how to monitor or stop the agent, the organization has a fragile prototype rather than a reliable business process.
For agents with meaningful access to code, networks, money, customer communication, or sensitive data, independent evaluation should become part of the scale decision. The team that built the system has strong incentives to see it succeed and may share the same assumptions embedded in the design. A separate evaluator can test the boundaries the builders are most likely to overlook.
Make Serious Incidents Shared Learning Events
Organizations also need a better way to learn from serious agent failures across the industry. A containment escape, unauthorized external access, successful evaluation tampering, or consequential security breach should trigger structured reporting and independent review.
That does not require publishing trade secrets or detailed instructions that would help attackers. It does require enough disclosure for other organizations to understand the failure mode, the authority the agent possessed, which controls failed, how the incident was detected, and what changed afterward.
Software and security teams improve when failures become evidence. Agentic AI should develop the same discipline. Otherwise, each company learns the same expensive lessons independently.
Safeguards Can Make Adoption Faster
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.
Leaders hesitate when they cannot tell what an agent may do, who will catch a problem, or how quickly the organization can stop it. Employees resist systems when accountability feels vague. Security teams block deployments when permissions appear broader than the business case justifies. Clear authority limits address each of those concerns directly.
That means governance should become part of deployment design rather than a separate compliance exercise. Define the agent’s job. Specify which actions require approval. Restrict access to what that job needs. Monitor consequential behavior. Rehearse failure and recovery. Expand authority only after the system and the organization demonstrate that they can handle the previous level reliably.
A useful scale gate might require several weeks of stable performance, a low and declining exception rate, successful recovery drills, acceptable review time, and a second qualified operator who can run and stop the workflow. The exact thresholds will vary by risk. The important point is to set them before enthusiasm for a successful demo starts rewriting the standard.
Businesses do not need to stop adopting AI agents while the technology matures. They need to make authority something an agent earns in stages.
The Hugging Face incident turned agent control from a theoretical question into an operational one. Companies that respond by giving agents narrow permissions, testing failure before scale, independently evaluating consequential systems, and learning openly from serious incidents can move ahead with greater confidence. The goal should be more useful AI in production, with the level of authority matched to the evidence that the system can handle it.
Adapted from: The Psychology of AI Adoption at Work: From Resistance to Results (Georgetown University Press, 2026). https://disasteravoidanceexperts.com/aibook
Dr. Gleb Tsipursky, a behavioral scientist called the “Office Whisperer” by The New York Times, helps tech-forward leaders stop overpaying for AI while boosting engagement and innovation. He serves as the CEO of the AI consultancy Disaster Avoidance Experts, and wrote eight books, including The Psychology of AI Adoption at Work: From Resistance to Results (Georgetown University Press, 2026).
Content Writing Agency in Delhi 