AI agents can act: can you still control them?

Chatbots answer questions. Agents issue refunds, cancel orders, and alter customer records. A mistake can therefore reach a live business system before anyone is in a position to stop it.

Suppose a customer writes in to say a parcel never arrived. Software reads the order, checks the carrier's tracking, weighs the customer's history against the claim, judges the complaint honest and sends back €729. No human approves the payment, because the system was built so that none would have to. The money is gone before anyone knows the conversation took place.

Selling the machinery to keep such decisions inside their bounds is now a business. By late 2025 Microsoft had announced a product it called a control plane for AI agents, and Forrester, a research firm, had made the agent control plane a distinct functional plane in its model of enterprise architecture.

Six months later Forrester was publishing a market landscape covering 34 vendors. Fiddler, an observability firm inside the category itself, describes the same stretch less charitably. The phrase went “from a phrase nobody said out loud to one on nearly every vendor's keynote slide”, it says, and “has become a catch-all that every vendor bends toward whatever they already sell”.

Scepticism about the label is warranted, then, and the thing underneath it is still real. Gartner's reference architecture for multi-agent platforms, published in May 2026, treats the category as settled enough to name an agent control plane and an agent runtime authorisation component as distinct components, alongside agent gateways, asset registries, observability and guardrails. Neither analyst firm sells the software. What vendors still disagree about is where in the stack the controls belong.

One ordinary customer-support agent is enough to show why it is at all necessary.

Three versions of the same agent #

The first version only talks. It searches the help centre, summarises tickets and answers questions. Its failures are embarrassing but cheap. A wrong answer costs an apology.

The second version can look. The business connects it to the customer relationship management (CRM) system, the order database, the shipping provider, and the customer's history. Now it investigates rather than guesses. It can see that a parcel has been sitting at a depot for nine days, and it hands that finding to a support employee, who decides what to do and clicks the button.

The third version can act. The reasoning is hard to resist: the agent already understands the problem, and the employee is only approving what it found. So the business removes the click, and the agent gains a refund API, a coupon system, and the power to modify orders and shipments.

Which returns us to the lost parcel. The agent works through the order, the tracking status and the customer's record, decides the complaint is genuine and calls refund_order() for €729.

Nothing about the model changed between version one and version three. What changed is the question the business must answer. In version one the question was whether the model reasons well. In version three the question is what this thing may do, on whose authority, and how anyone would know.

Every component that vendors argue about falls out of that question.

Borrowed authority #

The refund service logs that support-agent-17 made the call. That names a credential. The actor behind it stays hidden. The same agent may be working for a customer in a self-service portal, for a support employee handling a ticket, or unattended, as part of a nightly batch that no person triggers but someone has still authorised. Those three cases should carry different rights. An agent should not inherit a finance director's powers merely because the finance director built the workflow.

This is not only a vendor preoccupation. America's National Institute of Standards and Technology published a concept paper in February 2026 on agent identity and authorisation, seeking comment on “identification, authorization, auditing and non-repudiation of AI agents, as well as controls to prevent and mitigate prompt injection techniques.” It frames the problem as one of identity and authorisation rather than reaching for the language of a control plane, which makes it the more useful corroboration. The requirements arrive at the same place from a different direction.

The plumbing is entering standards work too. An Internet-Draft on AI agent authentication and authorisation, filed in July 2026, applies existing OAuth-style identity machinery to agents rather than inventing new protocols. Its authors come from Amazon Web Services, Okta, Ping Identity, Zscaler and OpenAI. Their affiliations show the approach has drawn contributors from across the identity, cloud and AI industries. It is an individual submission, not an adopted standard, and should be read as evidence of convergence rather than of consensus.

The requirement itself is old. The action must carry a chain: the human who started the task, the agent and its version, the service account it used, and the scope delegated for this run. Long-lived API keys in a configuration file carry none of that.

Where the rules live #

A common early answer is to write the rules into the system prompt: “Never refund more than €1,000 without approval.” That shapes the model's reasoning, and the model is the thing being controlled, so the rule can only ever be as strong as the model's compliance. A prompt injection in a customer's message, a model upgrade, or a badly phrased ticket can talk the agent out of it.

The rule should live outside the model, in something that reads the proposed action and decides:

Paulo Cavallo, in a paper published in April 2026, gives the distinction a useful pair of names. Described governance is what the policy documents say. Established governance is what the architecture actually enforces at runtime.

Frameworks describing what firms should do have multiplied; the tooling that enforces any of it while the agent is running has not kept pace. A refund limit in a system prompt is described governance. The gap between the two is where the money goes.

OWASP, the open security community, began closing that gap in September 2026 with an Agent Control Standard. It specifies how agent platforms should expose middleware hooks so that safety policies become “declarative controls that are portable across agent frameworks and enforced at runtime.” The ambition matters more than the current maturity. An independent body is now trying to standardise the control interface itself, rather than each vendor shipping its own.

Vendors differ on where the hook belongs. Fiddler puts enforcement “at the agent gateway, the one point in the request path that can hold, redact, or block a call.” OpenHands, which builds coding agents, consolidates “LLM routing policies, MCP access, secrets access, budgets, user management and auth” into one platform, covering both the language model and the Model Context Protocol that connects agents to tools.

The insertion points differ. The principle does not: the check happens before the call reaches the production system.

An approval must name the act #

A typical architecture diagram contains the same box. Agent proposes a risky action, arrow to human approval, arrow to execution. The box hides the important question of what, precisely, the human approves.

If the answer is “let the agent continue,” the approval is close to worthless. The agent can carry on reasoning and execute something else. The approval must bind to a concrete, frozen proposal:

Once approved, that intent should be immutable. If the agent later wants €900, it needs a new approval. This is why “human in the loop” is a data-model problem before it is a user-interface problem. The system needs a durable record for each proposed action, which moves through the states proposed, approved, executed or rejected, and which names whoever moved it between them.

The retry that paid twice #

Say the refund executes, but the network drops the response. The agent sees a timeout. It does what any well-built client does. It retries. The customer receives €1,458.

Engineers who have run payment systems will recognise this as a distributed-systems problem, and it is. Idempotency keys, durable execution state, and compensation logic are decades old. What is new is who issues the retry. An agent decides at runtime whether to try again, with what arguments, and it may not know that the first attempt succeeded.

Once an agent can cause side effects, a retry is a business decision, and the control layer must classify actions by their side effects. A genuinely read-only call can usually be retried. A refund must not be.

Reconstructing €63,000 #

Three weeks later the finance director asks why agents issued €63,000 in refunds last week. The API log says POST /refund → 200, 340 times. The finance director already knew that much.

Each refund needs a record of six things: the agent and its version, the person it acted for, the model version, the inputs it saw, the tools it called in order and the policy rule that let it through. And the record must also show whether a human approved the action and what that person was shown, whether the call was retried and what finally happened.

Fiddler's second control problem is “observability (what happened, and whether it was any good).” NIST reaches the same requirement through a legal word, non-repudiation: the record must be good enough that no party can plausibly deny what the agent did on their behalf. The artefact is a trace that links a business outcome back to a decision, a policy and an identity.

Observability reveals that an agent did something wrong. Control stops the action before it happens, and a trace, however rich, does neither on its own. A firm with excellent dashboards and no enforcement point will merely be able to explain its losses very precisely.

The nine meanings of stop #

The refunds look excessive. Someone says: “Stop the agent.” The instruction sounds simple, but technically it has at least nine readings:

1. Stop assigning new tickets.
2. Kill runs in progress.
3. Revoke credentials.
4. Block all tool calls.
5. Block only refunds.
6. Allow reads to the CRM but deny writes.
7. Cancel queued jobs.
8. Halt sub-agents the main agent spawned.
9. Prevent new workflows from starting.

And setting agent.status = stopped in a database does none of these unless something on the request path checks that field before every call.

A kill switch is only as real as its enforcement point. That is the same enforcement point that checks policy, binds approvals and blocks the duplicate refund. Fiddler argues the controls belong at a single point in the request path, since they all interrogate the same call. Others disagree: Forrester treats its planes as functional rather than as strict layers, and the IETF draft assumes identity checks may be spread across several systems.

Britain's National Cyber Security Centre states the test more sharply than any vendor would: “If you cannot understand, monitor or contain an agent's actions, it is not ready for deployment.” Containment is a capability a firm either has before the incident or improvises during it.

The plane appears #

Line up the checks the refund demanded and the shape is clear. An agent proposes an action, and seven questions stand between the proposal and the production system:

• Identity — who is acting, and for whom
• Authorisation — what they may do
• Risk — whether this action is dangerous
• Approval — whether a human must confirm it
• Execution — how it runs, and whether a retry is safe
• Audit — how it is reconstructed later
• Enforcement — how the next one is stopped

Whatever performs those checks, whether concentrated in one component or spread across several, is the control plane.

Forrester's definition is the most careful: “a common enterprise governance and control platform that sits above and across a heterogeneous estate of AI agents and agentic skills,” applying one envelope of oversight regardless of who built each agent. IBM, more plainly, calls it an intermediary that “routes requests, enforces permissions and applies policies before actions are run.” Fiddler compresses it best: “the part of the system that decides, kept separate from the part that moves.” The model reasons. The tools move. The control plane decides whether the movement is permitted.

Governments have converged on the same list without the vocabulary. At the end of April 2026, six cyber-security agencies from America, Britain, Australia, Canada and New Zealand issued their first joint guidance on agentic AI. It sorts the dangers into five categories: privilege, design and configuration, behavioural, structural and accountability.

Those map almost exactly onto the questions the refund raised. Privilege is the identity chain. Behavioural is the retry. Accountability is the audit trail. Agencies with nothing to sell arrived at the architecture by cataloguing what goes wrong.

That framing also explains the vendor noise. An identity vendor sees the “who.” A gateway vendor sees the “may.” An observability vendor sees the “reconstruct.” A workload-automation vendor sees its scheduler with a control plane bolted on. Each describes one face of the layer. Forrester's own caution is the corrective: the architecture is real, but “the standards stack underneath it is incomplete,” and the “connective tissue between the planes” that would let a governance decision in one product propagate reliably into another “remains underdeveloped.”

The message being that a firm buying a control plane today is adopting one vendor's architecture and should expect to revise it as the standards mature.

The same shape, different verbs #

The refund is one instance. Ask a procurement agent to “order 40 laptops for the new Warsaw team” and the same questions return. Its authority has to be bounded before it runs: a spending ceiling, a list of approved vendors, a rule on payment terms, and a rule on what employee data may leave the company.

The two orders differ by one zero. The authority they require differs entirely. Firms already know how to delegate purchasing authority to a human. Delegation to software is the same policy with a stricter enforcement point.

Give a site-reliability agent access to Kubernetes, AWS and the CI pipeline and it will, during an incident, diagnose latency, restart workloads, scale replicas and roll back deployments. Now ask what happens if the diagnosis is wrong, if two agents respond to the same alert, or if a human operator is changing the same system at the same time.

The business verbs differ: refund_customer(), create_purchase_order(), scale_cluster(). The control questions do not.

Not every agent needs one #

The need for a control plane grows with scale, autonomy and side effects. A firm that builds one before it has an agent that can act is buying insurance against a risk it does not yet carry.

The line to watch is the one between reading and writing. The moment an agent's output stops being a suggestion and becomes a call to a production API, the organisation has hired an operator.

You would not give a new employee an unlimited company card, root access to AWS and authority to sign contracts, with nothing more than a note asking them not to misuse any of it. Yet privilege is the first risk category the Five Eyes agencies list, and the pattern they describe is almost exactly that: a handful of API keys and a system prompt listing things not to do.

This is also where the work of production goes. Writing the agent is the smaller task. Most of the effort at Vstorm goes into making sure our agents survive contact with real customers and real infrastructure: guardrails that bound its authority, validation rules that check each proposal and observability that shows what it did and why. The result joins the agent's judgment to the determinism that engineers have relied on for decades. That combination, rather than the agent alone, is what Vstorm delivers to its clients.

Agents can act. The open question is whether the organisation stays in charge when they do. The vendors will keep arguing about where the control plane sits. The refund does not care. It only needs something that can say no before the money moves.

At Vstorm we help clients draw that line: deciding which actions need an enforcement point at all, and designing the control plane around what their agents are actually allowed to do.

Sources #

Independent research and standards

• The Agentic Control Plane Solutions Landscape, Q2 2026 — Forrester, June 24th 2026. Category landscape covering 34 vendors. Subscription required.
• Reference Architecture Brief: Multi-Agent Platform (Outer Architecture) — Steve Deng and Gary Olliffe, Gartner, May 2026. Subscription required.
• Agent Control Standard (ACS) — OWASP Gen AI Security Project, September 2026.
• Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization — NIST, February 2026. Concept paper.
• Careful Adoption of Agentic AI Services — CISA, NSA, ASD ACSC, CCCS, NCSC-NZ and NCSC-UK, April 2026. First joint Five Eyes guidance on agentic AI.
• Thinking carefully before adopting agentic AI — Martin R and Kate S, UK National Cyber Security Centre, May 2026.
• Described vs. Established Governance in Agentic AI — Paulo Cavallo, April 2026.
• AI Agent Authentication and Authorization — Internet-Draft, July 2026. An individual submission, not an adopted IETF standard.

Vendor material, cited as competing implementations

• Microsoft Agent 365: the control plane for AI agents — Microsoft, November 18th 2025. Product announcement.
• The control plane for AI agents: the architecture behind the hype — Fiddler. AI observability.
• The software agent control plane — OpenHands, April 2026. Coding agents.
• What is an agent control plane? — Matthew Finio and Amanda Downie, IBM Think.