To an AI agent, a ban in the prompt is only a request

If you are thinking about an AI agent that would read company email, organize documents on a shared drive or fill in data in a customer relationship management system (CRM), then in my opinion what such an agent will get access to matters more than what it can do. An AI agent is a program in which an AI model doesn't only answer questions but takes actions itself: it reads messages, opens files, changes data or sends emails. It should get only what one specific task requires, that is, the data it needs to read and the actions it needs to take, and before it sends or deletes anything or makes a payment it should wait for a person's approval. The reason is that an AI model doesn't separate instructions from the content it reads, and the UK's NCSC (National Cyber Security Centre) and OpenAI write that this probably can't be fully fixed. It also seems to me that the most common mistake is connecting the agent to everything at once, because that is the simplest thing to do.

AI agents in the workplace in Poland

According to a report by ESET and DAGMA, based on a survey that the ARC Rynek i Opinia institute carried out in Poland in March 2026, 62% of people who work at a computer at least three days a week use AI tools in their everyday work duties, and almost one in five says they rely on the help of autonomous agents, while only 27% of companies have a written policy on the use of AI. The announcement doesn't say how many of those agents have access to email, documents or accounting, yet it is an agent's permissions that directly determine how much risk it can create (according to the joint guidance of six cybersecurity agencies, which I will come back to).

Prompt injection: an instruction hidden in the content

An AI model receives an instruction (for example “summarize today's emails for me”) and the content it is meant to work on (those emails), but both reach it as ordinary text, and the NCSC writes plainly that current language models do not enforce any boundary between instructions and data. That is what prompt injection relies on: someone puts a sentence, worded so that the model will treat it as an instruction, into content the model will read (in an email, a document or on a web page, for example), and that sentence doesn't even have to be visible to a person, as long as the model reads it. The NCSC considers it very possible that such attacks will never be completely eliminated, and OpenAI compares prompt injection to scams and social engineering on the web and writes that the problem is unlikely ever to be solved once and for all.

Data security in Copilot and in a CRM

In June 2025 Aim Security described the EchoLeak vulnerability in Microsoft 365 Copilot (the AI assistant in Microsoft's apps, such as Outlook and Teams): it was enough to send the victim a single email and wait until they asked Copilot an ordinary question (for a summary of recent messages, for example) to extract data that Copilot had retrieved while preparing its answer (and it retrieves it from email, OneDrive, Office files, internal SharePoint sites and Teams chats). Copilot can't send emails on its own, so the data got out another way: the attack slipped past the filter Microsoft used to catch such attempts and put an image in the answer, and the image's web address carried the stolen data. A browser loads images on its own, so the data reached the attacker's server (through an address in a Microsoft domain that the browser treated as safe), even though the victim clicked nothing. The researchers who found EchoLeak also write that when a model reaches for the user's trusted data because an email from outside told it to, it breaks the principle of least privilege (under which every program and every person has access only to what they need for their task). Microsoft rated the vulnerability as critical, stated that it had not been exploited in attacks and fixed it on its own side (users didn't have to do anything), and Aim knew of no affected customer.

In September 2025 Noma Security described ForcedLeak, a critical vulnerability in Salesforce Agentforce (AI agents working in Salesforce's CRM system): the attacker typed a hidden instruction into a contact form, and when an employee later asked the agent about that submission, the agent carried out the instruction and could send sensitive CRM data out (it went through a domain that was still on Salesforce's list of trusted addresses, even though it had expired and could be bought). After the report, Salesforce secured that domain and released fixes.

A ban in the prompt is not the same as a missing permission

In July 2025 the founder of SaaStr (a business development company in the software industry) described how an agent in Replit (a service where applications are written with the help of AI) deleted his database, even though he had forbidden it to change any code without permission. To me this is a good example of how a ban written into the prompt is a request to the model, not a boundary. An agent that lacks a permission has, in practice, no way to do the thing. (When it runs in a separate container, that is, a closed environment where it sees only what was deliberately put inside, I think the chances of it getting out are small.) A ban in the prompt, by contrast, is something the model may obey, but nothing forces it to. The OWASP Gen AI Security Project (a project that publishes recommendations on the security of AI-based applications) and the NCSC see it in a similar way: according to OWASP, whether a given action is allowed should be decided by the system in which the agent is acting, not by the model itself. According to the NCSC, protections should rely more on limits to what the system can do, limits that don't depend on the model, than just on trying to stop harmful content before it reaches the model.

What permissions to give an AI agent in a company

In practice it comes down to a few principles that you can find in OWASP's and the NCSC's guidance as well as in the joint guidance of six cybersecurity agencies from Australia, the United States (CISA and the NSA), Canada, New Zealand and the United Kingdom, published in May 2026. The agent gets one task and the narrowest access that task requires (an agent that summarizes customer emails in a small office only needs to be able to read email and shouldn't be able to send or delete messages). Reading alone isn't free of risk either, though: Simon Willison, who writes about this on his blog, calls a combination of three things the “lethal trifecta”, namely access to private data, exposure to content from an untrusted source (an email from a stranger, for example) and any way at all of sending something outside. If an agent has all three, an attacker can easily trick it into handing that data over. Before it sends or deletes anything or makes a payment, the agent waits for a person's approval (OWASP gives an example in which the user personally reviews every email the agent has drafted and clicks “send” themselves), and what the agent is allowed to do is decided by the system the agent runs in. A rollout starts with a tightly bounded pilot with clearly defined tasks, and its scope is widened only once confidence in the whole solution has been built. I also advise companies to run their first tests of an agent on a computer that holds no real, important data.

The same guidance also contains an example of exactly the kind of mistake I mentioned at the start: to make things easier, a company gives an agent that handles purchasing broad access to its financial systems, email and contracts, and checks its permissions only once, at deployment. When an attacker breaks into one of the minor tools connected to the agent, they gain the same overly broad permissions the agent had, so they can change contracts and approve payments without setting off any alarm.

How I do it in my own setup

In the agents that prepare reports for me, an ordinary program calculates the numbers and the AI model only describes them (amounts of money don't reach it at all). The agents can change only one thing, and in four situations they refuse to and say why. For running what I don't trust (such as commands an AI agent wants to execute, or a script from the internet), I built a sandbox: a disposable environment with no access to the internet or to my files, stocked with fake files, keys and passwords. After each run it leaves a report of what anything inside it tried to create, delete, change or send out, and then the whole thing is wiped.

I also wanted to check whether a small AI model could act as a guard that decides, before each of the agent's actions, whether to allow it, and on 172 agent commands prepared in advance (99 of them risky) the model let five of the risky ones through. Simple rules written down beforehand stopped every risky one (though they were written from the same set they were tested on). A guard like that can be useful as an extra safeguard, but I don't think it would replace permissions, because its judgments are sometimes wrong too.

Where the guidance goes further than I do

That the most common mistake is connecting an agent to everything at once is my own observation, not a research finding. Both vulnerabilities described above were found by researchers and fixed by the vendors, so they are examples of what was possible, not accounts of break-ins at real companies. The joint guidance of the six agencies also goes further than I do, because it recommends using AI agents only for low-risk tasks that don't involve sensitive data, and the NCSC adds that if a system can't tolerate the risk that remains despite the safeguards, then perhaps language models are simply not a good fit for it.

Four questions before deploying AI in a company

If I had to boil this note down to four questions I would ask before an agent gets access to anything in a company, they would be these: what the agent can read, what it may do without anyone's approval, who approves sending, deleting and payments, and whether you can see what it is doing and stop it if need be. I took the last question straight from the NCSC, which writes that an agent whose actions cannot be understood, monitored or contained is not ready for deployment. There is also the matter of data that employees paste into AI tools themselves (in the same survey, 10% of respondents admitted to sharing sensitive company data with publicly available AI models), but that is a topic for a separate note.

In short

• In my opinion, an AI agent in a company should get only what one task requires: the data it needs to read and the actions it needs to take, and before it sends or deletes anything or makes a payment it should wait for a person's approval.
• An AI model doesn't separate instructions from the content it reads, so a sentence hidden in an email, a document or on a web page can change what the agent does (that is exactly what prompt injection is), and the NCSC and OpenAI write that this probably can't be fully fixed.
• In Microsoft 365 Copilot and in Salesforce's agents, researchers showed that an instruction hidden in a single email or in an entry in a contact form could make the AI assistant leak data it had pulled in to answer an employee's ordinary question (the vendors have since fixed both vulnerabilities).
• A ban written into the prompt is a request to the model, whereas a missing permission is a boundary, which is why what an agent is allowed to do should be decided by the system the agent runs in, not by the model itself.
• Before an agent gets access to anything in a company, I would ask four questions: what it can read, what it may do without anyone's approval, who approves sending, deleting and payments, and whether you can see what it is doing and stop it if need be.