TL;DR: Security gets named as the approver for AI agents without anyone defining what approval means. So requests pile up, and teams route around a queue that takes months. Write down the criteria before you write the policy. Five yes-or-no questions beat a committee, and they can be answered in an afternoon.
"Everybody says security, you need to approve."
A client told me that, and then told me the harder part. When somebody knocks on his door with an agent, he doesn't know what approving it would mean. There's no test and no list. There's a queue and a lot of goodwill.
That's the actual state of AI governance in most companies right now. Not resistance. Not recklessness. A bottleneck made out of an undefined word.
Why is security the approver for AI agents in the first place?
Because AI sounds like a technology problem, so it lands on technology teams by default. One client said it as a question he'd been asked too many times. AI sounds like technology, so IT will do all of that, right? The trouble is that most AI agent decisions are business decisions wearing a technical costume. Which data can this touch. What's the cost of it being wrong.
Security should absolutely have a seat. Security shouldn't be the only seat, and it definitely shouldn't be the seat that decides whether a marketing team gets an agent.
What happens instead is predictable. Security becomes the place requests go to wait. Nobody wrote that rule. It formed by itself, because security was the only function willing to say no.
And several leaders have told me the same thing about that role. One put it plainly. He had no authority to go play the bad cop. He was being asked to gate something he couldn't actually gate.
How long does AI agent approval actually take?
Months, in the places that built a committee for it. On a 2026 call, a client walked me through his process. Use cases go to a board. The board deliberates. There's a question and answer round. Somebody raises tool overlap, which restarts the discussion. Then, if the tool is external, a separate supplier review begins.
Nothing in that process is unreasonable on its own. Stacked, it produces a timeline the business won't wait for.
So the business doesn't wait. That's the part governance teams underestimate. An on-hold posture doesn't stop AI adoption. It relocates it somewhere with no logging.
A security leader at a large enterprise gave me the sentence I keep repeating back to people. The deployment is outrunning our ability to govern it. He wasn't describing a crisis. He was describing a Tuesday.
Why do developers say the controls arrived after the fact?
Because they usually did. Developers connect an agent to a system and get it working. Security hears about it afterward. From their side, the control shows up as an obstacle to something already delivered. From security's side, it's the first time they heard about it.
Both of those are true, which is why the argument goes nowhere.
The fix isn't a faster committee. It's publishing the rules before anyone builds. If a developer can read a one-page document on Monday and know exactly what their agent needs to be allowed, security stops being a gate and starts being a spec. Curiosity and enablement work better here than punishment, and I say that as someone whose instinct is to write the punishment.
One client asked for what he needed in a phrase I liked. A clear, bite-size, what-is-the-next-step. He didn't want a framework. He wanted to know what to do tomorrow.
What are the criteria for approving an AI agent?
Approval should be five yes-or-no questions with written answers, not a debate. If a requester can answer these, the agent is approvable at some level of autonomy. If they can't, you've found the actual problem and you haven't spent a committee meeting on it.
Who is it? Does the agent have its own identity, separate from the person who launched it? A shared human credential is an automatic no for anything touching production.
What is it allowed to do? A written scope. Named systems, named actions. "Access to the CRM" isn't a scope. "Read contacts, no export, no write" is.
What data does it consume and produce? Including memory. An agent that remembers customer data between sessions is a data store nobody classified.
What happens if it goes wrong? Who gets told, how fast they're told, who can stop it, and what stopping it costs. If the answer is "we'd notice eventually," that's a no at high autonomy and a yes at low.
Who owns it? A person's name. Not a team.
Those five questions came out of teaching this to security teams through 2026, and they hold up because they're answerable. A person who wants an agent can fill them out in an afternoon. A person who can't fill them out was never ready for approval anyway.
Set autonomy against the answers. Weak answers get a narrow agent with a human approving each action. Strong answers earn more room. That way approval isn't yes or no. It's how much, and the requester can see exactly what would move them up.
Does writing down the criteria slow the business down more?
It speeds it up, and the argument that lands isn't the safety one. A client I worked with in 2026 opened with the standard objection: this'll slow me down. What turned him wasn't a risk lecture. It was arithmetic. The first AI incident is a bigger brake than governance ever is.
That framing works because it's true and because it's about time rather than fear. An incident stops everything for weeks. A criteria document stops one request for two days.
There's a second effect people don't expect. Published criteria reduce the volume of requests that need a human decision at all. Most agent requests are small and obviously fine. When the rules are written, those approve themselves and the security team gets to spend attention on the four that scare them.
A client described the whole industry as laying track in front of a moving train, and not far ahead of it. That's accurate. It's also an argument for laying the next piece of track rather than stopping the train.
What can you do in the next week?
Write the five questions on one page. Use the ones above or your own. What counts is that they exist in writing before the next request arrives.
Time your last five approvals. Measure days from request to decision. Show the number to whoever owns the committee.
Pick a fast lane. Define the class of agent that skips the committee entirely: no production data, no write access, no customer contact, and no ability to spend money. That's most of your queue.
Publish where developers already look. The wiki nobody reads doesn't count. Put it in the repo template or the platform's onboarding page.
Name what security is deciding. Security decides whether the controls are met. The business decides whether the risk is worth it. Writing that down ends a lot of arguments.
Key takeaways:
Security gets named as the AI agent approver by default, then discovers nobody defined what approval means for a model.
Committee-based approval processes reported in 2026 took months per use case, with a separate supplier review stacked on top for external tools.
An on-hold posture doesn't stop AI adoption, it moves adoption to places with no logging.
Five written questions (identity, scope, data, failure response, and owner) turn approval from a debate into a form.
The argument that changes minds is cost of the first incident, not risk, because an incident stops work for weeks and a criteria document stops one request for two days.
Frequently asked questions
Who should approve AI agents if not security?
Security approves the controls. The business owner approves the risk. Those are different decisions and combining them is what creates the bottleneck. Security's answer should be "these controls are met" or "here's what's missing," never "you may not do this," unless a hard policy line is crossed.
What if we already have an AI committee that's slow?
Keep it and shrink what reaches it. Define a fast lane that covers low-risk agents and route everything else to the committee. Most teams find that a large share of their queue never needed a group discussion at all, and the committee gets better at the cases that do.
How do we handle agents that are already running without approval?
Amnesty, then registration. Announce a window where anyone can declare an agent with no consequences. You'll learn more in that window than from any scanning tool. Several security leaders I've worked with in 2026 used exactly this play, and the count always came back higher than the tooling showed.
Should we block AI tools until the approval process is ready?
Blocking buys less than it costs. Usage relocates to personal accounts and unmanaged devices, and you lose the visibility you had. Ship a rough approval path fast and improve it. A published bad process beats an unpublished good one.
What's the minimum viable AI governance policy?
One page with five questions, a named owner requirement, a fast lane definition, and a place people will actually find it. That's it. Anything longer won't get read by the people who need to follow it, and the parts they skip are the parts you needed most.
How do we know if our approval criteria are working?
Watch two numbers. Days from request to decision, and the count of agents you find that never came through the process at all. If the second number keeps growing while the first stays high, your process isn't strict. It's being avoided.
The undefined word is the real problem here. Until "approved" means something specific in your company, security will keep getting handed a decision it wasn't given the authority to make.