You asked a digital assistant to save you time. You gave it access to your email, your files, and perhaps your online store. If it makes a wrong decision, how far could the consequences go?
On October 19, 2026, Microsoft raised an issue concerning the everyday use of artificial intelligence at work: the risk posed by AI agents installed by the company itself.
The assistant that can do more than is necessary
In the white paper “Securing the agentic insider,” the company points out that agents often have excessive privileges. They have access to data and tools and are involved in critical processes. Their behavior may deviate from the user’s intent, even without prior compromise by hackers.
Microsoft recommends continuous monitoring and auditing of their actions, highlighting the role of so-called Guardian Agents and Project Perception. This is Microsoft’s own approach to security, not a guarantee that a single tool will eliminate every risk.
From “write this for me” to “do this for me”
To illustrate the change, consider two different tasks. In the first, you ask the AI to draft a response to a client. You read the text, make any necessary corrections, and send it. In the second, you ask it to read your inbox, decide which messages require a response, and handle the communication.
The second option promises greater time savings. However, it presents the assistant with a series of decisions: which message is important, which file pertains to that specific client, what they can promise the client, and when they should pause to ask you.
This is where the appeal of agents lies, and this is where caution is needed. The ability to complete a sequence of tasks becomes truly valuable when each step remains within the scope of the assignment.
The email that tries to become an order
There is also a less obvious trap. OWASP, the international application security project, describes “indirect prompt injection”: instructions embedded in external content, such as a web page or a file, can influence the model’s behavior.
Simply put, text that the assistant is supposed to read as information attempts to dictate what it should do. OWASP also describes an email assistant scenario in which a malicious incoming message tricks it into searching for sensitive information and forwarding it. This is an example of a risk described in the documentation, not an incident we observed at a Greek company.
The outcome depends on the application and its permissions. An assistant that can only read has a different scope of action than one that can also send, delete, or modify data.
A simple example from an e-shop
Let’s say you ask an assistant to identify overdue orders. For this task, they need to review data and create a list. If you’ve also given them the ability to issue refunds, change prices, or send messages, you’ve opened up many more possibilities for them.
This is a hypothetical example. However, it illustrates why access must be granted specifically for this task. “Find the problem” and “do whatever you think is necessary” are different instructions.
The “But He Did It Right Yesterday” Trap
Let’s continue with the hypothetical e-shop. On the first day, the assistant prepares a flawless order list. On the second, they draft helpful responses. Then a borderline case arises: the customer requests a replacement, the product is out of stock, and an old note mentions a different agreement.
Success in previous tasks does not determine who has the authority to make a commitment on behalf of the store at this moment. Before this step is automated, it must be determined which decisions the assistant can make and which require a manager.
A practical test is to ask them to describe what will happen in the event of an exception. Everyone can present a smooth workflow. The quality of an operation is also evident in how it handles ambiguous orders, the wrong recipient, or tasks that should not be continued.
Boundaries require technical implementation as well
OWASP links excessive autonomy to three things: more functions, more privileges, and more freedom of action than the job requires. It recommends restricted permissions, human approval for high-impact actions, and authorization checks on connected systems.
This means that “don’t send anything without permission” shouldn’t just be a well-intentioned statement in a conversation. Where approval is required, the workflow itself needs to enforce it. Logging actions helps you understand what happened, but it does not, by itself, undo a transfer that has already taken place.
What to Clarify Before Clicking “Log In”
For a small business, a useful starting point is four specific questions:
- What can they access? Only the necessary files, or the entire customer database?
- What can they change? Do they prepare proposals or make direct changes?
- When do they need to seek approval? Sending items to a customer and issuing refunds require clear guidelines.
- How do you track what happened? You must be able to verify the action and revoke access.
These are practical recommendations from BEEGITAL for designing a workflow. They do not describe a specific scenario.
As we saw in the article about who can write a reply on Facebook, AI is moving from text generation to performing actions.
Before assigning it a task, define the limits of its authority. This makes automation more useful and manageable.
Featured photo: FlyD / Unsplash.