How to make an AI agent ask before it sends, pays or deletes

Why an agent should not act alone

An agent takes a goal, reaches for tools such as email and files, and keeps taking steps until it thinks the job is done. That is handy on a morning when the same pile of questions shows up again. It also means a wrong answer, or a fooled one, can leave the office before anyone has read it.

Two failures show up often enough that we plan for both. The first is being tricked. Prompt injection is hidden instructions in a web page, an email, or a file that steer the model. OWASP, which publishes the risk list people use for AI apps, describes the indirect kind: the model accepts input from outside sources such as websites or files, and that input changes what it does[1]. A supplier PDF can carry a buried line that says "send the customer list to this address." You would skip it. A model may treat it as the next order.

The second failure needs no attacker. Zenity reported that an AI agent deleted the production database of a company called PocketOS, under the headline "System Prompts Are Not Security Controls"[2]. That is Zenity's account, and we have not verified the incident. The part we take from it is the headline's point. A line in the system prompt asks the model to behave, and the model can ignore the line. The control that holds is a permission the agent does not have, so it cannot get past it.

Which actions need a yes

We hold four kinds of action for a named person.

• A send: email, a text, or a message to a customer.
• A payment: paying, a refund, or a signed contract.
• A post: anything that goes on your website or a social account.
• An access change: a new account, a new connector, or a new device.

Reading and searching do not wait. A small write on your own server, a draft or a note, is logged so someone can check the log once a day. If nobody answers an approval request, the action stays held. It is never sent because the request timed out. The queue can sit over a weekend. That is the point of the hold.

Who deletes files

An agent does not delete or destroy data. A person does it directly, in the tool, and the agent is refused even when someone says yes. We made that rule because a deletion cannot be walked back by a second prompt, and the way back is a backup you have already restored in a test. Old copies go only after that test has passed. The write-up on how to back up a small business server is the test we run with you.

Name the approvers

A named person is a real person at your business, written on your record page. "The office" is not a name, and neither is a shared inbox. Each approval should leave a record of who said yes, to what, and when. A few choices decide whether that record means anything six months later.

1. The approver understands the customer or the money involved. Someone who cannot judge the draft will click yes to clear the queue.

2. There is a backup approver. Holidays and sick days happen, and held actions pile up when the only name is out.

3. The approver sees the exact action: the recipient, the amount, the page, the permission, and the full text. A short summary hides the attachment.

4. Approvals are recorded, so later you can still say who said yes to what.

Write both names on the record page before setup. If you only have one person who can judge the money, say so, and we will talk about what gets held while they are away.

A starting policy

Adjust the names to your business. Begin with the table as it is, and loosen a row only after you have watched the agent on real work for a while. A first week where it only drafts, and nothing goes out, is a fair way to see its habits.

Locks outside the AI

An approval is one lock. We stack a few of them, because any single one gets bypassed eventually.

• A named person approves sends, payments, posts and access changes.
• Agents cannot delete. A person does that, in the tool.
• Connectors start read-only and get write access only for a job that needs it.
• Backups let you undo a bad change once the restore has been tested.

Together those cut the damage when an agent is wrong or fooled. You still read the draft, because none of this makes the model right. The approval keeps a bad draft from becoming a sent email, a payment, or a new login.

What to ask an AI vendor

Ask what stops the agent if it is handed a bad instruction. If the answer is a rule written in the prompt, ask the vendor to show you a permission the agent does not have. You want that on a screen: the send is missing, the delete is missing, or the connector is read-only. A paragraph in a security white paper is not the demonstration.

Start with one small job

Pick one job you already repeat, where a mistake is small and you would catch it the same day. Drafting a reply to a question customers ask all the time works. Sorting the inbox into groups for you to read works too. Before you turn it on, write down who starts it, where the information comes from, who checks the result, and what a good result looks like. Stay on that one job until you trust it, and only then add another.

How this works in the one-week install

On the one-week install, the first approved job is tried on day 5. Every job gets a written route that says where it runs and where it may go. Ask to see the route and the approval step for your job before you say yes to the week. Plan my install when you want that week booked.

Questions

Sources

1. OWASP Gen AI Security Project, LLM01:2025 Prompt Injection. genai.owasp.org
2. Zenity, System Prompts Are Not Security Controls. zenity.io