Keep a human approval step before an AI agent moves money, sends a sensitive or binding message to a customer, deletes important records or accepts a contractual commitment, and let it search, summarise and draft within narrow permissions. Get that boundary wrong and a confident but mistaken piece of generated text becomes a payment, a disclosure, a lost record or a promise the business has to honour.
This explainer is for small-business owners and managers trying out agents: software built on a large language model that can use other tools, such as an inbox, a payment system or a customer database. It is not a product comparison or legal advice. The four gated actions are this publication’s recommended default, drawn from security and risk guidance, not a regulator’s list. Adoption and cost decisions sit in Business; more applied-AI explainers are in Technology.
| Item | What it means | Source or condition |
|---|---|---|
| Searching and summarising | Can run without per-action approval, with read-only access to approved sources | OWASP least-privilege advice; read access can still expose sensitive data |
| Drafting a reply | The agent prepares text but has no permission to send or publish it | OWASP mailbox example (LLM06:2025) |
| Payments and refunds | Hold above a set spending limit or outside policy | OWASP high-impact approval; ICO spending-limit example; no universal amount |
| Customer messages | Review sensitive disclosures, disputed claims and promises before sending | OWASP “send” example; fixed templates may follow a lighter rule |
| Deletion and bulk changes | Confirm which records, how many and whether they can be restored | OWASP deletion example; restore must be tested, not assumed |
| Contracts and commitments | Review final terms and counterparty before accepting | Editorial recommendation; legal effect not assessed here |
| Wider permissions or data access | Escalate requests that widen the agent’s reach | OWASP least privilege; ICO access-control example |
Why an agent needs a different rule from a chatbot
A chatbot hands you text; an agent can act on it. OWASP, the nonprofit application-security project, describes in its guidance on excessive agency how language-model systems are given tools to call other systems, often with the model choosing the tool and feeding its own output into the next step.
Two failure modes matter most. Generative models can present false information confidently, and NIST’s Generative AI Profile notes they can also invent reasoning or citations that make a wrong answer look justified. And an agent reads content it did not write, such as emails, web pages and files, which can carry instructions; OWASP calls this indirect prompt injection. In one hypothetical OWASP scenario, a malicious email tricks a mail-summarising assistant into searching the inbox and forwarding sensitive information to the attacker.
Neither problem has a clean fix. OWASP says it is unclear whether fool-proof prevention of prompt injection exists, and the UK National Cyber Security Centre (NCSC) argues for managing it as a residual risk, relying on deterministic, non-AI safeguards that limit what the system can do. Approval is one such safeguard: a check between what the agent proposes and what happens.
Takeaway: Judge an agent by the actions it can take, not by how well it writes.
Four actions that should wait for a person
OWASP advises requiring a human to approve high-impact actions before they are taken, but it does not define “high-impact” for a small business. NIST’s voluntary AI Risk Management Framework leaves risk tolerance to each organisation and asks that risks be prioritised by impact, likelihood and available resources. On that basis, four kinds of action make a sensible default: they are hard to reverse or bind the business to outsiders.
Payments and refunds
Releasing a payment, issuing a refund or changing a supplier’s bank details moves money that may not come back. The UK Information Commissioner’s Office (ICO), in a report on agentic AI, gives the example of an agent authorised to make purchases automatically up to a set amount and required to ask permission above it. A small amount is not automatically safe: a new payee, many small payments that add up or a changed account number deserve review regardless of size. No source sets a universal threshold; each business must choose its own.
Customer messages
Messages that disclose personal or commercial information, answer a complaint or promise a price, delivery date or remedy should be read before they go out. One fix OWASP gives in its inbox scenario is for the user to review and press send on every drafted message. A small set of fixed, pre-approved templates, such as an order confirmation the agent cannot edit, can follow a lighter rule.
Deleting records and bulk changes
OWASP’s example of excessive autonomy is an extension that deletes a user’s documents without confirmation. Before an agent deletes or overwrites records, the reviewer should see which records, how many and whether they can be restored. A backup helps only if restoring from it has been tested.
Contracts and commitments
Accepting terms or confirming an order form creates obligations. An agent can summarise a contract and flag unusual clauses; a person with the authority to commit the business should approve the final terms and the counterparty. Whether an acceptance sent by an agent is legally binding depends on jurisdiction and circumstances, which this article has not assessed. The same caution applies to terms with overseas distributors, covered in our explainer on how small manufacturers build international sales channels.
A fifth case sits alongside these: requests for new tools, data sources or wider permissions should go to someone with authority to grant them.
Common mistake: Giving a drafting agent the right to send “for convenience”. If the tool can send, an injected instruction in an incoming email can make it send.
Takeaway: Gate the actions that move money, reach outsiders, destroy data or bind the business, and let the agent prepare everything up to that point.
Permissions do more work than the approval button
Approval is the last line of defence, not the first. OWASP traces excessive agency to three root causes: excessive functionality, excessive permissions and excessive autonomy. Approval addresses only the third; the first two are fixed with fewer tools and narrower access. In OWASP’s example, an assistant that summarises email needs to read mail, not delete or send it.
Where the check sits matters as much. OWASP advises enforcing authorisation in downstream systems, such as the payment platform, email service or database, rather than relying on the model to decide whether an action is allowed. The NCSC adds that an AI system processing emails from unknown senders should not have access to privileged tools. An instruction in the agent’s prompt saying “always ask before paying” is not a control. A payment system that refuses the transaction until a person has recorded an approval is.
The same logic applies where software triggers steps in production; see what digital manufacturing means on the factory floor.
Common mistake: Treating the agent’s confidence or its explanation as a safety check. NIST notes that generated justifications can themselves be wrong.
Takeaway: Remove unneeded tools and access first, then enforce approval in the system that executes the action.
What a useful approval request shows
The ICO’s guidance on individual rights in AI systems, which the regulator says is under review following the UK’s Data (Use and Access) Act, warns that a decision does not stop being automated just because a person rubber-stamped it, and that reviewers need the authority and competence to go against a recommendation. Article 14 of the EU AI Act sets similar design requirements for high-risk AI systems, including awareness of automation bias and the ability to override or stop the system. Under the act as amended in 2026, those requirements apply from 2 December 2027 to high-risk uses listed in Annex III and from 2 August 2028 to high-risk AI in products covered by the EU laws in Annex I. This article borrows only the design principle.
As this publication’s recommendation, not a published standard, a request should show:
- Action: pay, send, delete or accept.
- Target: the payee, the recipient, or the records affected and how many.
- Details: the exact amount, final message text or contract terms, identical to what will run.
- Evidence: the original invoice, ticket or document, not only the agent’s summary of it.
- Consequence: what happens if it goes ahead and whether it can be undone.
- Decision: approve, edit or reject, recorded with the reviewer’s name.
If the amount, message or set of records changes after approval, the approval should lapse and a fresh one be requested. If no one responds, the action should stay on hold or fall back to a draft rather than run automatically.
Takeaway: Show the reviewer the exact action and its source, and tie the approval to that version only.
Where this does not hold
- Not every step needs a person. Low-impact, tightly scoped actions a fixed rule can check, such as tagging support tickets, can run under a defined policy. Approving everything breeds the rubber-stamping the ICO warns about.
- Human review has costs and blind spots. The ICO notes that reviewers may need to see more personal data and may reintroduce human bias; NIST describes automation bias, the tendency to defer to automated output. A reviewer without time, context or authority adds a click, not oversight.
- Approval and stopping do not undo. NIST’s framework calls for ways to deactivate a misbehaving system and recover, but halting an agent will not recall a payment or email already sent. OWASP notes that logging and rate limits reduce damage without preventing it.
- Residual risk remains. If the risk left after these controls is intolerable, the NCSC suggests the task may not suit a language model at all.
- Legal scope is not settled here. This article does not determine whether a business falls under EU high-risk rules or UK rules on automated decisions; that needs specific advice. NIST’s framework is voluntary, and the ICO stresses that using an agent does not shift responsibility for personal data away from the organisation.
Takeaway: Put approval where the consequences justify the cost, and plan for what it cannot catch.
How we researched this
This explainer draws on NIST’s AI Risk Management Framework and Generative AI Profile, OWASP’s 2025 entries on excessive agency and prompt injection, UK NCSC and ICO publications, and Articles 14 and 113 of the EU AI Act in its consolidated text of 27 July 2026. Published articles and community discussions were read only to see what readers ask, not as evidence. We did not test agent products or interview businesses, and found no reliable data on how often agent errors occur in small businesses. Our editorial policy explains how we select and attribute sources.
Takeaway: These sources support advice on designing controls; they do not show how any particular agent product performs.
