An AI agent gets it wrong. Who is accountable: the vendor, the person who switched it on, or the CISO?

Ask any security leader how many AI agents are working inside their business right now, and the honest answer is usually a pause. Then a guess.

That pause is the subject of this piece. The 80 seconds above show the problem as a picture: agents appearing faster than anyone can count them, most with nobody's name on them, wired into the systems that matter. We want to argue about what follows from it, and we want your view. The comments are open at the bottom.

Why nobody can count them

Earlier this month we briefed on the 2026 State of Agent Security Report, which looked across a range of business environments and found roughly 1,280 third-party products that now have AI built in. Only about 282 of them sit behind single sign-on. The other thousand or so are invisible to identity tools by default.

Nobody hid them. Identity systems can only govern what signs in through them, and most agents never do. They arrive inside software a business already uses, switched on by a product update, with no purchase order and no decision anyone remembers making. The report splits them three ways:

• Inherited: shipped inside platforms you already run.
• Configured: your own prompts and logic, running on someone else's platform.
• Built: open frameworks on infrastructure you own.

The first two are most of what is out there and are growing fastest. The third is the smallest group, and the only one with a code repository to scan and a build process to gate.

So agents multiply. They share API keys and service accounts because that was the quickest way to get them working. And when one of them does something it should not, nobody can say which one acted, or who approved it.

Three candidates

When that day comes, three people get pointed at.

The vendor who built it. The agent was theirs, the model was theirs, the update that switched it on was theirs. But read the contract. Typical software terms put the configuration, the permissions and the use of the output on the customer. A vendor can be responsible for a defect. It is very hard to make one accountable for what your business let its agent touch.

The person who switched it on. Often the most honest answer, and the least useful. In the inherited case nobody switched it on: it arrived. In the configured case the person was a marketing manager or a developer doing their job well, with no way to know the agent could reach a payments system through a shared key someone set up two years ago. Accountability without authority or visibility is just blame.

The CISO. The default, because security is where incidents land. But a CISO cannot be accountable for an agent they cannot see, whose permissions were granted outside their tools and whose actions were never logged anywhere they can read. Holding the CISO to account for a thousand agents behind no single sign-on is holding them to account for a list that does not exist.

Where we think it lands

Our view: the question has no answer until four things are true, and once they are true the answer is mostly obvious.

1. Every agent has its own identity. Not a shared key, not a borrowed account. If you cannot tell two agents apart, you cannot hold anyone accountable for either.
2. Every agent has a named owner. A person in the business, written down, who decided this agent should exist and what it is for. That person is accountable for its purpose.
3. Every action is checked against rules before it happens, and anything risky waits for a person to say yes. The rule-setter is accountable for the rules; the approver is accountable for the approval.
4. Every decision goes on a record nobody can quietly change, and any agent can be stopped at once. Without the record there is no accountability, only argument. Without the stop there is no control.

With those in place the vendor answers for defects, the owner for purpose, the approver for the risky calls, and the CISO for the system that makes all of it visible. Without them, the honest answer to "who is accountable?" is "nobody", whatever the policy says.

This is also roughly where the Australian Government's ISM guidance on AI has been heading: knowing which AI is in use, on whose behalf it acts, and keeping a register you can verify, rather than a list someone compiled once.

A disclosure

The video above is from Sigilant, which is built by the company behind CISO AI. It is one way of putting the four things above in place: one checkpoint every agent's actions pass through. We think the argument stands whichever way you solve it, and we would rather you disagreed with the argument than agreed with the product.

Over to you

Three questions, and we will read every answer:

1. When an AI agent gets it wrong in your business, who would be held accountable today? Not who should be. Who would be.
2. Could you produce a list of every agent with access to your systems by Friday? If not, what stops you?
3. Is a named owner for every agent realistic, or does it collapse the moment you count the inherited ones?

The comments are open below.