AI agent governance: the six controls a regulated firm needs

Agents are worth deploying because they act, and that is also why they need governing. A chatbot’s worst output is a wrong paragraph a person can catch. An agent’s worst output is a completed action: the email sent to the wrong client, the record overwritten, the subscription bought a thousand times. None of this argues against agents (my own business runs on them). It argues for deploying them the way you would onboard a capable new employee: defined duties, limited keys, supervision and a probation period.

Gartner’s widely reported prediction that over 40% of agentic AI projects will be cancelled by the end of 2027, on cost and unclear value, is best read as a control failure forecast: unbounded scope and unmeasured value are governance gaps before they are technology ones.

The six controls for governing an AI agent

Six controls cover almost every way an agent deployment goes wrong, and each is cheap compared with the incident it prevents.

1. Bounded permissions. The agent gets the narrowest tool access that does its one job: read before write, draft before send, its own workflow and nothing adjacent. What it can do and how much damage it can do are both set here, so this is the decision that deserves the meeting.
2. Approval gates at the points of consequence. Anything leaving the firm, changing a client record, or moving money passes a human until autonomy is earned for that specific step, on evidence. Drafts-for-approval is the correct starting posture for every new agent: it proposes, a person disposes.
3. Complete action logs. Every step the agent took, when, with what input and result, inspectable after the fact. This is what turns an incident into a correction rather than a mystery, and it is what a regulator or auditor will ask to see. An action you cannot show in the log is an action you cannot defend.
4. Caps. On spend, on volume, on rate. Agents can fail by succeeding too much: a loop that sends, buys or calls repeatedly. Hard limits enforced outside the agent, so no confused reasoning can exceed them.
5. A tested stop. One switch that halts the agent, known to more than one person, and tested. The middle of an incident is a bad time to find out the off switch doesn’t work.
6. A named owner. One person accountable for what the agent does, its reviews and its evidence, mapped to your existing accountability regime. For regulated firms this lands inside SM&CR, and the wider governance cluster shows the full frame around it.

What UK regulators expect of AI agents

No UK regulator has agent-specific rules yet, and that is the trap: the existing rules apply in full.

• The FCA holds firms to outcomes however produced; “the agent did it” is not a sentence its framework recognises.
• UK GDPR governs the client data agents touch, and restricts solely automated decisions with legal or similarly significant effects: a human must decide, not rubber-stamp.
• Record-keeping obligations extend naturally to agent actions: the log is your suitability evidence chain with a new author in it.

In practice, an agent deployment must be explainable to your regulator in the same sentence structure as a staffing decision. Who does it report to, what may it do alone, how do you know it is behaving, and what happened the last time it was wrong.

Common AI agent failure modes

Each of these failure modes has one of the six controls as its fix:

The agents in my own business run under written bounds, logged actions, spend caps and human gates, with automated security testing every week. If agents are already in your firm, sanctioned or not, the first job is the same one: list them, and check each against the six controls above.