In July 2026, AI agents behind an internal OpenAI cybersecurity evaluation somehow circumvented the controls meant to keep them off the open internet and reached Hugging Face’s production infrastructure. In the four days that followed, they exploited a two-code execution flaw in the Hugging Face dataset processing and escalated their privileges until they reached the internal clusters. From there, they logged about 17,600 actions. None of these targeted customer data. They had determined that Hugging Face likely held the answer to a benchmark they’d been assigned. All this was done to reach that answer.
These agents weren’t given any instructions to attack a third party. They pursued this path on their own in their quest to meet their goal using a route no one had anticipated. Every system and credential they could use to get to that goal was leveraged.
This represents a core challenge of AI agent security, and it keeps on escalating. Gartner has forecast that by the end of 2026, 40% of enterprise applications will be integrated with task-specific AI agents, up from a mere 5% in 2025. That isn’t the most damning statistic, as oversight hasn’t remotely kept pace. Of more than 750 IT executives and practitioners asked, the average business had almost 37 deployed AI agents, with less than half being monitored or secured appropriately.
The following guide walks you through what AI agent security means, why they break traditional security models, which risks matter the most to enterprises, and the best practices and frameworks to adopt to plug any weak links between an organization’s sensitive data and its users. Read on to learn more.
Why AI Agents Break Traditional Security Models
Enterprise security in the traditional sense has always relied on a few assumptions, i.e., software follows a predictable logic, identities belong to people, and any meaningful action will only occur after a human’s approval. AI agents break all three.
AI Agents Decide Own Path
Traditional application security relied on the assumption that code will follow a path the developer has defined in advance. All testing, review, and predictions have been made on this assumption. However, when an agent receives a goal, it isn’t a script in the traditional sense. It can choose which tools to call, in what order, and how to interpret both the results and the ways to achieve these results. All this means its behavior cannot be fully validated before its deployment.
Agents Are Identities with Human-Level Reach
Most identity and access management systems have been designed around employees and service accounts. Agents lie somewhere between the two. However, most organizations continue to treat agents as an extension of human users or as generic service accounts. Hence, agents end up inheriting far more access than the task requires, with actions harder to track back to an accountable owner.
Content Is Command
Data and instructions are kept separate in a conventional sense. An agent may read emails, documents, webpages, and tool outputs as natural language, with no way to know which information it has read must be followed. This gap is what makes prompt injection so dangerous. This is also why an attacker need not breach a network if they can plant instructions somewhere the agent will read them.
Agents Act at Machine Speed
Most security monitoring is tuned to human behavior, with all logic, sessions, and sequence of actions at human pace. However, an agent can query databases, call several APIs, and send external messages in seconds, across systems, leveraging different tools and teams.
Legitimate Access is an Attack Path
Most serious agent risks do not involve stolen credentials at all. The OWASP Top 10 For Agentic Applications highlights that the main risk isn’t agents having unauthorized access, but misusing the permissions they already have, without breaching their privileges.
Top AI Agent Security Risks
The OWASP Top 10 For Agentic Applications provides security teams the necessary shared vocabulary for threats specific to agents. The most critical of these threats are mapped out below.
Prompt Injection & Goal Hacking
Prompt injection is a common technique used by malicious actors where attackers hide instructions in content an agent is going to process, such as a support ticket, a webpage, or a shared document. As these agents interpret natural language, they will likely interpret these as legitimate instructions.
Whereas in a simple chatbot, this can result in a bad answer, with an agent this can lead to bad actions such as forwarding sensitive files, approving transactions, and changing internal documentation and records.
Agents rely on tools to carry out actions. This includes APIs, databases, file systems, email, code interpreters, and SaaS connectors. Tool misuse occurs when an agent uses a legitimate tool in an unsafe and unapproved way, whether by being manipulated or given more privilege than it needed.
This can be harder to detect because each action looks authorized. Catching instances of tool misuse involves knowing whether an action fits the agent’s intended purpose, and not just whether the action itself was allowed or not.
Identity & Privilege Abuse
Agents almost always operate through either borrowed or shared credentials. These can be a user’s own OAuth token, a team’s service account, or a long-lived API key stored in the original configuration files. When an attacker impersonating an agent gains access to everything the agent has access to, they gain access to everything that identity had access to, including delegation chains between different agents.
This problem is made exponentially worse by privilege creep as agents are given broad access during the development phase to ensure seamless working. These permissions often carry forward into production. With no separate identity for each agent, it can become next to impossible to track an action back to a specific agent or its accountable owner after an incident.
Memory & Context Poisoning
Most agents keep memory enabled across sessions. This allows them to draw on shared knowledge bases and retrieval systems. If an attacker were to write false or malicious information into those memory sources, the agent would continue to act on it repeatedly, long after the initial attack.
As opposed to prompt injection, which may occur once, poisoned memory follows a repeated cycle, continuing to spread to other users and agents that rely on the same source. This can become particularly troublesome in enterprise retrieval systems, where a single tampered source in the knowledge base can influence thousands of agent decisions.
Agentic Supply Chain Compromise
Agents depend on a growing ecosystem of third-party components such as models, frameworks, plugins, skills, and the MCP servers that connect agents to external tools. However, each component comes with its own vulnerabilities or malicious behavior.
As each of these components often runs with the agent’s full permissions, a compromised plugin or connector can effectively become an insider threat. Hence, agent tooling must be treated as any traditional assessment of software dependencies, with close examination of where the components are from, locking versions, and continuously watching for any unexpected changes in behavior.
Why AI Agent Security Is a Data Security Problem
Most discussions of AI agent security focus on the AI agent itself. This includes its prompts, model, and guardrails, with the risk being defined ultimately by what assets it can reach. While an agent with no access to sensitive data may be a nuisance if it goes haywire, an agent with the appropriate permissions is a breach waiting to happen.
Agent Turn Hidden Overexposure into Active Exposure
Oversharing has long been an issue for enterprises. Files are left with broad permissions, old datasets, and sensitive data that no one has cleaned up and which continues to be part of collaboration tools. Obscurity has contributed to this problem as people simply forget about their existence. However, agents remove that buffer as they search, retrieve, and summarize information from across all systems they’re connected to.
Every Agent Interaction Creates New Data Flows
Sensitive data flows through prompts, retrieved context, tool calls, agent memory, outputs, and handoffs between agents. Each represents a path by which regulated data can potentially fall outside its intended boundary. Most traditional DLP methods have been built to watch files and network traffic, not prompt exchanges between machines.
Data Agents’ Consumption Is What They Become
Agents do not only read data, but they also act on it. Hence, any manipulated documents, knowledge bases, or tampered memories can steer an agent towards performing harmful actions without anyone messing with the actual code. As a result, it is critical to secure the integrity and origin of the data an agent is set to consume just as much as its confidentiality.
Compliance Obligations Follow the Data, Not the Agent
Regulations such as the GDPR, HIPAA, and PCI DSS apply to all sensitive data regardless of whether a person or agent has processed it. If an agent moves personal data across regions, leaves it exposed to unauthorized users, or uses it in a manner not approved by the organization, the liability will fall onto the organization. Hence, demonstrating compliance with the organizational obligations in this regard requires extensive audit trails that document every agent action and its reasoning for those actions.
Security Spillover Effects
To secure an agent, it is vital to have the data infrastructure figured out. This means knowing what sensitive data exists across this infrastructure, where it exists, what identities can access it, and how it’s being used. Organizations that can effectively produce these answers can limit agent access precisely and eliminate any misuse with the right context.
AI Agent Security Best Practices
These practices follow an agent’s lifecycle. This goes from discovery to daily operations and applies to agents built in-house, embedded in SaaS platforms, or supplied by third parties.
Discovery & Inventory Each Agent
Security agents cannot possibly be expected to protect agents they do not know about. Hence, organizations must build a complete inventory, with information on agents built internally, agents embedded in SaaS applications, copilots, and third-party tools connected via OAuth grants or API keys.
Against each agent, the organization must have documented its purpose, owner, model, all connected tools, and all data access privileges. This inventory must be maintained as regularly and thoroughly as possible in tandem with the pace with which the organization adds and modifies its agents.
Assign Every Agent a Unique Identity & Owner
Each agent must be given its own non-human identity, instead of relying entirely on the user’s credentials or sharing a service account. Such separate identities allow for permissions to be set distinctly for each agent, every agent being accountable for their own actions, and the possibility of revoking an agent’s access without disrupting others.
Every identity will need an accountable human owner who approves their access and responds in case anything goes wrong.
Enforce PoLP
By leveraging the principle of least privilege (PoLP), each agent can only be assigned permissions appropriate to their specific task requirements. This means read-only access where it doesn’t need to write, access limited to specific datasets rather than entire repositories, and only to the tools it actually needs.
OWASP then extends this principle to the idea of least agency, which requires limiting not just what an agent can access but how much freedom it has to act on its own.
Any content the agent can read may carry malicious instructions, including through emails, documents, webpages, tool outputs, and messages from other agents. Filters must be in place to detect prompt injection attempts, with trusted instructions separated from untrusted content wherever the system design allows.
Moreover, outputs must be checked as well. All agent responses must be screened, with planned actions for sensitive data, policy violations, and possible signs of violations before they can be executed.
Every tool, plugin, skill, and MCP server must be treated as a software dependency with access to the enterprise environment. All components connected to the agents must be approved through a review process, with verification of their origins and locked versions so updated versions do not introduce unreviewed changes.
A list of approved tools should be maintained, with agents being blocked from connecting to anything not on it. Moreover, the approved components must be monitored at all times.
How Securiti Helps
Most organizations still struggle with gaining and maintaining a clear and current picture of their sensitive data. This issue cannot be resolved by limiting an agent’s access. Moreover, PoLP and documentation cannot be maintained without knowing what sensitive data exists, where it exists, and who has access to it.
Securiti, now a Veeam company, has the Data Security Posture Management (DSPM) solution that provides a critical dataAI security foundation. It not only protects data across public clouds, private clouds, and SaaS environments, but does so while discovering and classifying sensitive data so teams know what a data source contains before connecting an agent to it.
Organizations can leverage its access intelligence and least-privilege capabilities to visualize which identities can reach which data, so teams can tighten access before an agent inherits it. Moreover, continuous posture management scans cloud and SaaS configurations and flags where sensitive or regulated data could be at risk, catching overexposed data before an agent can surface it.
Each of these controls can be extended to AI workflows as well, thus enabling compliance automation, automated remediation, and breach management.
Request a demo today and learn more about how Securiti, now a Veeam company, can help your organization maximize the benefits of using AI agents.
FAQs About AI Agent Security
Here are the most commonly asked questions about AI agent security:
