For a while, the worst an AI chat tool could do at work was hand back a confident, wrong answer. Someone on your team asked it to tidy up an email, read what came back, and decided whether to use it.
That's changing. The same tools, and a crop of new ones, can now act. They open websites, fill in forms, send email, place orders, book appointments and update records, all while signed in as the person using them. Some are AI tools that operate a web browser for someone. Others work inside the apps your team already uses.
Our guide to which AI tools staff can use, and on whose account covers the first question. This is the next one. Once a tool can act and not just answer, which jobs and which work accounts may it touch? And which stay with a person?
This isn't a product review or legal advice. It's a way to set a rule your team can follow.
What Changes When an AI Tool Can Act
A tool that only answers can be wrong, and you catch it or you don't. A tool that acts while signed in as a staff member is different in two ways.
First, it can do anything that person's login can do. If your office manager's login can issue refunds, move a patient's appointment or email every client on the list, so can a tool working under that login. The tool doesn't get its own, smaller set of keys. It borrows theirs.
Second, what it reads can steer it. A US government AI lab at NIST explains this in a January 2025 technical blog, Strengthening AI Agent Hijacking Evaluations. It describes agent hijacking as "a type of indirect prompt injection in which an attacker inserts malicious instructions into data that may be ingested by an AI agent, causing it to take unintended, harmful actions". In plain words: someone hides instructions in something the tool will read, and the tool follows them as if they came from you. The hiding place can be ordinary material, "such as an email, a file, or a website".
In one test run inside simulated work environments, not a real incident, the lab planted a hidden task that "instructs the agent to send personalized emails to everyone the user has a meeting with, including a link that purports to contain meeting notes, but in fact could be controlled by the attacker". Now picture that on your front-desk login: a friendly note to every patient booked this week, with a link that leads somewhere you'd never send them.
The trick is called prompt injection, and our piece on letting AI enter vendor bills explains it in more detail.
This isn't only about chatbots. In March 2026 the same lab published findings from a large red-teaming competition, where people try to break AI systems on purpose. It covered agents "including tool use agents, coding agents, and computer use agents", which takes in tools that operate a computer the way a person would. Its finding: "at least one successful attack was found against all of the target frontier models, highlighting the ongoing challenge that hijacking attacks pose for secure agent use". In other words, none of the leading models it tested was immune.
Why This Won't Simply Be Patched Away
The UK's National Cyber Security Centre (NCSC), that country's national cyber security agency, doesn't expect a quick fix. In a December 2025 blog written for security professionals, Prompt injection is not SQL injection (it may be worse), it compares this problem with an older attack on website databases that programmers learned to block properly. Its view is that "there's a good chance prompt injection will never be properly mitigated in the same way".
The reason is simple to state: "Current large language models (LLMs) simply do not enforce a security boundary between instructions and data inside a prompt." Large language models are the kind of AI behind these tools. Your request and the page the tool is reading land in the same pile.
So NCSC says plainly: "The best we can hope for is reducing the likelihood or impact of attacks." It also explains why acting raises the stakes: "This is particularly critical when the system calls tools or uses APIs based on the LLMs output, as an attacker can coerce it to use those tools/APIs." Translated for an owner: once the AI's output turns into clicks, emails or payments, a hidden instruction turns into an action.
Two more lines from that blog matter to an owner. One is an email rule: "Therefore don't let an LLM processing emails from random external people have access to privileged tools." The other is a test: "If the system’s security cannot tolerate the remaining risk, it may not be a good use case for LLMs." If a job can't survive the tool occasionally being tricked, it isn't a job for the tool.
You can't make the tool impossible to fool, so limit what a fooled tool could do.
Sort the Jobs by What the Tool Can Do While Signed In
The same tool can be harmless on one job and risky on the next. So instead of asking which tool is safe, sort the work into three bands.
| The kind of task | Examples from a small business | What the tool is allowed to do | Who finishes it |
|---|---|---|---|
| Band one: fine to hand over. Reading and research on public pages. | Comparing supplier catalogues, checking a vendor's opening hours, summarising a public page. | Read and report back, signed out of every work account. | The staff member, who checks the answer like any other research. |
| Band two: the tool prepares, a person finishes. | Filling in a supplier order form or a booking form. Writing a draft reply the staff member copies into their own email. | Fill in the fields, then stop before the submit button. It is not given the work inbox. | The staff member reads what it filled in and clicks submit, or pastes and sends the reply, themselves. |
| Band three: not handed to an AI tool on a staff login. | Sending anything to a customer, patient or vendor. Paying, buying, deleting or sharing files. Changing a customer, patient, client or staff record. Anything inside the work email, banking, payroll or an admin console. | Nothing. These jobs stay off the tool's list. | A person, start to finish. |
Band two: the tool prepares, a person finishes
OWASP, a nonprofit security community, backs up this middle band in its LLM06:2025 Excessive Agency entry: "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken." Its example of what goes wrong without it: "an extension that allows a user’s documents to be deleted performs deletions without any confirmation from the user".
Two honest warnings come with it. First, a confirmation step only helps if the person reads what's about to be submitted. A button clicked by habit is not a check.
Second, the pause is something the tool does, so a hidden instruction can talk it out of pausing. That's why band two is only sound where an accidental submission would do little harm, and why it runs in a separate browser profile with no saved work passwords or payment cards. If the tool did click submit, there's no card to charge and no other work account open behind it. If a supplier bills your account the moment an order goes in, treat that form as band three.
Band three: a person does it
Some band-three jobs come back every week and are worth automating. Then it becomes a separately scoped job with its own narrow access and a named owner, not a staff member's browser running unattended. Approval still doesn't go away. As our comparison of one AI agent against one per job puts it, "Wherever money leaves or a record changes, a named person still approves it". That holds for any separately built agent, including one we build for you.
A built agent that drafts work also shouldn't hold the key that publishes or sends it, and needs its own off-switch, as our piece on marketing draft agents explains.
The Trade-Offs, Fairly
The time saved is real. Copying details between screens and filling in the same booking form again and again is tedious. A tool that does the boring part gives people time back for work only they can do.
A blanket ban has a cost too. As the account guide linked above argues, banning tools people already like tends to push use onto personal accounts you can't see. A rule people can follow beats a rule they quietly work around.
A looser rule is reasonable when the tool is used signed out of every work account, or on a test account that holds no customer data. If there's nothing behind the login worth taking, there's little for a hidden instruction to reach.
A tighter rule is right for any office holding patient, client or payment information: a dental or medical office, a law firm, a club with member accounts, anyone who keeps cards on file. There, even band two deserves a second look against the rules that apply to you.
A Checklist of Settings to Look For
Menus change often, so these are features to look for, not steps to follow:
- Signed-out or separate use. The tool can be used without being signed in to work accounts, or in a separate browser profile with no saved work passwords or payment cards.
- A stop before anything final. It stops and asks before it sends, submits, buys or deletes.
- A record the business can see. It keeps a record of what it did, and the business can read it, not just the employee. That matches OWASP's advice to "Log and monitor the activity of LLM extensions and downstream systems to identify where undesirable actions are taking place, and respond accordingly." OWASP lists it among steps that limit damage rather than prevent it, so the record helps you notice and respond; it doesn't protect you.
- An off switch the business controls. A business administrator can switch the acting features off for work accounts.
If a tool lacks any of these, keep it to band-one research, signed out.
Questions to Ask Before a Tool Acts Under a Staff Login
Ask the vendor, or check the tool's documentation, with one employee's login in mind:
- When it's signed in as my employee, which of their accounts can it act in? And can it keep acting after they've stepped away from the screen?
- Before it sends, pays or deletes anything in that person's name, does it stop and wait for them?
- What does it write down about what it did under their name? Can the business read that, or only the employee?
- Can the business turn the acting features off for work accounts without asking each employee to do it?
- What does it do when a page or an email it reads contains instructions?
On that last one, NCSC's advice is the best filter you'll find: "Beware any that claim they can 'stop' prompt injection, and instead look at those who understand how they reduce it." A vendor who explains the limits is telling you more than one who promises a cure.
Red Flags
- It asks for a staff member's saved passwords, or full mailbox access, to do a one-off task. A small job shouldn't need the whole key ring.
- It runs on a schedule inside a work inbox. That's an unattended tool reading email from strangers, the exact case NCSC warns about.
- Staff share one login with an AI tool. Then nobody can tell who did what, and you can't switch off one person's access without switching off everyone's.
Frequently Asked Questions
Can staff let an AI tool fill in online forms for them?
Yes, where a mistaken submission would do little harm. The tool should stop before the submit button, and the staff member should read every field before clicking it themselves. Use it in a separate browser profile with no saved work passwords or payment cards.
Should an AI tool be allowed into the work inbox?
No. Email from outside senders can carry hidden instructions. The tool can write a draft that the staff member copies into their own email, but it should not be given the inbox itself.
If a tool asks before every action, is it safe on any account?
Not by itself. The pause is something the tool does, and hidden instructions can steer the tool. Keep it away from jobs where a wrong submission would do real harm, and make sure someone actually reads what is about to be sent.
Can a separately built AI agent take over payments or record changes?
It can do the preparation, with its own narrow access and a named owner. Where money leaves the business or a customer, patient, client or staff record changes, a named person still approves it. That is true of any agent, including one we build.
The Bottom Line
An AI tool that acts is a borrowed login that can be talked into things. So sort the work by what the tool could do while signed in. Research on public pages, signed out, is fine. Forms it fills in and a person submits are fine where a mistake would be cheap. Anything that sends, pays, deletes, shares or changes a record stays with a person.
Then add one line to the staff AI rules you already have: which jobs an AI tool may do for you, not just read, and on which accounts.
If you'd like your staff trained to use AI on their own work, see our AI training page. Our pricing page describes it as "Private AI training for your staff, on the work they actually do." And if a band-three job keeps coming back and deserves automating with its own narrow access, start a conversation with us. We build those as modular automations, and our pricing page says "Each loop is scoped, priced and given its monthly usage on its own."