Let's go back to Harry. He is your golf buddy's son, the receptionist who ended up approving vendor invoices at your property management firm. (New here? Start with Your AI Has More Authority Than You Approved.)
Here's a question we never asked about Harry: Who approved each step? The office manager handed him the company card. Was the office manager the right person to give a receptionist spending authority? Nope. That decision belonged to someone who answers for the money.
Your AI tools have the same problem. Somebody approved each one, but was it the right somebody? The answer depends on two things: how much the AI tool can do without a person approving it first, and whether you can undo the damage if the tool gets it wrong.
Let's dive in!
Who’s Driving? (The Series)
This is the third article in our AI series. In this series, we focus on AI adoption because nearly every organization is rolling out AI right now, and most have no formal way to track how much authority it has. We lay out a straightforward framework to help you decide how much authority your AI gets, spot the risks, and guard against them before something goes sideways.
The More Your AI Can Do Alone, the Higher the Sign-Off Goes
In the first article, we covered the six AI autonomy levels from the Cloud Security Alliance (CSA). At Level 1, a person approves every action the AI takes. At Level 3, the AI acts on its own inside boundaries you set. At Level 5, the AI sets its own goals.
The same CSA framework also says who should approve an AI tool at each level, and how often someone should review that approval:
Table 1: The Sign-Off Table| Level | Name | Approval needed | Who approves | Who reviews, and how often |
|---|---|---|---|---|
| 0 and 1 | None and Assisted | Standard deployment approval | Business owner | Business owner, once a year |
| 2 | Supervised | Documented use case approval | Manager and security | Operations and security, every quarter |
| 3 | Conditional | Formal autonomy request | Autonomy Review Board | Autonomy Review Board, every month |
| 4 | High | Executive approval and signed risk acceptance | CTO or CISO, plus the board of directors | Autonomy Review Board and an executive, every week |
| 5 | Full | Not recommended | Not applicable | Not applicable |
A quick summary of the approval and review requirements in the Cloud Security Alliance's Agentic AI Autonomy Levels and Control Framework, v2.0. CSA’s own recommendation is that most enterprise use cases should default to Level 1 or Level 2, and that governance should be in place before anything goes to Level 3 or higher. I denote this segmentation with the red line.
Let’s define a few terms:
The Autonomy Review Board is CSA's name for a standing group that handles requests to give an AI tool more autonomy.
The business owner is the person who runs the part of the business the AI tool serves.
Operations is the team CSA puts in charge of day-to-day monitoring, escalations, and reporting on AI tools. In CSA’s structure, Operations sits at the same tier as the Autonomy Review Board.
Look at what changes as you move down the table. At Level 1, one business owner can say yes, and the approval gets a second look once a year. At Level 4, the decision goes to your top technology or security executive and your board of directors, and someone reviews it every week. The more an AI tool can do without a person watching, the more senior the approver and the more frequent the review.
Running a 50-person company with no review board? CSA doesn't say how a smaller organization should handle this. My advice is to keep the principle and shrink the structure. Name two or three people (for example, your head of operations, your IT lead, and one executive) who must all agree before any AI tool moves to Level 3.
NOTE: CSA labels this framework "Unofficial AI-assisted Research." It comes from CSA's AI Safety Initiative, not its formal standards process.
Bottom line: When someone asks you to approve an AI tool, first ask what autonomy level the tool will run at. A manager can approve a tool that needs a person's okay for every action. A tool that acts on its own needs a group of senior people to approve it and to keep reviewing it.
What the Tool Can Do Sets the Ceiling
The right approver can still make the wrong call if the AI tool should never run at the requested level in the first place. CSA handles this with a ceiling. The kind of work an AI tool does sets the highest autonomy level CSA recommends for that tool:
Table 2: The Ceiling| What the AI tool can do | Highest recommended level |
|---|---|
| Read, search and analyze information without changing anything | Level 4 (High) |
| Work with local files or pull data from other systems | Level 3 (Conditional) |
| Move money or change data | Level 2 (Supervised) |
| Run code, change system settings or install new tools | Level 1 (Assisted) to Level 2 (Supervised) |
| Take actions that can't be undone or that affect the physical world | Level 1 (Assisted) |
A quick summary of the capability limits in the Cloud Security Alliance's Agentic AI Autonomy Levels and Control Framework, v2.0
CSA treats this ceiling as a hard limit, not a guideline. An organization that wants to go above the ceiling needs an exceptional reason and a senior executive who formally accepts the risk.
What does that look like at your hypothetical property management firm? Let’s look at two AI tools:
An AI tool that reads leases and answers staff questions. Since it only reads information, the ceiling lets that tool run with a lot of independence (up to Level 4).
A more consequential AI tool that pays vendor invoices and moves money around has a lower ceiling (Level 2 at most). This is because the consequences are higher. In a situation like this, with higher impact, you should have someone at your firm approve the payment plan before that tool pays anyone.
Bottom line: Before you decide who approves an AI tool, check what the tool can do. An AI tool that moves money, changes records, or takes actions you can't undo should stay at a low autonomy level, even if the person asking for more is your most senior executive. If you are an executive, you might not want to hear that, LOL.
"We Can Undo It" Isn't Always True
The ceiling above depends on one question: if the AI tool gets it wrong, can you undo it? That sounds simple. But after reviewing real incidents, CSA split that one question into two:
Can you undo the action? CSA calls this action reversibility. For example, you can restore a deleted record from a backup, or change a system setting back to what it was.
Can you undo the harm? CSA calls this consequence reversibility. It asks whether you can repair what happened after the action. CSA's own example is a leaked login credential, such as a password. You can change the password, but you can't un-leak it. Whoever saw it has already seen it.
Pro-Tip
When a vendor or a team member tells you an AI tool's mistakes are easy to reverse, ask one follow-up question: "If this tool gets it wrong, can we actually put things back the way they were?"
Here is how the gap between those two questions shows up at your property management firm. Let’s say that your AI assistant emails a rent increase notice to 400 tenants, and the amount is wrong. You can send a correction in ten minutes, so the action looks easy to undo. But 400 tenants already read the first notice. Some of them called a lawyer. A few posted it online. You can't take any of that back.
CSA's rule is that the harm decides how strict your controls need to be, not the action alone. If you can reverse the action but not the harm, CSA says to treat that action as one you can't undo.
Bottom line: When you judge how risky an AI tool is, don't stop at whether you can reverse the tool's action. Ask whether you can repair the harm the action causes. If you can't repair the harm, treat the action as permanent and keep a person in the approval chain.
What to Do About It
You don't need a new committee by Friday. You need a repeatable way to decide who approves each AI tool. Here are four steps you can take:
Write down the most damaging thing each AI tool can do. Don't list what the tool usually does. List the worst action its access allows, such as sending email to every tenant, paying an invoice, or deleting records.
Ask whether you could repair the harm if that action went wrong. If the honest answer is no, keep that tool at Level 1, where a person approves each action before it happens.
Match the approver to the autonomy level. Use the sign-off table above (Table 1). If a tool runs at Level 3 and the only person who approved it was a team lead, the approval needs to go higher before the tool keeps running.
Put the review on a calendar. An approval with no review date slowly turns into a permanent approval. Set a date, and name the person who owns that review.
Bottom line: For every AI tool, your organization should be able to name the autonomy level the tool runs at, the person or group who approved that level, and the date someone will review the approval next.
In Conclusion
The person who approves an AI tool should match the amount of independence that tool has. A business owner can approve a tool that asks a person before every action. A tool that acts on its own needs senior people to approve it and to review it often. And any AI tool that can cause harm you can't repair should stay at a low autonomy level, with a person approving its actions.
If Harry's spending authority had gone to the right approver, someone would have asked, "What's the worst thing he can do with that card, and can we get the money back?" Ask the same question about every AI tool you run.
If your organization is rolling out AI and nobody can say who approved each tool or when that approval gets reviewed, that's exactly the conversation I have with leadership teams. Contact us; we can help!
To infinity and beyond! Oh… don’t text and fly, so share this article before take-off. #safetravels
