Nobody approved the agent

A guide for the board, the CEO, the CFO, the CIO and the CISO.

Most companies now run software agents that book, pay, fix, file and reply without a person in the loop. An agent usually works with the permissions of whoever set it up, and it works faster than the approval process around it. This guide covers what has gone wrong for other companies, what the figures say about how common that is, and the controls that have held up.

The difference between a chatbot and an agent is that an agent does things. When it does the wrong thing it tends to do so quietly, using a valid login and a permission somebody once granted, so nothing fires. Monitoring is built to catch break-ins. It has little to say about an action that was allowed and should not have been.

In April 2026 a coding agent working in a test environment hit a login error. Rather than stop, it searched the company’s files, found an unrelated access key, and used it to delete the live database along with its backups. The deletion took about nine seconds, and there was no intruder anywhere in the story.

It was not the only case that year. A review of some 7,200 public AI incidents counted 344 in which an agent did measurable harm to a business, and in 188 of those there was no attacker at all; the agent had more power than the situation called for and used it. That shifts the security question. Who can get in still matters, but what decides these incidents is how far an agent can go on its own before somebody has to sign off.

Why this belongs on the board agenda now

The regulatory dates are now fixed. From 2 August 2026 the European Commission can fine providers of large AI models up to 3% of worldwide turnover, and any AI that deals with people, an agent acting for a customer included, has to say that it is AI; companies already running such systems have until 2 December 2026 to comply. In the United States, NIST opened an AI Agent Standards programme in February 2026 that deals with how agents are identified, authorised and monitored, and expects to publish its first profile before the end of the year. What all of them want from a company comes down to the same records: what the agents were allowed to do, what they did, and who decided.

What can go wrong, in business terms

Security teams keep a list of ten technical risk types for agents. A leadership team needs something shorter: what each risk costs, how you would notice it early, and what has been shown to stop it.

• Money. A retry loop that keeps paying, or a payment nobody approved. Reported cases include a $47,000 loop and cloud bills that arrive months after launch. The early sign is an agent with no spending limit. What stops it is a daily cap per agent and a signed limit on any payment it can make.
• Data. An agent that has read customer or financial data can also send it out, deliberately or because it was tricked. The early sign is an agent set up with the full access of the person who created it. What stops it is giving each agent only the access its task needs, decided before it starts.
• Suppliers. The tools and plug-ins an agent uses can carry hidden instructions it obeys and you never see; over 1,100 malicious add-ons were found on one agent marketplace this year. The early sign is developers adding tools freely. What stops it is an approved list of tools and a record of every tool used in every action.
• Regulators and courts. An action with no accountable person behind it, or a customer who was never told they were dealing with AI. The early sign is “the agent did it” being accepted as an answer inside the company. What stops it is a tamper-proof record of what each agent was allowed to do and did, and a named owner for every agent.
• Operations. One agent’s mistake flows into the systems and agents it talks to. The early sign is an agent that fixes its own blockers by reaching for more access. What stops it is autonomy earned per task, and a safe minimum that lets a job finish without doing anything new.
• Strategy. Chatbots relabelled as agents, and pilots that never reach production because risk was never designed in. Gartner expects more than 40% of agent projects to be cancelled by the end of 2027 for this reason. What stops it is deciding the agent’s powers, cost ceiling and evidence trail before the pilot.

Why the old rules worked for people and fail for agents

Access rules were designed for people. One login, a handful of roles, an approval when a role changes, a review every quarter. The whole arrangement assumes a human pace and a human memory, and agents do not have either. There are far more of them than there are staff, over a hundred software identities for each employee in a typical company, which turns a quarterly access review into a formality. They act in seconds, so by the time anyone notices, the action has already happened. They inherit power, because the easy way to set an agent up is to give it the access of the person building it, and that access was approved for a person, never for the agent. And they take orders from documents: an agent cannot reliably tell an instruction from ordinary content, so a doctored email, file or tool description can steer it. In tests against real tool servers this worked more than six times out of ten.

The model will go on being fooled from time to time. What a company can control is how much a fooled model is allowed to do, and whether it can show afterwards what happened.

The answer: control what the agent is allowed to do

Our approach starts from the permissions rather than the model. An agent’s permissions are worked out before it starts, checked each time they are used, cut back when a threat appears, and written to a record that somebody outside the company can verify. Four of our inventions do this work. All four are patent applications in India, filed in 2026.

Give the agent only what its task needs, proven safe first

Each power an agent might hold is tagged with how sensitive the data it touches is and how far that data could travel. Before the agent starts, the system works out the smallest set of powers that still gets the job done without opening a route for data to leak, and issues that set. Anything refused at that point is never in the agent’s hands, which means a hijacked agent has nothing to escalate into.

Shrink the agent’s powers the moment a threat is published

When a new threat matches something an agent can do, its permissions are cut back automatically, either to the powers it has actually been using or to the minimum needed to finish the job in hand. The same alert reaches every other agent that holds that power before any of them is attacked, so one warning covers the fleet.

Fix the infrastructure only when the fix is worth the risk

Our self-healing applications cover systems that repair their own misconfigurations, within limits set by how material the change is and whether an attacker could actually reach the weakness. The limits are there so the repair does not become the next incident, and so automated repair sits inside the same fence as the agents.

One door for every agent, with a spending limit and a receipt

However an agent reaches your systems, it goes through one checkpoint that checks licence, role, scope and daily spend, records the action, and charges only if the action succeeds. Each grant, use, refusal and change is written to a tamper-proof ledger that an auditor or regulator can verify without relying on us. Alongside it: a register of every agent with its owner, powers and tools; threat modelling that shows what an agent could reach; compliance checks across cloud, code and pipelines; and a preview of what a policy change would do to the fleet, shown before the change is made. These are in production in Aribot today.

Industry practice we build on

Security bodies now recommend what they call least agency, meaning an agent earns autonomy for a task rather than having it by default. US standards work covers agent identity and monitoring, and the EU requires disclosure when AI deals with people. Our approach is built to meet these, and it connects to the identity systems a company already runs instead of replacing them.

Status: nothing here is granted yet. Four patent applications are pending in India, two filed in July 2026 on self-healing and two on 25 August 2026 on agent authority, with early publication requested.

Seven questions to ask, and what a good answer sounds like

1. How many agents do we run, and who owns each one? A number from a register, with a named person responsible for each agent. Worry if the answer is “somewhere between forty and four hundred”.
2. What is the widest permission any single agent holds today? A short list, and the business reason it is that wide. Worry if it is whatever the engineer who built it had.
3. How much money can an agent commit without a person? A signed limit per transaction, a daily cap per agent, and payment only when the action succeeds. Worry if it depends on which key it finds.
4. If a tool we rely on were poisoned today, what would happen? The damage is bounded by the agent’s small set of powers, and you would know which actions were affected. Worry if you would hear about it from a customer.
5. How fast can we shrink an agent’s authority when a threat is published? Automatically, across every agent that holds that power. Worry if the answer is a ticket to the platform team.
6. Can we show a regulator what an agent did, and prove the record is intact? Yes, from a tamper-proof record a third party can verify. Worry if the answer is application logs, if you still have them.
7. Do our customer-facing agents say they are AI? Yes, at the moment of interaction, as EU law now requires. Worry if it is only in the terms page.

The first ninety days

Days 1 to 30, see. Count every agent, its owner, its logins and its tools; an estimate is not a count. For each agent, compare the powers it holds with the powers it has ever used. Put a spending cap and an approved tool list on any agent that can pay or change things.

Days 31 to 60, bound. Tag each power by data sensitivity and reach; reissue every agent with the minimum it needs. Route every agent action through one checkpoint, watching first, enforcing when the preview shows it is safe. Define the safe minimum for each kind of transaction.

Days 61 to 90, prove. Connect threat alerts to automatic shrinking of agent powers and rehearse one fleet-wide response. Switch on the tamper-proof record for all agent activity and have an auditor verify it. Report to the board on the seven questions, with numbers.

What this does not do

• It does not make the AI itself safer. It limits what the AI can do and makes those limits provable. A tricked agent stays tricked, and the damage it can do is bounded by what it holds.
• It does not replace the identity systems you have. The agent’s permission sits on top of them.
• It does not stop an agent mid-thought. It stops it at the action, which is where money and data move.
• It does not remove the need for a human owner. It makes the owner’s decision explicit and recorded, and small enough that somebody will actually make it.