AI agents can read files, run commands and access business systems on behalf of employees. If attackers manipulate them, or exploit the tools connected to them, legitimate access can become a route to data theft and system compromise.
Imagine an AI assistant that has permission to read company emails, search internal documents and update a customer database. An employee asks it to summarize a supplier’s proposal. The document contains hidden instructions telling the assistant to find confidential pricing information and send it to an external address.
The employee did not ask for that action. The assistant was not designed to steal data. But if the agent follows the malicious instructions and has access to the necessary tools, it could expose information without an attacker ever having to log in as an employee.
This is one of the security challenges enterprises face as artificial intelligence moves from answering questions to taking actions.
AI agents can search databases, write and execute code, interact with cloud services and carry out multistep workflows with limited human intervention. Those capabilities can improve productivity, but they also introduce new ways for attackers to misuse legitimate access.
The problem is not necessarily that an AI model has malicious intentions. It is that the model may be manipulated, make a mistake or invoke a tool in an unsafe way — and the surrounding system may allow the action to proceed.
For enterprises adopting agentic AI, the question is no longer just whether a model produces a correct answer. It is whether the organization can control what the model does, what it can access and what happens when it goes wrong.
What is an AI agent, and why is it different from a chatbot?
A conventional chatbot primarily responds to prompts with generated text. An AI agent can go further by using tools to complete tasks.
An agent might receive a request to investigate a security alert, collect relevant logs, query a threat-intelligence service, prepare a report and open a ticket for an analyst. Rather than requiring a person to perform every step, the agent can decide which tools to use and in what order.
The tools themselves might include a web browser, a database connector, a command-line interface, an email system or an application programming interface (API). The agent may also retain information between steps to help complete a longer task.
These capabilities create three important security conditions: the agent can access information, it can encounter content controlled by someone else, and it may be able to take actions or communicate outside its immediate environment.
The OWASP AI Agent Security Cheat Sheet identifies risks involving excessive permissions, untrusted inputs, unsafe tool use and insufficient human oversight.
Consider a coding agent that can read a software repository, execute shell commands and download dependencies. It may be able to complete a programming task independently. But if it also inherits a developer’s credentials and unrestricted network access, a manipulated instruction could potentially expose source code or trigger an unwanted operation.
The distinction is important: an agent’s security depends not only on its model but also on the permissions, tools, data and execution environment surrounding it.
How can an AI agent become an insider threat?
An insider threat traditionally involves someone with legitimate access who misuses it, deliberately or accidentally. An AI agent creates a related problem: it can operate with legitimate access without necessarily understanding the consequences of every action.
There are several ways this can happen.
1. An attacker manipulates the agent through the content it reads
One of the main risks is prompt injection. This occurs when malicious instructions are introduced into content that an AI system processes, potentially changing how it responds or what it does.
The instructions could be placed in a webpage, email, document, software repository or support ticket. An employee might ask an agent to summarize the content, unaware that it contains instructions intended to manipulate the model.
This is known as indirect prompt injection because the attacker does not necessarily communicate with the agent directly. Instead, the malicious instructions arrive through material the agent is asked to process.
For example, an employee could ask an AI assistant to review a vendor’s website. The page might contain text instructing the assistant to search connected documents for confidential information and transmit it elsewhere.
Whether the attack succeeds depends on the agent’s design, the model’s response, the tools available and the controls governing their use. A prompt injection does not automatically result in a breach. But the risk increases when an agent can both access sensitive information and send data outside the organization.
The US National Institute of Standards and Technology’s Center for AI Standards and Innovation has examined this problem in its research on agent hijacking. Its work describes how malicious instructions embedded in data processed by an agent can cause unintended actions.
2. The agent has more permissions than it needs
An agent may inherit the privileges of the employee who created it or use a service account with broad access to corporate systems.
That can turn a limited task into a much larger security risk. An assistant intended to retrieve customer information, for example, might also have permission to modify records, export entire databases or access administrative functions.
If an attacker manipulates the agent, the potential damage is determined partly by the permissions it possesses.
A Cloud Security Alliance survey published in April 2026, commissioned by AI security company Zenity, found that 53% of surveyed organizations had experienced AI agents exceeding their intended permissions. Nearly half reported an AI agent-related security incident in the preceding year.
These figures are survey findings, not a measurement of every enterprise’s exposure. Nevertheless, they illustrate why permission management needs to be part of AI deployment planning.
3. A flaw in the agent’s software lets an attacker execute code
Not every agent security problem begins with a model being tricked. Vulnerabilities in the software that connects models to tools can also create a route to compromise.
In May 2026, Microsoft’s security researchers disclosed two vulnerabilities in Semantic Kernel, an open-source framework used to build AI agents.
One vulnerability, CVE-2026-26030, could allow remote code execution under specific conditions involving prompt injection and a vulnerable search-plugin configuration. Another, CVE-2026-25592, involved arbitrary file writes through a file-download function in the .NET SDK.
Microsoft demonstrated how a manipulated prompt could lead an agent to execute code on the host machine. The company said the vulnerabilities had been fixed and provided guidance on affected versions and remediation.
In its technical account of the vulnerabilities, Microsoft explained that the problem lay in how the framework and tools handled model-controlled inputs.
The lesson is that an AI agent can become a path to conventional system compromise. If a tool accepts unsafe parameters or writes files to unrestricted locations, an attacker may exploit that weakness through the agent’s normal workflow.
Enterprises building agents should therefore treat their frameworks, plugins and tool integrations as part of the software attack surface — and patch them as they would other business-critical software.
What makes agent attacks difficult to detect?
Traditional security monitoring often looks for suspicious logins, malware, unusual processes or unauthorized network connections. Agent-related attacks may initially look like legitimate activity because the agent uses approved accounts and tools.
A database query might be authorized. A file export might be permitted. An API call might come from a trusted service account. The problem is that the action may be inappropriate for the task the agent was supposed to perform.
Security teams need to understand not just which identity performed an action, but whether it was an AI agent, which task it was executing, what information influenced its decision and whether the action was within the approved scope.
Visibility is already a concern. In an April 2026 Cloud Security Alliance survey, commissioned by Token Security, 82% of respondents reported unknown AI agents running in their IT environments.
The result should be interpreted in the context of the survey’s respondents and methodology, rather than as a universal estimate. But it points to a practical problem: organizations cannot adequately secure agents they do not know are running.
Agents may be created by developers, embedded in applications, introduced through third-party services or enabled by business teams outside formal IT procurement. Each can have different permissions and connections.
Without an inventory, security teams may not know which agents can access sensitive information, which credentials they use or who is responsible for shutting them down.
How should enterprises secure AI agents?
There is no single control that eliminates agent-related risk. Enterprises need to combine identity management, access restrictions, monitoring, testing and human oversight.
Give each agent its own identity
Agents should use identifiable, dedicated accounts rather than simply inheriting an employee’s credentials. This makes their actions easier to trace and allows access to be revoked without disabling the employee’s account.
Permissions should be limited to the specific task. An agent that needs to read a database should not automatically be allowed to modify or export its contents.
Where possible, organizations should use short-lived credentials and grant access only for the duration of a task.
Restrict the tools an agent can use
Start with a small set of approved tools and expand access only when there is a clear business need.
A document summarization agent should not need unrestricted shell access, payment permissions or the ability to send arbitrary files to external destinations.
High-impact operations, such as deleting records, changing access policies or transferring sensitive data, should require additional authorization. The model’s own decision that an action is safe should not be treated as authorization.
Separate the agent from critical systems
Agents that execute code or process untrusted content should run in isolated environments with tightly controlled access to files, credentials and networks.
Network access should be restricted to the destinations required for the task. If an agent does not need to reach the public internet, it should not have unrestricted outbound connectivity.
Isolation also limits the damage if an agent is manipulated or a vulnerability is exploited.
Monitor actions, not just prompts
Logging should capture which agent acted, which tools it called, the identity and permissions it used, and the resources it accessed. Security teams should look for unusual sequences of activity, such as an agent reading a large number of sensitive files before making an unexpected external connection.
These records should be stored centrally so that an attacker or compromised agent cannot easily erase the evidence by deleting local logs.
Monitoring should also cover the systems hosting agents. Suspicious child processes, unexpected file writes and unusual network connections may reveal that an agent has been used to execute code.
Test the complete workflow
Testing only the underlying AI model is not enough. Enterprises should test the complete application, including its prompts, tools, credentials, APIs and execution environment.
Security teams can use controlled exercises to determine whether malicious instructions in a document can cause the agent to access restricted data, invoke an unauthorized tool or send information to an unapproved destination.
The OWASP AI Agent Security Cheat Sheet recommends adversarial testing, strict tool permissions, human approval for high-risk actions and controls that separate decision-making from execution.
These checks should be repeated when models, prompts, tools or permissions change.
Is the answer to stop using AI agents?
Not necessarily. AI agents can automate repetitive work, help developers write and test code, and assist security teams with investigations. The goal is to capture those benefits without giving an unpredictable system unrestricted access to business-critical resources.
The most important distinction is between allowing an agent to recommend an action and allowing it to execute that action. An agent can prepare a database update, for example, while a separate authorization system verifies whether the update is permitted. A person may need to approve particularly sensitive changes.
This approach also makes it easier to limit the consequences of a mistake. If the agent’s credentials are narrowly scoped, its network access is restricted and its actions are logged, a successful manipulation is less likely to become a full-scale compromise.
Enterprises should begin by identifying where agents are running, what information they can access and which actions they can take. They can then prioritize systems that combine access to sensitive data, exposure to untrusted content and the ability to communicate or make changes.
AI agents are becoming another class of software that enterprises must secure. But unlike conventional applications, they can interpret natural-language instructions and choose among tools dynamically. That makes it especially important to enforce security outside the model itself.
The central rule is simple: give an AI agent only the access it needs, independently verify high-risk actions, and assume that instructions it encounters may be malicious. The agent can help decide how to complete a task, but the organization’s security controls must determine what it is allowed to do.
