WatchGuard Technologies advises CIOs to define, for every new AI application, what an agent is allowed to do on behalf of employees. The company has put forward a three-step approach for assessing the permissions of AI agents. According to WatchGuard, the reason is the growing use of agents with access to email, calendars and business applications.
According to WatchGuard, AI agents are increasingly being given access to email, calendars, documents and business applications so that they can carry out tasks independently. This gives them permissions that would normally rest with employees. The company argues that attackers can manipulate those agents to intercept data or disrupt processes. WatchGuard says this is becoming more pressing now that employees are using AI tools themselves or connecting applications to business systems without involving the security team, a practice also known as shadow AI.
Prompt injection via email
WatchGuard illustrates the risk with email. An agent that summarises messages may, through the same integration, also have access to other emails or be able to send messages. An attacker can place hidden instructions in an email that prompt the agent to look up sensitive information and forward it. The agent then treats text it is supposed to process as a command. This technique is known as prompt injection.
WatchGuard refers to OWASP, which describes this scenario in its risk list for 2026 as ‘excessive agency’: AI with too many functions, permissions or too much autonomy. The risk rose from sixth to third place on that list.
Autonomy as a design choice
The company points to a trade-off. The value of an agent lies in working independently: an agent that schedules appointments must be able to write to a calendar, and other tasks require access to multiple applications. Read permissions alone are then not enough. At the same time, the principle of least privilege applies in cybersecurity, and even necessary permissions can cause damage if misused. Requiring approval for every action in advance, on the other hand, limits the agent’s autonomy and leaves the work with the employee.
According to WatchGuard, the decision on how much autonomy an agent receives therefore belongs in the design of the application. Organisations also need to know which AI tools employees are using and how much access those tools have to business systems. Without that overview, integrations remain outside security controls, creating additional entry points for attackers.
Three steps
Martijn Nielen, Sr. Sales Engineer at WatchGuard Technologies, says that multi-factor authentication alone is not enough to secure the use of AI agents. WatchGuard therefore advises CIOs to assess permissions in three steps.
The first step is to establish, for each agent, which work it takes over and which systems it can reach to do so. You then check what it is allowed to do there: only read documents, or also modify and delete files. This shows where access goes further than the task requires.
In the second step, you restrict permissions to what the task needs. An agent that summarises emails does not need permission to send them. For necessary actions with major consequences, you determine when an employee must first review and approve them.
The third step is reassessment. New tasks, functions and integrations can change what an agent is allowed to do. WatchGuard recommends checking with every expansion whether permissions and approval arrangements are still appropriate, repeating that check periodically and revoking access as soon as it is no longer needed. The company expects that this will prevent agents from quietly accumulating more permissions than necessary.
Nielen argues that security must be part of the design of AI applications from the outset. In his view, organisations must define which permissions agents receive and keep track of which AI applications are connected to the business environment, which data they can access and which permissions they retain.
This article was originally published in Dutch on MSP Business. Read the original →
