The short answer: An AI agent is not a chatbot—it is a program that takes actions on your behalf: reading emails, creating invoices, saving files, and replying to customers. Prompt injection occurs when data processed by the agent—an incoming email, PDF, or web page—contains hidden text phrased as an instruction. Without safeguards, the agent may follow it because instructions and data reach it through the same channel. OWASP ranks prompt injection as the number-one risk for applications built on language models, while cybersecurity authorities warn that this vulnerability cannot be eliminated entirely. The solution is therefore not to „persuade" the agent to behave, but to implement four safeguards outside the model: least privilege (the agent cannot access more than the person it represents), human approval for sensitive actions, an audit trail (who did what, when, and on whose instructions), and limits with the ability to shut the agent down immediately.
For an AI assistant that only responds in a chat window, the greatest risk is what people paste into it. Once the same model gains access to email, accounting software, or a shared drive—and is allowed to take action—the nature of the problem changes. It is no longer just about the confidentiality of submitted data, but about everything the model can do when instructed by someone else. This article addresses that second scenario. The risks of entering company data into chatbots are covered in Company Data in ChatGPT, while AI-generated code review is discussed in AI-Generated Code: Who Reviewed It Before It Reached Users?.
How an agent differs from a chatbot
A chatbot returns text, leaving responsibility with the person using it. An agent also has tools—API integrations that allow it to read a mailbox, create a document, or send a message. That is the crucial difference between „it generated nonsense„ and „it generated nonsense and immediately sent it to thirty customers." Agents also process content that the company neither wrote nor approved, including external emails, attachments, and websites. That creates an opportunity for attack.
A concrete example of prompt injection
Imagine an agent that reviews the company mailbox every morning, sorts enquiries, and drafts replies. An email arrives that looks like a routine question. Somewhere in its body—written in tiny text matching the background colour, or hidden in the attachment’s metadata—is an instruction telling the agent to forward the latest issued invoices to a specified address.
An unprotected agent may comply. Not because it is „stupid,„ but because the language model receives instructions and data as a single stream of text—it does not have a separate „command line" and „data input" like conventional software. OWASP adds that the input does not even need to be visible or readable to a human; it only needs to be processed by the model.
There are two forms of prompt injection. Direct injection occurs when a user deliberately forces different behaviour within the conversation. Indirect injection—which is more dangerous for businesses—occurs when an instruction enters through external content loaded by the agent, such as an email, document, web page, or ticket. Microsoft describes it as a situation in which an attacker embeds instructions in third-party content and the AI interprets them as legitimate commands.
The lesson is simple: input data must not be treated as instructions.
Why prompt injection cannot simply be „filtered out"
The first response is often to add a filter. Filters and models trained to detect attacks do exist and are useful, but they do not provide an impenetrable barrier. In its guidance on deploying agents, the UK’s NCSC states explicitly that safeguards should focus on measures outside the model that restrict what the system can do in the first place—for example, ensuring that a model processing emails from unknown senders cannot access privileged tools. Microsoft recommends designing systems on the assumption that some attacks will get through, then layering defences so that the damage remains limited. The goal is not a perfect filter. It is a system in which even a successful injection cannot cause harm because the agent lacks the necessary permissions and a human must approve any sensitive action.
Least privilege: an agent must not have more access than the person it represents
This is the cheapest effective safeguard available to a small business. An agent preparing invoices needs access to orders, price lists, and contact details—not payroll data, personnel files, or backups. If it cannot access those resources, it does not matter how cleverly someone tries to manipulate it; the information is beyond its reach.
OWASP identifies Excessive Agency as a risk in its own right and divides it into excessive functionality (the agent has tools it does not need for its work, often because a ready-made „complete package" integration was used), excessive permissions (a tool has more access in the target system than the task requires), and excessive autonomy (high-impact actions lack a review step). In practical terms for a small business:
- Separate reading from writing. Source material should be collected by a role with read-only access; writing should use a separate, narrowly scoped role.
- Specify the allowed tools. A list stating that the agent „may create and edit a document" is safer than a list of prohibitions—anything not on the allowlist is unavailable.
- Enforce permissions in the target system. What the agent may do must be determined by the accounting system, file server, or mail server—not by prompt text that the model can influence.
- Do not use an administrator account. Giving an agent network-wide privileges is a common shortcut during a pilot—and the biggest mistake you can make.
Actions that must always require human approval
Human-in-the-loop means that a person must say „yes" between the agent’s decision and the action being carried out. Microsoft describes this as the last line of defence, while OWASP recommends human approval for high-impact actions. These fall into five categories:
- movement of money—payment orders, changes to a supplier’s bank details, credit notes;
- deletion and irreversible changes—deleting a document, file, or record;
- bulk communication—sending an email to multiple recipients at once;
- data leaving the organisation—exports, forwarding attachments outside the company, sharing folders;
- permission changes—adding an account, expanding access, disabling a control.
Approval comes with one condition: the person must see exactly what will happen—to whom, how much, and which file—not merely a dialog asking, „Do you agree?" A prompt with no meaningful details will be approved blindly within a week and becomes little more than an excuse.
The audit trail: who did what, when, and on whose instructions
An audit trail is a record that allows you to reconstruct what the agent did. It may also be the only way to discover that something happened at all.
In its least-privilege guidance for agents, Microsoft identifies a common weakness: logs often capture only the response shown in the chat, rather than the actual tool calls, permission scopes, and decisions made by downstream systems. Such a log is useless during an investigation. A usable record includes who (the agent’s identity, using its own account rather than a shared password), on whose instructions (the person or event that initiated the action), what (the operation called and its parameters, not the text response), when, with which permissions, with what result, and a shared ID for the entire run so that the full sequence of steps can be reconstructed.
Platform operators handle some of this work. Microsoft records separate audit events for launching an agent, calling a tool, and triggering a safeguard. You still need to verify that these events are enabled and that the logs are retained for long enough.
Limits, environment isolation, and a kill switch
The final layer limits damage over time. OWASP recommends restricting the number of actions permitted within a given period, while the NCSC advises giving agents the minimum access for the shortest possible time and monitoring unusual behaviour. Action limits define how many documents, emails, or files an agent may process per hour; exceeding the limit should stop the agent and trigger an alert, not allow it to continue silently. Environment isolation means the agent runs under an account and within a network segment that cannot reach the rest of the network. Time-limited permissions grant elevated access only for the duration of the task. A kill switch is a tested way to stop the agent immediately and revoke its credentials. The NCSC puts it bluntly: anything you cannot understand, monitor, and stop is not ready for deployment.
Beneath all these measures lies ordinary IT hygiene. An agent allowed to write to a system is yet another reason to maintain tested backups—restoration is the only reliable answer to large-scale incorrect changes. AI Without the Cloud: Which Workloads Must Stay on Your Network? examines where data resides while it is being processed.
Agents belong in the access register alongside employees
A useful model for business owners is to treat an agent with access to data as another entry in the access register. It has its own identity, a named owner responsible for its behaviour, a defined scope of permissions, and a review date. This creates the same obligations that you already apply to people: when a process changes, access is reassessed; when an agent is retired, its access—including tokens and keys—is revoked; and annual access reviews include agents as well. Permissions also accumulate just as they do for employees: anything expanded „temporarily" during a pilot will remain in place until someone removes it.
Questions to ask an AI agent vendor
Take this table to the meeting. „Our model handles that" is not an answer.
| Question | Why ask it? | An answer that stands up to scrutiny |
|---|---|---|
| What permissions will the agent receive, and in which systems? | The scope of its access determines the maximum possible damage. | A named list of systems, roles, and scopes; separate read and write access; no administrator account. |
| What exactly is logged, and where is the log stored? | An incident cannot be investigated without a record of the actions called. | Identity, instruction, operation, time, permissions, and result; stored outside the agent with a defined retention period. |
| What happens if the agent makes a mistake or receives a malicious instruction? | This reveals whether the vendor has planned for failure. | Limits on potential damage, automatic stopping on anomalies, human alerts, and a recovery process. |
| Which actions require human approval, and what does that approval look like? | Without approval, errors go straight into production. | Defined categories—money, deletion, bulk communication, exports, and permission changes—with approval showing the action’s specific details. |
| Where is the data processed, and who can access it? | This determines where the contents of invoices, contracts, and emails are sent. | Processing locations, named processors, treatment of data used for training, and contractual safeguards. |
| How can I shut the agent down immediately? | You should not have to search for the kill switch during an incident. | A tested procedure for stopping the agent and revoking its credentials, including who is authorised to initiate it. |
Frequently asked questions
How can we introduce an agent without bringing the business to a halt?
Start with a pilot in a single low-impact process, where the agent initially only reads information and prepares drafts for approval. Grant it write access only after its records show that its output is reliable—first for reversible actions, with irreversible actions enabled last.
Does this also apply to a small company with five employees?
Yes—and in some ways even more so than to a large organisation. Small businesses often lack separated systems and roles, so a single account can access everything. An agent connected to that account inherits complete access. That is why it makes sense to start by separating permissions, not by choosing technology.
If we use a well-known platform, is this handled for us?
Partly. Major providers supply filters, audit records, and dedicated identities for agents. But no provider will define the scope of permissions, allowed tools, approval rules, or which parts of your network the agent may access on your behalf.
Can we even tell whether someone attempted prompt injection?
Only if tool calls are logged and unusual behaviour is monitored—such as attempts to access resources outside the normal scope or a sudden increase in the number of actions. You cannot determine this from the response shown in the chat.
ITHOPE builds AI automation solutions in Brno and the surrounding area that can operate without blind trust in the model: with clearly defined permissions, human approval for sensitive actions, and an audit trail that makes it possible to reconstruct what happened. AI Automation for Businesses explains which processes are suitable starting points. You can learn about IT management and backups and our other services in the IT for Businesses section. If our assessment shows that a particular process is not yet suitable for an agent, we will say so.
Sources
- OWASP Top 10 for LLM Applications—prompt injection in first place (LLM01), with excessive agent autonomy listed as a separate risk.
- OWASP: LLM01 Prompt Injection—direct and indirect injection, input that need not be visible to humans, and human approval for privileged operations.
- OWASP: Excessive Agency—excessive functionality, permissions, and autonomy; minimising access, approving high-impact actions, logging, and rate limits.
- NCSC: Thinking carefully before adopting agentic AI—guidance from the UK authority dated 15 May 2026: minimum access for the shortest possible time, temporary credentials, and behaviour monitoring.
- Microsoft: Defend against indirect prompt injection attacks—layered defence built on the assumption that some attacks will succeed, with human approval for risky actions.
- Microsoft: Least privilege for AI agents—a dedicated agent identity with an owner, task-specific roles, allowed tools, and audit-record contents.
- Microsoft Purview: Audit log activities—audit events for launching an agent, calling a tool, and triggering a safeguard.
Where to find us
ITHOPE is a company based in Brno, Czechia: we do data recovery from disks, RAID and NAS, PC and laptop service and IT for business, all in our own lab at Viniční 3587/216, 615 00 Brno.
Phone +420 775 556 063 (24/7 line). You can bring the device in person, or send it by courier (Zásilkovna, PPL).