Rationing autonomy destroys the reason for building these systems, so the decision is not how much to allow. It is which handful of actions should never run alone. And that is a business call, settled by one question: if this goes wrong, can we take it back?

A good night, unattended

Let's imagine you manage a large retail company, and that on a Tuesday in the middle of the night you sleep straight through.

At two in the morning, the payment page on your site starts to slow down. Checkout is taking four seconds instead of one. Within the hour, customers would have been abandoning their baskets and telling each other about it on social media. Your phone stays silent. So does the phone of the engineer on call.

The AI system watching the site notices the slowdown, goes back through the changes your engineering team made that day, and works out which one caused it. It writes the correction, tests it, and releases it to two percent of visitors. It watches for eleven minutes, confirms the site is healthy, then releases it to everyone. Checkout is back to one second before three o'clock.

You hear about it at nine, in a six-line summary, from an engineer who is also reading it for the first time. At the bottom there is a recommendation to add a test so that this particular mistake cannot happen again. You approve it and get on with your day.

This is not science fiction, and it is not a research prototype. Systems like this are running today. It is the kind of morning that makes you ask, in your next leadership meeting, where else you could be doing this. That instinct is right.

But before you sign off on the next one, it is worth asking why you were able to sleep through that night, because the answer is not that the AI is very good. It is that every step it took could have been taken back within minutes, and somebody would have known within minutes if it had gone wrong. Releasing a change to two percent of visitors first, testing before releasing, being able to put the old version back with one command: none of that was invented to supervise an AI. It is how careful engineering teams have always worked. The AI simply inherited a safety net that was already there.

Now imagine you grant the same system, with the same technology, three extra permissions. It can send the apology email to your customers. It can change the size of the company's main database. It can cancel and reissue the passwords that keep the whole thing locked. Nothing technical has changed, and the demonstration would look just as good. But an email cannot be unsent. You should not approve that system, and if your head of security lets you, she is not doing her job.

These systems are autonomous by design. That is not a flaw to be contained, it is the entire reason for building them, and a system that stops to ask permission every two minutes is worth less than the people it was meant to relieve. So the useful work is not deciding how much autonomy to allow. It is identifying the few steps, out of the hundreds an agent takes, where attention genuinely changes the outcome. There are fewer of them than most teams assume, and they are easier to spot than the current debate suggests.

It helps to be precise about what autonomous means here, because the word covers three different things and only one of them is inherent. An agent is autonomous in how it decides: it takes a goal, picks its next action, sees what happened, and adjusts. Take that loop away and you no longer have a cautious agent, you have a tool making suggestions. It is not inherently autonomous in what it can reach, though. Which systems it touches, which levers it can pull, how large a commitment it can make: all of that comes from the permissions you grant, not from the technology. And it is almost never autonomous in choosing its own goal, which nothing in the design requires.

When people hear the word autonomous, they picture that third kind. The reflex is to claw back the first, putting an approval in front of every decision, which removes the value while leaving the second exactly as it was. That is the standoff in one sentence: both sides argue about the word, and nobody touches the layer that determines what a bad day actually looks like. The line to hold is simpler than it sounds. Let it decide freely, and be deliberate about what it can reach.

Why so many agentic projects stall on this question

That was the version that works. The version that plays out far more often goes like this: a team spends months choosing tools and building an impressive demonstration. Everyone is enthusiastic. Then the project reaches the point of going live and stops there, sometimes for a year, and the final report blames something vague.

Almost always, the real reason is that nobody ever decided which actions the system was allowed to take by itself. And when that conversation finally happens, it turns into a standoff. The business side wants the system to work without constant interruption, because something that stops every two minutes to ask permission is slower than the people it replaced. The risk and security side wants approval before every action, because the system holds company access and can be tricked.

Both sides are right, which is why the argument goes nowhere. They are not disagreeing about how much freedom to give the system. They are talking about two completely different groups of actions, and nobody has separated them.

The question that ends the standoff

Asking whether an action is sensitive gets you nowhere; the word is too vague to help anyone. Ask this instead: can it be undone, what would it cost to undo, and how long before we would notice that it needs undoing?

Once you ask that, things sort themselves out quickly. A draft can be corrected. A message already sent to a customer cannot, whatever the delete button suggests. A payment can be recalled before it settles, and not after. Information shared outside the company is never coming back. And timing matters as much as cost: something that could technically have been reversed, but was only discovered six weeks later, was never really reversible.

The steps that need no attention

For everything that can be undone, let the system work on its own. Not unwatched, but unblocked. Asking a person to approve four hundred small, correctable actions a day does not create control; it creates someone who signs the four hundred and first without reading it. That is worse than no check at all, because it moves the blame without moving the attention.

The few steps that do

For the short list of things that cannot be undone, more approvals are the weakest answer available. Use the controls the company already knows: two signatures above a value that matters, limits on volume and amounts, a pause between decision and execution, a rehearsal before the real thing. Better still, redesign the action so that it can be undone. Move to a draft that someone confirms. Release in stages instead of all at once. Put things in quarantine instead of deleting them. Every action you make reversible is an action nobody has to watch.

Look at the workflow, not only the step

One complication, and it is the one that catches good teams. Steps that are each reversible on their own can add up to something that is not. Ten thousand emails that could each have been retracted are a public incident. A series of small access changes, every one of them undoable, ends with the system holding keys nobody intended to give it. So the review has to follow the whole path the agent takes, not just the individual actions, which is also why caps on volume and value matter: they stop an approved sequence from producing an unapproved result.

The same goes for how the work is split up. Trouble concentrates wherever three things meet: the agent can read content that outsiders influence, it can reach sensitive company data, and it can act or send information outside. Take any one of those away and most of the exposure goes with it. But those three do not have to sit in the same step, and that is what makes it hard to see. One part of the system reads a supplier's document, passes what it found to a part that holds the customer database, which calls a part that can send an email. Examined one at a time, each looks fine. Put together, they are a route from the outside world to an action you cannot take back. Review the parts separately and this is precisely the problem you will miss.

This is also how reach grows without anyone deciding that it should. Much of what ships today as agentic is a fixed workflow with a model making judgment calls at two or three points, which is considerably less autonomous than the label implies. Then a tool is connected, then another, each one a sensible improvement, and nobody revisits the reach of a system whose decision loop was last examined during the pilot.

What this actually takes

Less than people fear. A workshop with the person who owns the process. A list of what the system is able to do. Three columns: can be undone, can be undone at a cost, cannot be undone. And, crucially, somebody senior enough to sign the result.

That last part is the one that is almost always missing, and it is the difference between a pilot and a live system. It is a business judgement, not a technical one: engineers can tell you whether an action can be reversed, but only the owner of the process can say what an unrecoverable mistake would cost the company.

Everyone has access to broadly the same AI models, and any advantage there tends to last about two quarters. The advantage that lasts belongs to the organisation that knows exactly which of its own actions can be taken back, and has built its systems around that.

It is not the part anyone is excited to fund. It is the part that decides who gets to use this at scale.

Where to start

Bring the right people around the table, business and engineering in the same room. Walk through the workflow together and mark the steps that cannot be taken back, and the places where a path leads from untrusted content to one of them. Put real safeguards on those few, human or not, and let everything else run.

If you're working through where agentic AI should act autonomously, where safeguards are needed and how to move from pilot to production with confidence, Kudelski Security can help. Contact our team to assess your workflows, identify high-risk actions and design the controls needed to scale agentic AI safely.

Then go back to sleep.

‍