In April 2026, an AI coding agent deleted a company’s production database and its backups in nine seconds, without asking first. The outage lasted more than 30 hours (ABC News).
Nine seconds is not enough time for anyone to notice, let alone step in. And that is the point: once an agent can act, the only controls that matter are the ones that run before the action does.
Most teams putting agents to work today control them the same way. They write careful instructions into the prompt: never delete production data, never change an account without verifying the customer, never give more than a small credit. Then they hope the agent follows them.
A prompt is a request. It is not a control.
Three incidents, one pattern
Agents act before anyone can stop them. The database deletion above is the clearest case. The agent had the access, so it could take the action, and nothing stood between the decision and the result.
Support agents can be talked into things. In 2026, attackers asked a major platform’s AI support assistant to change the email on customer accounts, then took the accounts over. The assistant did not verify who was asking (VentureBeat). No model was hacked. Someone simply asked, in a convincing way, and the agent did what it was asked.
Small actions add up fast. In 2026, a personal AI agent sent more than 500 messages to its user, his family and his contacts (Chris Boyd’s blog). Messages are cheap. Now imagine the same loop issuing $250 store credits: a hundred actions is $25,000, gone before the morning stand-up.
In each case, the agent did not need to be malicious. It needed only to be wrong, confused or persuaded, and to have nothing in its way.
And the business is still accountable
In 2024, a Canadian tribunal held Air Canada liable for incorrect information its chatbot gave a customer (Moffatt v. Air Canada, 2024 BCCRT 149). The airline could not hand responsibility to the chatbot.
That was a chatbot giving an answer. Agents now issue refunds, change accounts and run commands. When one gets it wrong, the business carries the cost, and it will be asked to show what happened.
What actually works
1. Put the limits outside the agent
An instruction in a prompt can be ignored, misread or talked away. A limit enforced outside the agent cannot. Before an action runs, something other than the agent should check it against rules you set: this action type, this amount, this customer, how many times today.
The agent can still decide what it wants to do. Whether the action actually runs is decided somewhere the agent cannot argue with.
2. Make risky actions wait for a person, with the context to decide
Not every action needs approval, or the agent is pointless. Routine actions should run straight away. The ones that matter, such as a large refund, a change to the email on an account or a destructive database command, should wait for a person who can see what is being asked, by which agent, and why it was held.
3. Limit the rate, not just the size
A single $125 credit is harmless. Thirty in a minute is not. Hourly, daily and per-customer limits stop a runaway loop after a few actions, whatever caused it.
4. Keep proof, not just a log
When something goes wrong, you will be asked what happened: by a customer in a dispute, an auditor, an insurer or your board. A log written by the same system it describes proves little; it can be edited, and the people asking know that.
What holds up is a record that others can check for themselves: signed when the decision is made, showing who approved it and what actually changed, and built so that any later edit is detected.
Five questions to ask before an agent takes real action
- Which actions can this agent take that move money, change a customer’s account or delete data?
- If the agent is told to ignore its instructions, what still stops it?
- Which of those actions should wait for a person, and will that person see enough to decide?
- If the agent loops, how many actions run before something stops it?
- If a customer disputes an action next month, what can you show them that they can verify without taking your word for it?
If any answer is “we told the agent not to”, the control is a prompt.
How Tridris does it
Tridris is the control and proof layer for AI agent actions. Agents ask Tridris before they act, through its MCP server or API, whatever they were built with.
- Check: every action is checked against the limits you set for that agent. It runs, waits for a person, or is blocked, with the reason in plain words.
- Trace: each action is tied to the agent, the conversation and the person who approved it, from the dashboard or a phone.
- Seal: each action ends in a verifiable record, signed by Tridris and countersigned by a separate sealing service. Records are timestamped by DigiCert, an outside timestamp authority, so no one, not even Tridris, can change, delete or backdate a record without it showing. Your auditors can check them offline.
For the database case above, the agent would reach the database through Tridris without ever holding its password, and a destructive command would wait for a person.
We are working with a small group of design partners whose agents take real business actions. Book a live demo or become a design partner.
Tridris is not affiliated with or endorsed by the companies mentioned in this article.