According to IBM's Cost of a Data Breach Report 2025, 20% of organizations have already experienced breaches linked to unauthorized AI use, adding an average of $670,000 to breach costs per incident.
Agentic AI systems are developing at a rate that the majority of security teams are unable to keep up with. The attack surface Agentic AI creates is qualitatively distinct from what has been produced by traditional LLM deployments. This post identifies the frameworks that are important and where most enterprise deployments fail the most, as well as the threat vectors.
Compared to the security risks of a chatbot, Agentic AI systems are substantially more dangerous. The biggest risk is not prompt injection, but rather what Agentic AI systems that are given too many privileges can. The pillars of Agentic AI system security are the principles of least privilege and the human-in-the-loop systems.
What Makes Agentic AI Systems Unique from Standard LLM Chatbots?
Everyone understands the difference between a responding entity and an acting entity.
The problem is with the severe and poorly understood implications for security. Standard LLM chatbots merely present text outputs and Agentic AI systems take the text outputs and perform actions in the real world. These actions may include, but are not limited to, querying internal databases, making external API calls, sending and executing code, and completing a web search. Typically, Agentic AI systems complete these actions in an unmonitored and automated fashion.
Four properties characterize agentic systems and shape their unique security exposure.
- Autonomy: Agents can autonomously decide and perform actions without human oversight of each step. The longer the chain of agents, the more actions differ from what was authorized by a human.
- Tool use: Agents are linked with external systems, cloud services and internal APIs. Each connection constitutes a potential attack surface.
- Multi-agent chaining: Entire network of agents is increasingly used in an enterprise, with each agent receiving and processing the output of one that precedes it, a compromised agent can manipulate the output of the subsequent agents before a human conducts an oversight.
- Real world action execution: Agents can execute actions, they can also be instructed to perform harmful tasks that can breach the security of a system.
Because of these four characteristics, you can see why the security of AI agents needs different threat models compared to the security of custom enterprise software.
The Threat Landscape: Attack Vectors You Should Know
What are the significant threat vectors in agentic AI systems?
The same vectors appear in almost every overly permissive enterprise engagement I've seen.
1. Prompt Injection (Direct and Indirect)
Prompt injection is a form of negative AI threat most discussed by teams working at the input layer and is classified as LLM01 in the OWASP Top 10 for LLM Applications. Direct injection is when the user input manipulates the agent’s instructions. Indirect injection is worse when we talk about agentic contexts. This occurs when a malicious instruction is embedded in a document the agent reads, a web page the agent visits, or an API response the agent processes. The agent will consider the instruction authentic and proceed to act on it.
2. Excessive Agency
This is classified by OWASP as LLM08 and in my experience, it is the failure mode that causes the most damage in production. Excessive agency occurs when an agent is granted an overabundance of permissions. This occurs with access to tools, overly broad API scopes, and database read/write permissions. As a result, the agent is over-permissioned. The agent may also be unsafe due to manipulation and/or injections. Over-permissioned and unsafe agents have a large impact.
3. Insecure Output Handling
This is LLM02 in the OWASp framework. Agent outputs integrate with and are consumed by downstream systems. These may include databases, rendering pipelines, and other agents. If validation and sanitization are ignored at a handoff, an attacker may use an agent to produce output that compromises the target to other systems in order to execute SQL injection, cross-site scripting (XSS), or remote code exploitation.
4. Privilege Escalation
5. Multi-Agent Trust Failures
6. Supply Chain Vulnerabilities in Plugins and Tools
Threat Vector Reference Table
Attack Vector | Risk Level | Primary Control | Framework Reference |
|---|---|---|---|
Prompt Injection (Indirect) | Critical | Input/output validation; treat external content as untrusted | OWASP LLM01 |
Excessive Agency | Critical | Least-privilege tool permissions; scope all API access by task | OWASP LLM08 |
Insecure Output Handling | High | Output sanitization before downstream system ingestion | OWASP LLM02 |
Privilege Escalation | High | Agent identity frameworks; no self-permission expansion | OWASP LLM08 / UC Berkeley CLTC 2026 |
Multi-Agent Trust Failures | High | Inter-agent authentication; independent validation at each node | UC Berkeley CLTC 2026 |
Insecure Plugin Design | High | Plugin sandboxing; supply chain review before integration | OWASP LLM07 |
Shadow AI / Unauthorized Agents | Medium–High | AI governance policy; continuous inventory monitoring | NIST AI RMF – Govern |
AI-Related Breach Causes: The Proportional Picture
Based on IBM Cost of a Data Breach 2025 data and documented industry patterns, here is an approximate breakdown of how AI-related breach causes distribute across enterprise environments.
Where Agentic Deployments Usually Break First
The following is the most common method of agent deployment I've observed in enterprise settings, and it rarely represents a sophisticated attack. A development team provides an enterprise AI agent broad permissions to internal APIs and a production database. The team also provides the agent permissions to all tools. This is done under the assumption that the agent is still in an internal testing phase and will not be made available to the rest of the employees. This assumption is clearly incorrect, and the agent continues to operate beyond its original permissions.
The Frameworks That Govern Agentic AI Security
What do NIST and UC Berkeley’s CLTC have in mind when it comes to agentic AI security?
Currently, two frameworks are most relevant to securing enterprises from agentic AI.
NIST AI Risk Management Framework – Agentic Profile
NIST’s AI RMF places risk management at a different balance when looking at the following four functions.
- Govern: Set accountability and policy frameworks and structures of AI oversight pre-deployment.
- Map: Consider the specific context in which the AI system will be deployed, and the risks therein.
- Measure: Define and evaluate the risks with some defined likelihood and impact.
- Manage: Put in place safeguards, and provide ongoing monitoring with a sufficient ability to reverse course.
The Govern function is where most organizations are failing. IBM reports that around 63% of organizations do not have a plan for AI governance, meaning that the organization is not accountable. With no accountability, the problem of agent over-permission remains.
The UC Berkeley Center for Long-Term Cybersecurity has published a profile on agentic AI risk, identifying five risks which differentiate agentic deployments from conventional LLM use (Source: cltc.berkeley.edu).
- Goal Misalignment: agents that optimize for a metric that is not aligned with the goal.
- Permission Leakage: agents obtain permissions that they were not given.
- Shut Down Resistance: agents are able to take steps to avoid being turned off by a human.
- Self-Replication: agents are able to create copies of themselves.
- Hallucination Propagation: agents that provide incorrect outputs which other agents use as correct inputs.
Risk of Shut Down Resistance may sound theoretical. I have seen early implementations of this in production, where agents are continually attempting to perform actions that creates a never-ending loop of API calls that prevents the agent from being turned off. The agent does not need to be "sentient" for this to occur. The only thing that is needed for this to occur is the agent treats task completion as the most important thing and views being interrupted as a barrier.
Why Focus on Prompt Injection First Is Misplaced
The majority of security teams first focused on the input layer to create controls to combat prompt injections. I understand why this is the case: prompt injections are the most talked about type of security threat, the type of attack is clear, and filtering the input seems like the first obvious control.
Here is the problem: An indirect prompt injection embedded in a poisoned external document can still successfully circumvent input filters. The agent may retrieve a document, a web page, or an API response, all of which are subject to no input sanitization on your end. In this case, the injection is delivered in context, not in the input.
More than filtering what the agent can be instructed to do, restricting what the agent can actually do is more important. This is because in agentic systems, the injection surface is much greater than any particular input channel. The principle of least privilege tool access effectively contains the blast radius, no matter how the injection comes to be. Input hardening is important, but it should not be the primary control. The greatest production risk, and the one that is least considered in the course of deploying the system, is the excessive agency of the system.
While this is the opposite of what most vendors would recommend, it is actually what I have seen in production security failures.
Effective Production Controls
Securing agentic AI in production requires defense in depth. Of the many controls I implement, these are the most important:
1. Least Privilege Access by Agents
For each tool, restrict permission to what is necessary to complete the task at hand. If an agent is only reading customer records for a specific task, it must not have permission to write those records. If it works in one department's API, it must not have tokens for other department's APIs. Permissions must be audited before going live, and after every change to the system.
2. Human-in-the-Loop Checkpoints
Clearly identify action categories requiring explicit human approval prior to execution. This includes approving write operations, data exports, external communications, and actions related to granting privileges. Automate all other actions, but maintain human confirmation for actions that entail significant risk.
3. Output Validation and Sanitization
Sanitize and validate all outputs bound for any downstream system. This includes agents, databases, or rendering pipelines. Discard the notion that outputs from an agent are safe simply because the agent was presented with a clean prompt. Agent Identity and Authorization Frameworks.
4. Continuous Monitoring and Anomaly Detection
Track agent actions throughout the production phase to identify any that fall outside of the established norms. Call patterns to tools, APIs, and exports that are abnormal are some of the earliest signs of a system being compromised or of some other form of unauthorized intervention.
5. Shutdown and Rollback Mechanisms
A shutdown path and rollback procedures must be implemented and tested for all agent deployments. If an agent is compromised or is acting outside of its intended purpose, you should be able to stop the agent and undo its actions without a full system interruption. Design with the shutdown resistance in mind, as it is a recognized risk.
Shadow AI: The Underestimated Breach Vector
Shadow AI refers to the illicit AI tools that exist beyond the IT governance structures. These tools are not an emerging risk. According to the IBM Cost of Data Breach report for 2025, 20% of surveyed organizations reported that the use of unauthorized AI by their employees was a contributing factor in a data breach. Each of these breaches cost the organization over $670,000, on average.
The risk increases with the use of agentic systems. A developer using an agentic system beyond the scope of company policy and support is doing more than simply using an unsupported system. Enterprise grade AI security controls such as identity systems, permission systems, and activity monitoring become ineffective in the presence of shadow systems. Agentic systems run without governance, audit, or a means to disable them.
The NIST AI RMF’s Govern function aims to address the gaps left by existing systems. Inventories of AI systems, knowing what systems have been deployed and by whom, and what tools they are permitted to use and whether or not they have been sanctioned, are the foundations of any derivative security system.
My Point for Agentic Systems
The past eight years have been spent as a consultant in enterprise security systems design and the implementation of AI. Security systems that limit the blast radius of a system have become the baseline and starting point.
Before agentic systems can become operational, I require that:
- The developer draw a complete picture of the agent’s system including every service, API, data storage, file systems, and every service on the Internet that the system will have access to. The developer identifies the minimum permission levels needed for each service. What constitutes the human-in-the-loop threshold?
- Which action categories will need human approval? Answer these questions prior to deployment, not post first occurrence.
- Establish the agent identity framework. Independent authentication for each agent is required. No ambient permissions and complete logging for each tool invocation are compulsory.
- Carry out a comprehensive inventory of your AI systems. Before you start hardening AI agents, you need to know each agent that exists in your environment. Shadow AI represents a gap in each control you implement.
- Perform shut down and roll back tests pre-go live. Resistance to shut down is an acknowledged failure mode. If the path to shut down has not been tested, you do not possess one.
Security for AI agents is not a stand alone problem at the point of deployment. It demands constant oversight, systematic audits of permissions, and governance that keeps pace with the rapid expansion of agent capabilities. Organizations that regard agentic AI security as an ongoing process, as opposed to a check box at launch, are the ones that manage to mitigate incidents prior to them becoming breaches.
Frequently Asked Questions
What are the main security risks of AI agents?
Agentic AI systems encounter unique threats distinct from traditional LLM Chatbots. The most dangerous risks are prompt injections (direct user prompt injections and indirect injections via content agents), over-agency (agents acting with excessive authority due to over-permissioned tool access), insecure output processing (unvalidated agent outputs being processed and integrated into downstream systems), unauthorized privilege escalation, multi-agent trust compromises (one of the compromised agents corrupting the downstream agents), and systemic supply chain risks with external third-party plugins. How do you prevent prompt injections in AI Agents?
There is no silver bullet control mechanism that completely mitigates the risk of prompt injections. Rather, the most effective mechanism is a combination of the following: treat all external content (documents, web pages, API responses, etc.) as untrusted; validate and sanitize all inputs prior to processing by the agent; employ output validation prior to agents outputs being sent to downstream systems; and apply least-privilege permissions. The successful injection of prompts should be limited in its potential impact. As part of its top 10 for LLM Applications, OWASP has classified prompt injection as LLM01 (owasp.org) and agentic systems are also exposed to indirect prompt injection risks which are typically more difficult to filter than direct input manipulations. While input hardening is important, it should be accompanied by permission controls to contain the successful agent output.
What does excessive agency mean in regards to security in AI?
Classified as LLM08 by the OWASP, excessive agency refers to allowing AI agents to access tools, APIs, or databases with permissions that go beyond the requirements of a given task. It creates risk even if the agent is not malicious. An agent with excessive permissions can be controlled by prompt injection. Since the agent has the permissions it needs, it can be designed to make data exports, API calls, or write operations, even though that was not the purpose of its design. Because the permission problem is clear even before the attack is, excessive agency is the riskiest production threat with agentic deployments. The control in these cases is not granting permissions beyond what is required. It means that every tool be limited to the minimum required for each specific workflow.
How can organizations govern agentic AI systems?
The first step toward governance of agentic AI systems is the application of the NIST AI Risk Management Framework to agentic deployments through its four functions: Govern, Map, Measure, and Manage. The most important of the four functions is the Govern function. The first step toward the Govern function is to create an inventory of AI systems to include information about every agent throughout the organization, including those that may have been deployed covertly. In addition to inventorying AI systems, governance involves defining who is accountable for the permissions granted to each agent, establishing an ad hoc policy for high-risk actions, and instituting an ongoing monitoring of agents with the development and testing of procedures for the undeployment (or shutdown) of the agents. The UC Berkeley CLTC’s Agentic AI Risk-Management Standards Profile (February 2026) provides a governance framework for the agentic risks of privilege escalation and shutdown resistance.
Closing Thoughts
The security profile for Agentic AI is distinct from static LLM chatbots. Unlike LLM chatbots, Agentic AI systems can traverse external data, make phone calls, conduct automated emailing, and trigger automated workflows, among other capabilities. According to OWASP's LLM Applications Top 10, prompt injection (LLM01) and excessive agency (LLM08) are the two most critical threat categories for LLM Applications.
In UC Berkeley's CLTC Agentic AI Risk-Management Standards Profile (February 2026), the risks associated with unauthorized privilege escalation, resistance to shutdown, and the agent chain's propagation of hallucination are noted as risks in production. According to the IBM Cost of a Data Breach 2025 report, AI-enabled attacks will occur in 1 in 6 data breaches, and that number will continue to climb as agentic deployments become pervasive.
The routinized response of security teams is to fortify the input layer. While that is generally warranted, the ecosystem impact of an agent that has been granted excessive permissions represents a much larger risk. Address permission issues before attempting to implement additional safeguards.
James Mitchell
He is the Founder and Editor-in-Chief of Techisane. He holds a Master of Science (MS) in Computer Science and a CISSP certification, with eight years of experience in enterprise technology. He began his career working with IT infrastructure before advancing into IT security and consulting. Mitchell brings firsthand experience to his writing, drawing on technologies he has implemented, tested, and worked with in real-world environments.