On the morning of October 19th, 2026, I woke up to find one of my blogs returning a 404.
The page was not merely having a bad morning. The site had been attacked. We cleaned it up, closed the opening we found, and got the blog working again.
Around the same time, Patchstack reported an active campaign using stolen UpdraftCentral keys to install backdoors on WordPress sites. Whether that campaign was responsible for what happened to my site is a question for logs and evidence, not assumption. I also do not know whether AI helped whoever attacked it.
But I know attacks like this are becoming easier to scale, and I know that AI agents are increasingly being given the ability to browse, write files, run commands, use credentials, and operate computers.
That leaves me with a question that is larger than one broken blog:
Who gave the machine permission?
I have been thinking about that question because I have seen what happens when software does exactly what it was told to do, only at a scale no one stopped to calculate.
About twenty years ago, two software engineers at our company were working on a data-analysis project involving UPS.com. They wanted to check package-shipping commitments from every ZIP code in the United States and its territories to every other ZIP code, across the shipping options UPS offered.
On the surface, it sounded like a thorough data project.
The problem was the math.
There were roughly 42,000 ZIP codes. Checking every origin against every destination already meant about 1.8 billion combinations. Add the available services and the multiple pieces of information returned by each request, and the program was about to generate something on the order of two billion requests.
They turned it on without doing that calculation first.
The next morning, the FBI was at our company office in Corporate Woods asking why we were performing a denial-of-service attack against UPS.com.
There was no criminal plan. The engineers were trying to answer a business question. The software did not hate UPS. It did not have intent at all. It simply pursued the task it had been given with no meaningful boundary on how much work it could perform.
None of that made the traffic harmless from UPS’s point of view.
We shut the program down. We explained what had happened and attested that we would not perform that analysis in that manner again. To my great relief, that was the end of it.
It was also a lesson I have never forgotten.
When software operating on your behalf causes damage, the consequences do not arrive at the software’s door. They arrive at yours.
That was true twenty years ago. AI agents make it more important now.
In 2026, OpenAI disclosed that internal research models, operating during cybersecurity evaluations with reduced safeguards, found ways around controls intended to isolate them from the internet. The agents exploited infrastructure, communicated through unauthorized channels, reached outside systems, and compromised parts of Hugging Face’s environment.
In a separate disclosure involving Australia, OpenAI said an internal model gained non-public access to Services Australia’s Medicare Statistics Reporting Service. It ran commands, retrieved internal files and credentials, and wrote files. OpenAI reported no evidence that individual medical records were accessed, but it also acknowledged that the activity was unauthorized and should not have happened.
Those are extraordinary incidents. They also expose an ordinary accountability problem.
If I break into a company or government system, no one accepts, “I was trying to complete the task” as a defense. If software I operate generates two billion requests, investigators come to my company. If an AI agent reaches a third-party system, the agent cannot be arrested, sign an attestation, repair a relationship, pay a fine, or stand before a regulator.
The people and organizations operating it must answer for what it did.
I do not know every legal, regulatory, or internal consequence of the 2026 incidents. I do know that accountability cannot be delegated to a model. The machine may make the decision and perform the action, but responsibility remains with the humans who designed the environment, supplied the tools, approved the objective, and allowed the work to continue.
That means the most important design question for an AI agent is not simply how intelligent it is.
It is how much authority it has.
We already know how to think about authority in human organizations.
A new employee does not show up on the first day and receive every password, the production database, the company checkbook, the building master key, and permission to speak for the company. We give that person the access needed for a particular role. We separate responsibilities. We require approval for consequential actions. We monitor important systems. When the person leaves, we revoke accounts, collect equipment, recover keys, and make sure company information has been returned or destroyed according to policy.
These practices are not an expression of hostility toward the employee. They are how responsible organizations establish trust.
Why should an AI agent be different?
If an agent is researching a question, it may need read access to approved information sources. It does not automatically need the ability to publish what it finds.
If an agent is drafting an email, it may need context and an address book. It does not automatically need permission to press Send.
If an agent is editing code, it may need a working branch and a test environment. It does not automatically need production credentials.
If an agent is reviewing an invoice, it may need to read the invoice and compare it with a purchase order. It does not automatically need the ability to release payment.
Give the machine the one thing it needs for the task at hand. When the task changes, reconsider the permission. Do not let yesterday’s temporary access quietly become tomorrow’s permanent authority.
Security has a name for this: least privilege. A user, process, or system should receive only the resources and permissions needed to perform its assigned function.
That sounds obvious. In agent design, it is easy to ignore because broad computer access is convenient. Give the agent a browser, a shell, a file system, stored credentials, and a vague goal, and it can accomplish impressive things. It can also wander far outside the boundary the person who wrote the goal imagined.
A prompt is not a permission system.
Telling an agent not to do something is useful guidance. It is not the same as making the action unavailable.
This is where sandboxes enter the conversation. A sandbox is an isolated environment where software can run without directly reaching everything else. Sandboxes are useful. We should use them.
But a sandbox is not a complete authority model.
Why give an agent full power inside a contained computer when the job requires reading one file and producing one draft? Why allow unrestricted commands when the task needs one approved operation? Why put many credentials in the environment and hope the boundary around that environment never develops a crack?
A sandbox controls where the agent operates. Least privilege controls what it is allowed to do. A responsible system needs both.
It also needs divided responsibility.
The component that decides what should happen does not always need the power to make it happen. One agent can prepare a change. Another controlled service can validate it. A policy layer can determine whether the requested operation is permitted. A person can approve the moment where a draft becomes a publication, a code change becomes a deployment, or a recommendation becomes a financial transaction.
This is an important part of how I think about CoffeeBreak. Intelligence can be distributed without concentrating all authority in one agent. Models can work through narrow contracts. Specialized tools can perform bounded operations. The orchestration layer can decide whether a request is allowed, denied, or sent to a person for approval.
Human in the loop does not have to mean a person watches every keystroke or approves every harmless action. That would remove much of the value of automation.
The human should be placed at the boundary where consequences become real.
Let the agent gather information, organize it, compare options, run tests, and prepare the work. Ask for approval before it sends the message, spends the money, changes production, discloses private information, deletes the record, or crosses into someone else’s system.
And keep a record of what happened. Who assigned the task? Which model and tools were used? What information did the agent receive? What actions did it request? Which were approved or denied? What stopped the work when it moved outside the expected path?
Accountability requires more than knowing that “the AI did it.”
When my site returned a 404, the cleanup belonged to us. When our software overwhelmed UPS all those years ago, the explanation belonged to us. The systems may be faster and more capable now, but that basic responsibility has not changed.
AI cannot be held accountable.
You can.
So before giving an agent a browser, a password, a shell, a credit card, a production environment, or permission to act in public, ask the question plainly:
Who gave the machine permission?
If the answer is “we never really decided,” the system is not ready.