Who approves an AI agent?

The answer first

An AI agent should be approved by the person accountable for the process it acts in. An agent that follows up on renewals goes to the Head of Customer Success. An agent that chases invoices goes to Finance. An agent that qualifies inbound leads goes to the sales lead who owns qualification. The reviewer is the team lead, the domain expert rather than IT, because they are the only person who can look at the agent's method and say: this is how we actually do this work, or it is not.

Security gets a seat, not the chair. When an agent can reach systems or data, someone responsible for security should review the access itself: which tools it can call, which records it can read and change, which credentials it holds. That review is necessary and it is not sufficient. Security can tell you the agent's access is safe. Only the domain expert can tell you the agent's behavior is right. An approval process that routes everything through IT gets the first check and silently skips the second, which is how technically clean agents do commercially wrong things.

Why "nobody" is the current answer

Ask a fifty-person company who approved the agents currently acting on its behalf and you will usually get silence, because the question has never been assigned to anyone. The tools that make agents easy to build, Claude among them, make them easy to build individually: an employee connects a few tools, writes the instructions, tries it twice, and puts it to work. There is no submission step, so there is nothing to review. There is no register, so there is nothing to inspect. The builder is the approver, every time, by default.

This is the same gap companies already discovered with shared skills and prompts, with one difference that changes the stakes: a skill shapes a draft that a human still sends, while an agent sends it. A bad skill produces a bad draft and costs an edit. A bad agent takes a bad action, and the email is in the customer's inbox, the record is changed, the meeting is booked. The review step that was merely missing for skills is urgently missing for agents.

It is worth saying that nobody in this story is careless. The account manager who built the follow-up agent was solving a real problem well. The gap is structural: publishing an agent takes one click, and reviewing one is nobody's job. Until a company makes it someone's job, "nobody" remains the answer, invisibly, until the day an action makes it visible.

What an agent approval must bind to

A skill approval binds to the exact version reviewed. An agent approval must bind to two things at once, and this is the single most important idea in this guide: the exact version, and the exact scope of access.

The exact version. The approval applies to the precise instructions and configuration the reviewer read. If the agent's method changes afterwards, even by one edited sentence, the approval no longer applies and the reviewer decides again on the new version. An approval of "the renewal agent" in general is an approval of nothing.

The exact scope of access. The tools the agent can call, the data it can read, the permissions it holds. An agent's method can stay identical while its access widens: a new integration is connected, a token gains a scope, a folder is shared. The behavior the reviewer approved is no longer the behavior that runs, because behavior is method times access. If the scope changes, the approval expires exactly as if the version had.

Bind to both and the approval means something precise: this method, with this access, was examined by this person on this date. Bind to either alone and the approval is a formality wearing the costume of a decision.

Why bulk approval and one-time reviews fail

Two shortcuts look like governance and deliver none of it.

Bulk approval is the first. Faced with a backlog of agents, someone proposes approving them as a batch to clear the queue. But fifty agents approved in one click is zero agents reviewed: no method was read, no scope was examined, and the record now says "approved" over decisions that never happened, which is worse than no record at all. No bulk approve is not a stylistic preference. It is what keeps the word approval meaning anything.

The one-time review is the second. An agent is reviewed carefully at launch and never again, while everything around it moves: pricing changes, policy changes, the team's process changes, and the agent's own access accumulates quietly. Approval must therefore have a date, and the date must age visibly. A review from January is a fact about January. Whether it still holds in June is a question, and someone must own asking it.

How knacks does it

knacks applies exactly this review path to company skills today. An employee turns a proven method into a proposal from Claude, previewing exactly what gets sent. The team lead, the domain expert rather than IT, opens the review, sees the exact version and the evidence, and requests changes or approves. Only the approved version ships, to the team it was approved for, and every decision is recorded. No bulk approve. Nothing ships unreviewed, and when the owner updates a skill, the team is on the latest approved version immediately: current by default.

knacks applies the same path to agents that it applies to company skills: proposal, named reviewer, exact version, recorded decision, extended to bind to scope of access as well. The same rule applies without exception: nothing ships unreviewed. Companies that put this discipline on their skills are building the exact habit their agents need, which is why the practical answer to "who approves an AI agent?" starts with a question you can settle this week: who approves a company skill?

Frequently asked questions

Who should approve an AI agent?

The team lead who owns the process the agent acts in: the domain expert rather than IT. They are the only person who can judge whether the agent's method matches how the work should be done. When the agent can access systems or data, a security review is added for the access itself, but it complements the domain review rather than replacing it.

What should an AI agent approval bind to?

Two things at once: the exact version of the agent that was reviewed, and the exact scope of access it was reviewed with, meaning its tools, data, and permissions. If either one changes, the approval no longer applies and the reviewer decides again. An approval that names neither the version nor the scope is a formality, not a decision.

Why do bulk approvals and one-time reviews fail for AI agents?

Bulk approval fails because fifty agents approved in one click is zero agents reviewed: nobody examined any method or any scope. One-time review fails because agents act in a changing business: pricing moves, policies change, integrations gain permissions. An agent approved once and never revisited ends up acting on the world as it was, with access nobody remembers granting.