Should an AI agent ask before it acts?

Sometimes. The useful question isn’t whether an agent should ask permission, but which actions it should ask about, who it should ask, and what that person needs to see before they say yes.

Get that wrong in one direction and the agent is slow, annoying and quietly bypassed by staff who are tired of clicking “approve”. Get it wrong in the other and the agent does something on your behalf that you would never have agreed to, and you find out from a customer.

A small, very public example of the second problem played out in the last fortnight.

What happened with Meta’s Muse

In late September, a Toronto tech reviewer let Meta’s new Muse agent manage his Facebook Marketplace messages. According to the Guardian’s report, republished by inkl, he had given the agent his address as the pickup location for the listing, and when it offered him “Allow One Time” or “Allow Always”, he chose “Allow Always”. He believed that still meant he would approve individual offers. The agent read it as permission to answer every message using the information he had given it.

The result: the agent negotiated with a buyer, shared his home address and arranged a pickup without his knowledge. When asked about it afterwards, the agent itself replied, in part: “I never asked for consent.”

Meta’s response, as reported by Gadget Review, was that there had been no breach of privacy controls, that in similar cases Muse had followed instructions and asked for permission correctly, and that it would make its permission prompts clearer.

Both things can be true at once. The agent may have done exactly what its permission settings allowed. And the person still ended up with a stranger heading to his building, because the permission he thought he was giving and the permission he actually gave were not the same thing.

That gap is the subject of this article.

Why this matters more for a business than for a phone

A person using an agent on their own phone is risking their own information. A business deploying an agent is acting on behalf of its customers, its staff and its reputation. When a business agent shares something it shouldn’t, promises something it can’t deliver or commits the business to something nobody signed off, it’s the business that wears it.

The Muse case also shows a pattern that applies directly to business agents:

• The agent had information it was allowed to use (the pickup address).
• It had a broad permission (“Allow Always”).
• It had no rule separating routine replies from consequential ones. Answering “is this still available?” and sending someone your address were treated as the same kind of action.

Most business agents will face the same three conditions. An AI receptionist has access to your calendar and your service list. A sales agent has access to your CRM. A service agent can see orders and accounts. Each of them will, sooner or later, hit a request where the right answer is “I need to check with someone first”. Whether it does depends entirely on how the approvals were designed.

What the guidance says

You don’t need to invent this from scratch. Several public frameworks now say much the same thing.

The Guidance for AI Adoption, published on the Australian Government’s ai.gov.au site, lists six essential practices. The sixth is “Maintain human control”. It says oversight should be meaningful and should match how much autonomy the system has and how high the stakes are, and it asks organisations to “build in human override points” so people can pause, override, roll back or shut down an AI system if needed.

The joint guidance Careful adoption of agentic AI services, from the Australian Signals Directorate’s Australian Cyber Security Centre and its international counterparts, is more specific. It recommends that organisations “prevent agents from autonomously executing high impact actions or outputs without prior human approval”, and that they classify agent actions “by potential impact, likelihood and reversibility” and apply safeguards to match.

The OWASP project, which publishes widely used security checklists, lists “excessive agency” among the main risks for AI applications in its Top 10 for LLM applications. It traces the problem to three causes (excessive functionality, excessive permissions and excessive autonomy) and recommends human-in-the-loop control “to require a human to approve high-impact actions before they are taken”.

None of these says every action needs approval. They all say the same thing in different words: sort actions by consequence, and put a person in front of the ones that matter.

A simple way to sort actions

For a small or medium business, three questions do most of the work.

Can it be undone?

Creating a draft, adding a note to a CRM record or putting a tentative hold on a calendar slot can all be reversed in seconds. Sending an email to a customer, issuing a refund or deleting a record can’t, or not cleanly.

Reversible actions are good candidates to run on their own. Irreversible ones deserve a second look.

Who does it affect?

An action that only changes your internal records is lower risk than one that reaches a customer, a supplier or the public. Once a message has left the building, you can follow it up, but you can’t unsend it.

Does it commit the business?

Money, prices, terms, promises about timing, and anything that shares personal information with a third party all commit the business to something. These are the actions where you want a named person to have said yes.

If the answer to all three is reassuring (reversible, internal, no commitment), let the agent act. If any one of them isn’t, that’s where an approval step belongs.

Where approval usually belongs

Applied to typical SME agents, that sorting tends to look something like this. Your list will differ, but the shape is usually similar.

Usually fine to run on its own

• Answering common questions from your own published information.
• Logging a call, an email or an enquiry against the right record.
• Creating a task or a support ticket.
• Booking an appointment into an available slot under rules you’ve set.
• Sending a standard confirmation or reminder for something the customer asked for.
• Taking a message and passing it to the right person.

Usually needs a person’s approval first

• Refunds, credits, discounts or anything else that moves money.
• Quotes or prices outside your standard list.
• Changes to contract terms, cancellation conditions or payment arrangements.
• Messages to large groups of customers at once.
• Sharing personal information (an address, a phone number, account details) with anyone other than the person it belongs to.
• Deleting or merging records.
• Giving anyone access to a system or a document.

Usually shouldn’t be done by the agent at all

• Handling complaints, disputes or distressed callers beyond acknowledging them and handing over.
• Making exceptions to policy.
• Anything a regulator, insurer or court might later ask a person to explain.

The middle list is where design matters. The agent can still do the groundwork: draft the refund, prepare the quote, write the message. It just doesn’t send or commit until a person has looked at it.

Designing approvals people will actually read

An approval step only protects you if the approver is paying attention. That’s harder than it sounds.

Keep the list short

If an agent asks for approval forty times a day, people stop reading and start clicking. The point of sorting actions is to make the approval list short enough that each request gets real attention. If approvals pile up, the answer is usually to move more low-risk actions into the “run on its own” group, not to approve faster.

Show the person what they’re approving

“Approve action?” is not a useful prompt. A good approval request shows exactly what will happen: the message text, the amount, the recipient, the record affected, and why the agent thinks it’s the right step. If the approver has to open three systems to understand the request, they won’t.

Make “Allow Always” mean something specific

The Muse case turned on a broad permission that the person and the agent understood differently. In a business setting, standing permissions should be narrow and written down: “may confirm bookings for existing customers”, not “may handle bookings”. If you grant a standing permission, be clear about what it does and doesn’t cover, and review it after a few weeks of real use.

Decide who approves, and what happens when they don’t

Every approval needs an owner, and a fallback for when that owner is busy, on leave or asleep. Decide what the agent does while it waits. For most actions the right answer is to tell the customer someone will confirm shortly, then hold. An agent that times out and proceeds anyway hasn’t really asked.

Put the control in the system, not just the instructions

Telling an agent “always ask before sharing an address” is a sensible instruction, but it’s still only an instruction. Where you can, back it with a control the agent can’t talk its way past: an integration that only allows refunds to be drafted, not issued; a messaging connection that holds outbound messages to new recipients for review. We cover the access side of this in is business data safe with AI agents?

Keep a record

Log what the agent proposed, who approved or rejected it, and when. That record is how you’ll spot an approval step that’s become a rubber stamp, and how you’ll answer a customer who asks what happened.

Speed versus control

The honest trade-off is that approvals slow things down. A customer who asks for a refund at 9pm and gets “someone will confirm in the morning” has had a slower experience than one who got the refund instantly.

That cost is real, and it’s worth weighing rather than ignoring. A few ways businesses manage it:

• Approve the category, not each instance. For example, the agent may issue refunds under a set amount for a specific, documented reason, and anything outside that goes to a person.
• Separate the reply from the action. The agent can respond to the customer immediately, acknowledge the request and set an expectation, even if the action itself waits for approval.
• Start strict and loosen with evidence. Begin with approval on anything uncertain. After a few weeks, look at what was approved without changes, and consider moving those actions to the “run on its own” group.

That last approach is the same one the ACSC guidance recommends: deploy incrementally, starting with clearly defined low-risk tasks, and widen what the agent can do as you gain confidence.

The Australian privacy angle

There’s an additional reason to think carefully about approvals now. At the time of writing (October 2026), amendments to the Privacy Act will require many organisations to explain in their privacy policies when computer programs make, or substantially help make, decisions that could significantly affect individuals. The Office of the Australian Information Commissioner published guidance on these obligations on 30 September 2026, and they apply from 10 December 2026.

The OAIC’s material distinguishes between decisions made solely by a computer program and decisions where a program does something substantially and directly related to making them, so where a person sits in the process matters. If your agent makes decisions that affect customers, such as approving or declining a request, now is a good time to write down which ones a person reviews and which ones run automatically. We’ll cover the new obligations in more detail in a later article.

This is general information, not legal advice. Whether and how these obligations apply depends on your business and how your systems work, so get advice specific to your circumstances.

Common questions

Doesn’t requiring approval defeat the point of an agent?

Not if the approvals are in the right place. Most of an agent’s value comes from the high-volume, low-risk work: answering, logging, booking, routing. Approval on a short list of consequential actions takes a small amount of time and removes the outcomes you’d least want.

Can’t we just tell the agent to be careful?

You can, and you should. But instructions are interpreted, and the Muse case shows how a reasonable-sounding permission can be read more broadly than intended. For actions that matter, back the instruction with a control in the system.

Who should be the approver?

Whoever would make that decision if the agent didn’t exist. Refunds go to whoever approves refunds now. Pricing exceptions go to whoever sets prices. An agent shouldn’t create a new approval path that nobody owns.

How do we know if we’ve got the balance right?

Look at the approval log after a few weeks. If almost everything is approved unchanged, some actions can probably run on their own. If approvers often edit or reject requests, those actions belong in the approval group and the agent’s rules may need work. If approvals are sitting unanswered, the process needs an owner.

What about an AI receptionist?

The same logic applies. Answering questions, taking messages and booking into open slots usually run on their own. Quoting non-standard prices, promising callback times you can’t guarantee, or sharing anyone’s details with a caller should go to a person. Our article on AI voice for Australian businesses covers when a call should be handed over.

The short version

An AI agent should ask before it acts when the action can’t easily be undone, reaches someone outside the business, or commits the business to something. For everything else, asking slows things down without adding much protection.

The harder part is making approvals meaningful: a short list, clear requests, narrow standing permissions, a named approver and a control the agent can’t skip. That’s what turns “human in the loop” from a phrase into something that actually protects you.

If you’d like help deciding where those approval points should sit in your own processes, our implementation approach sets out how we work through it.