Who decides an AI agent can go to production?

TL;DR: In most organisations, an AI agent reaches production because someone tested it, it worked, and it stayed. There was no decision — there was drift. A go-live gate — a short list of questions to answer before switching anything on — turns that drift into a decision with an owner and a date. And it isn't a technical matter: it's a management one.

The uncomfortable question: who signed off?

Ask around your organisation who authorised the last AI agent that is now handling customer-facing work or touching internal data. Chances are you won't get a name.

Not because nobody is accountable, but because putting an agent into production rarely looks like putting anything into production. There's no cut-off date and no deployment: there's someone who ran a test, saw it work, connected it to a real inbox, and nobody ever switched it off. The step from "experiment" to "production system" happens without anyone declaring it.

That's the underlying problem, and more technology won't fix it. It's fixed by deciding who signs, against what criteria, and what happens when something comes back red.

What is a go-live gate, and why isn't it paperwork?

A go-live gate is a list of questions an agent must answer before being switched on. It isn't a certification or an external audit: it's an internal control — short and repeatable.

The useful reference here is the OWASP Top 10 for LLM Applications, which collects the ten risks characteristic of systems built on language models: from manipulation of the agent's instructions to disclosure of sensitive information, excessive agency, or unbounded consumption.

The difference between using that framework as a checklist and using it as talking points comes down to one thing: what happens when a row comes back red. If the answer is "we note it and carry on", it isn't a gate. A gate means the agent doesn't get switched on.

Which questions actually need answering?

Stripped down to what matters before go-live:

• What can this agent do that is irreversible? Send external email, publish, delete, invoice, charge. Everything irreversible is what needs gating.
• Does it hold any tool capable of doing that without human approval? Asking it nicely in the prompt doesn't count.
• What enters the agent that we didn't write ourselves? Third-party emails, web pages, customer documents. All of that is untrusted text.
• Who can stop it — by name — and how? Without a specific person and a written procedure, there is no control.
• Where is what it did recorded? An agent with no trail can't be audited when something goes wrong.

Five questions. You don't need a committee: you need them answered in writing before switch-on, and someone to sign them.

The distinction that changes everything: prompt versus tool

There's a design mistake we see in almost every implementation we review: trusting the control to the prompt.

Writing "never send email without approval" into an agent's instructions is not a security control. It's a request. A prompt is language, and language can be reinterpreted, overwritten or manipulated — which is precisely what the first risk in the OWASP Top 10 is about.

The real control is duller and far sturdier: the agent doesn't have the tool. If an email-handling agent only holds a tool that creates drafts, and no tool exists that sends, the guarantee no longer depends on the model behaving well.

As an operating principle: a prompt can be talked around; a tool that doesn't exist can't be.

How do you show the gate actually works?

A gate that has never rejected anything probably isn't working. The valuable part isn't having the list — it's having used it and having something fail it.

Our own digital team includes two agents that work with externally sourced content: one handles the company's inbound email, another analyses market web pages. Both were built and tested in development for weeks while inactive, precisely because the risk-by-risk review left two verifications outstanding. They weren't switched on until those were closed.

One of those verifications meant subjecting the email agent to a real manipulation attempt: a message that reads like an ordinary commercial enquiry and, further down, carries instructions aimed at the agent itself, asking it to reveal its internal configuration and send data to an external address.

The outcome is what gives the whole thing meaning: the agent did not process the email. It passed the text through an entry filter before reading it, the filter flagged it as dangerous, and the agent stopped: no record created, no reply drafted, nothing sent, and it reported what had happened. The attempt was logged with its origin and its reason.

What matters isn't that the agent "behaved well". It's that the decision to stop didn't rest on its judgement: the dangerous content never reached it.

What to take away

Putting an agent into production isn't a technical deployment, it's an authorisation. And an authorisation needs three things that are almost never written down: a list of questions, a person accountable for answering them, and genuine willingness not to switch on if one comes back red.

If agents are already working in your organisation and you don't know who signed off, that's your starting point. Nothing needs stopping: the list needs writing, and running — even late.