Posted on

Your AI agents are already in production. Who is accountable for them?

Twelve months ago, most conversations we had about artificial intelligence were about assistance: summarise this, draft that, answer a question. Those conversations have changed. Increasingly, organisations are not deploying models that advise people, they are deploying agents that act – raising tickets, moving data between systems, reconciling records, calling APIs, and occasionally spending money.

That is a different risk conversation, and in most organisations it has not caught up with the deployment.

The gap between adoption and control

A survey of 750 senior technology leaders in the UK and the US, published in April 2026, put some uncomfortable numbers against a pattern we see repeatedly in client environments. Agent estates had roughly doubled in four months. Almost 38% of the organisations surveyed were running more than a hundred agents. And around 90% reported having agents running in production that nobody was monitoring.

The governance findings were starker still: 85% had no formal accountability for the behaviour of their AI agents, and only around 7% could name an individual who was responsible. Just over half had experienced or suspected a security incident involving agents in the preceding twelve months.

Read those together and the picture is familiar to anyone who lived through early cloud adoption, or before that, early virtualisation. Capability arrives faster than the operating model around it. Teams do sensible things individually. Nobody has the whole picture. The controls arrive after the estate, not before it.

Why agents break the assumptions in your existing controls

Most security and governance frameworks in use today assume a fairly stable set of actors: employees, contractors, service accounts, and applications whose behaviour is defined at build time. Agents fit none of those categories cleanly. They hold credentials, but they are not people. They make decisions at runtime, but they are not deterministic software. They can be redirected by their own inputs.

The OWASP Top 10 for Agentic Applications, released in 2026, is a useful vocabulary for this. Several of its categories describe failure modes that have no real analogue in a conventional application:

  • Identity and privilege abuse – agents inheriting human or cached credentials, and then operating with far broader entitlements than the task required.
  • Tool misuse and exploitation – an agent using a legitimate, sanctioned integration in an unsafe way, because the instruction it received was ambiguous or deliberately manipulated.
  • Agentic supply chain vulnerabilities – tools, plugins and models being loaded dynamically at runtime, which means your software bill of materials is no longer a fixed thing you can review at release.
  • Memory and context injection – poisoning the data an agent retrieves or remembers, so that the manipulation persists across sessions rather than being confined to a single prompt.

None of these are exotic. They are the predictable consequence of giving software judgement and access at the same time.

What we would do first

Our advice to clients is deliberately unglamorous, because the organisations that get this wrong are rarely undone by a sophisticated attack. They are undone by not knowing what they had running.

  1. Build the inventory before you build the policy. You cannot govern an estate you cannot enumerate. Every agent, what it does, what it can reach, who commissioned it, and what happens if it stops. Expect to find things nobody told you about – that is the point of doing it.
  2. Give every agent its own identity. Agents borrowing a human’s credentials, or sharing a generic service account, destroy your ability to attribute an action afterwards. Distinct, scoped, revocable identities are the single highest-value control here.
  3. Scope the tools, not just the data. Least privilege for an agent is a statement about capability as much as access. An agent that can read a finance system is a different proposition to one that can post to it.
  4. Put a human in front of anything irreversible. Payments, deletions, external communications, changes to production configuration. Autonomy is a spectrum, and it is entirely reasonable to sit at different points on it for different actions.
  5. Name an owner. Not a committee. For each agent, or each family of agents, one accountable individual who signs off what it is allowed to do and reviews what it actually did.

The point is not to slow down

It would be easy to read the figures above as an argument for caution, and that is not the argument we are making. The organisations getting genuine value from agents are the ones that moved early. But they are also, in our experience, the ones that treated agent governance as a design problem at the start rather than a remediation problem at the end – and the cost difference between those two positions is considerable.

If you are somewhere in the middle of this – agents in production, governance still catching up – the useful first step is usually an honest inventory and a short, blunt assessment of where the accountability actually sits. APHS works with clients across ICT strategy, information and data governance and security, and this sits squarely at the intersection of all three. Get in touch if that is a conversation worth having.

Sources