.png){kind=small}
AI agents are changing the AI security conversation.
For the first wave of generative AI adoption, security teams were largely concerned with what employees were putting into AI tools: Are users uploading sensitive data to ChatGPT? Which AI applications are being used? Is confidential information leaving the organization?
Those questions still matter. But AI agents introduce a much bigger one:
What can AI access, and what actions can it take?
Unlike a traditional chatbot that primarily generates a response, AI agents can interact with tools, retrieve enterprise data, connect to applications, invoke APIs, maintain memory, execute multi-step workflows, and take actions on behalf of users.
Protecting an AI agent isn't simply a matter of protecting the underlying model or filtering prompts. Security teams also need to think about the identity the agent operates under, the permissions it has, the data it can reach, the tools it can call, the instructions it receives, and the actions it is authorized to perform.
This is AI agent security.
And as organizations deploy more autonomous AI across the enterprise, agent security is quickly becoming an important layer of a much larger AI security strategy.
What Is AI Agent Security?
AI agent security is the practice of protecting autonomous or semi-autonomous AI systems from attacks, misuse, unauthorized access, data exposure, and unintended actions as they interact with data, applications, tools, and other systems.
AI agents are typically powered by large language models (LLMs), but they extend beyond the model itself. An agent may be able to:
- Retrieve documents from Google Drive
- Search Slack conversations
- Query databases
- Access CRM records
- Interact with SaaS applications
- Call APIs and other tools
- Connect to Model Context Protocol (MCP) servers
- Maintain information in memory
- Execute workflows
- Take actions on behalf of a user
This ability to act is what makes agent security different.
AI agents are capable of reasoning, planning, using tools, maintaining memory, and taking actions toward goals. Those capabilities introduce risks beyond traditional LLM prompt injection, including tool abuse, privilege escalation, data exfiltration, and memory poisoning.
The security boundary therefore extends far beyond the AI model.
How Do AI Agents Work?
The exact architecture varies, but an enterprise AI agent generally combines several components.
At the center is the AI model, which provides reasoning and language capabilities.
Around that model sits an agent or orchestration layer that determines how the agent should pursue a goal. The agent may break a task into steps, determine which tools to use, retrieve additional information, evaluate results, and decide what to do next.
The agent can then interact with an ecosystem of enterprise resources, including:
Data sources → Applications → APIs → Tools → MCP servers → Identities and credentials → Memory → Other agents
Consider a simple request:
"Review our open sales opportunities, identify accounts that haven't received a follow-up this week, and draft a message for each account."
A traditional chatbot might explain how to perform the task.
An AI agent could potentially connect to the CRM, retrieve opportunities, analyze account activity, determine which accounts meet the criteria, access additional customer information, generate personalized messages, and – if authorized – actually send them out.
The productivity difference is huge. So is the security difference.
The agent now sits between human intent and enterprise action. Every system it touches, permission it inherits, piece of data it retrieves, and instruction it consumes becomes part of the security equation.
Why Are AI Agents a Security Risk?
AI agents combine three characteristics that security teams traditionally try to control very carefully:
Access, privilege, and automation.
Giving software access to sensitive resources isn't new. Neither is automated software taking actions.
What changes with agentic AI is that an LLM may dynamically determine how to accomplish a task, which information it needs, and which available tools it should invoke along the way.
The ways an agent may choose to go about a task and complete its objective isn’t always ethical. It doesn’t understand nuance or use human emotion to make a decision. It doesn’t always understand the implications of doing something.
It simply finds the best way to complete its objective, and goes for it. Whatever it takes to get it done, it does.
That creates several overlapping attack surfaces.
The AI Agent Attack Surface
Understanding AI agent security starts with understanding where an agent can be influenced, compromised, or given too much access.
1. Prompt Injection and Instruction Hijacking
Prompt injection occurs when malicious or manipulated instructions cause an AI system to behave in an unintended way.
A direct prompt injection comes directly from the user or attacker.
An attacker might attempt to override the agent's existing instructions, circumvent policies, extract hidden information, or convince the agent to perform an unauthorized task.
This becomes particularly concerning when an agent has access to tools or sensitive systems. Manipulating a chatbot's response is one thing. Manipulating an agent that can execute actions is another.
2. Indirect Prompt Injection
Agents don't receive instructions only from users. They also consume information.
An agent might read an email, webpage, document, knowledge base, support ticket, database entry, or tool response as part of completing a task.
That creates the possibility of indirect prompt injection.
Instead of attacking the agent through the prompt box, an attacker embeds malicious instructions inside content the agent later encounters.
Imagine an agent asked to summarize documents from an external source. One document contains hidden instructions telling the agent to retrieve confidential information and send it elsewhere.
The user never provided the malicious instruction, the content did. And, as mentioned before, the agent doesn’t always understand this nuance. It sees instructions, and it acts.
Google has identified indirect prompt injection as a major security concern for agentic systems because malicious instructions can be embedded in external information that an AI system retrieves while completing a legitimate task.
3. Excessive Permissions
An agent can only be as constrained as the permissions surrounding it.
If an AI agent can access far more information than it actually needs, a compromised or manipulated agent may inherit that same reach.
Consider an agent that only needs access to one customer database, but receives broad access to CRM records, cloud storage, internal communications, and administrative functionality.
That creates unnecessary blast radius.
The principle of least privilege therefore becomes fundamental to AI agent security: agents should receive only the access required to perform their intended tasks.
NIST has similarly highlighted identification and authorization as core considerations for AI agents because agents may access diverse datasets, tools, and applications.
4. Sensitive Data Exposure
Agents can interact with enormous volumes of enterprise information.
That may include:
- Customer information
- Employee data
- Financial documents
- Source code
- Intellectual property
- Credentials
- Legal documents
- Internal communications
- Regulated data
The security problem isn't limited to whether sensitive data is entered into a prompt.
Security teams also need to understand what sensitive information an agent can retrieve because of the access it already possesses.
This distinction becomes increasingly important as organizations connect AI directly to SaaS applications and enterprise repositories.
An AI agent doesn't necessarily need someone to upload a confidential file if it can retrieve that file itself.
5. Tool Misuse
Tools transform an agent from something that generates information into something capable of taking action.
An agent might have tools for:
- Sending messages
- Modifying files
- Querying databases
- Updating CRM records
- Running code
- Creating tickets
- Initiating workflows
- Changing configurations
The tool itself may be legitimate. The problem is how, when, and under what authority the agent uses it.
A manipulated agent could invoke a legitimate tool for an illegitimate purpose. An incorrectly configured agent could choose the wrong tool. Or, an agent with excessive privileges could perform an action beyond what the user intended.
6. MCP Security Risks
The Model Context Protocol (MCP) is becoming an important part of the agent ecosystem.
MCP provides a standardized way for AI applications and agents to interact with external tools, data sources, and systems.
Instead of building a completely custom integration every time an agent needs access to another resource, MCP can provide a common interface.
That makes agents considerably more useful. It also expands their connectivity.
Every MCP server, tool, and resource connected to an agent potentially becomes another component that needs to be trusted and governed.
Security teams should therefore consider:
- Which MCP servers are connected?
- Who authorized them?
- What tools do they expose?
- What information can they retrieve?
- What permissions do they possess?
- What information can flow back to the agent?
- Can a compromised tool influence the agent?
MCP itself isn't inherently insecure, but connecting agents to more resources means organizations need to understand and control the trust relationships those connections create.
7. Agent Memory and Memory Poisoning
Many agents maintain context across interactions.
Memory can make agents far more useful, for example: an agent may remember user preferences, previous tasks, business context, or information required for long-running workflows.
But, persistent memory also creates another security surface.
If malicious or inaccurate information becomes embedded in memory, it could influence future decisions long after the original interaction ends.
This is commonly described as memory poisoning.
Security teams therefore need to consider what information agents retain, how long it persists, who can influence it, and whether sensitive information should be stored there at all.
8. Agentic Supply Chain Risk
Agents rarely operate alone.
Their ecosystem may include third-party models, frameworks, APIs, plugins, MCP servers, skills, tools, libraries, and integrations.
A compromised component can therefore introduce risk into an otherwise legitimate agent workflow.
What Is AI Agent Observability?
Before organizations can govern AI agents, they need to know what those agents are doing.
AI agent observability is the ability to understand an agent's behavior and interactions across its environment.
That can include visibility into:
- Which agents exist
- Who or what owns them
- Which applications they access
- Which tools they invoke
- Which MCP servers they use
- What permissions they possess
- What data they access
- What actions they perform
- Whether their behavior changes over time
Traditional application monitoring asks whether software is working. Agent observability increasingly needs to answer a different question:
What is the agent actually doing?
This distinction matters because an agent can be technically functioning exactly as designed while still performing an action that creates security risk.
Are AI Agents Non-Human Identities?
AI agents increasingly intersect with another major cybersecurity challenge: non-human identities (NHIs).
A non-human identity is an identity used by software or machines rather than a person. Examples can include service accounts, API keys, workloads, automation accounts, bots, and other machine identities.
When an AI agent authenticates to enterprise systems, receives permissions, and acts independently, it may effectively operate as a non-human identity. But the terms aren't interchangeable.
An AI agent may operate as a non-human identity, but not every non-human identity is an AI agent.
NHI security focuses heavily on questions such as:
- What machine identities exist?
- Who owns them?
- How are they authenticated?
- What permissions do they possess?
- What resources can they access?
- Are their credentials properly managed?
- Is their behavior expected?
AI agent security encompasses those identity questions but also extends into prompts, instructions, tools, MCP, memory, autonomous decision-making, and agent workflows.
The overlap is significant enough that identity is becoming foundational to agentic security.
AI Agent Security vs. Other Types of AI Security
One reason AI security can feel confusing is that several distinct security problems are often grouped under the same label.
They overlap, but they aren't identical.
AI Agent Security vs. Model Security
Model security primarily focuses on protecting the AI model and its behavior. That can include model manipulation, jailbreak resistance, adversarial inputs, model theft, training-data poisoning, and other model-level concerns.
Agent security moves further outward. Once a model can use tools, authenticate to applications, retrieve enterprise data, maintain memory, and perform actions, the surrounding infrastructure becomes part of the attack surface.
An organization could have a well-protected model and still have an agent with excessive permissions. Likewise, an agent could use a secure model while connecting to a malicious tool or retrieving compromised content.
Securing the model is important. But securing the model does not automatically secure everything the model can reach.
AI Agent Security vs. NHI Security
The difference between agent security and NHI security largely comes down to scope. NHI security focuses on the identity and authorization layer.
Agent security includes identity but extends into the agent's reasoning, tools, instructions, memory, workflow, and actions. For security teams, the two disciplines increasingly need to work together.
An organization needs to understand not only what an agent is, but also whose authority it is using and what that authority allows it to do.
AI Agent Security vs. Browser Security
Browser security addresses another piece of the AI attack surface.
Employees access ChatGPT, Gemini, Claude, Copilot, and countless other AI applications through the browser. Browser extensions can also interact with enterprise applications and sensitive information.
This creates risks around:
- Shadow AI
- Unsanctioned AI applications
- Risky browser extensions
- Sensitive information entered into AI tools
- Malicious websites
- Phishing
- Browser-based data leakage
- Agentic browser activity
Agentic browsing makes this intersection even more important.
Google has identified indirect prompt injection as a primary new threat for agentic browsers because agents can encounter malicious instructions embedded in webpages, iframe content, or user-generated content and potentially take unwanted actions.
Browser security and agent security therefore address different—but increasingly interconnected – parts of the AI ecosystem.
How Can Organizations Secure AI Agents?
There is no single control that solves AI agent security. Organizations should instead apply security controls throughout the agent lifecycle and use this checklist to decide what they need to do next.
AI Security Requires a Layered Approach
The phrase "AI security" makes the challenge sound like a single problem. It isn't. AI now touches models, applications, browsers, identities, SaaS platforms, enterprise data, third-party tools, APIs, and autonomous agents.
Consider a few scenarios.
- An organization could successfully protect an agent against prompt injection while allowing that agent excessive access to sensitive Google Drive data.
- It could perfectly govern an agent's identity while employees upload proprietary information into unsanctioned AI applications.
- It could discover every AI application employees use while having little visibility into autonomous agents accessing SaaS data through APIs.
- It could secure an AI model while leaving the enterprise data that model can retrieve broadly overshared.
Each problem exists at a different layer. That's why organizations should think about AI security as a layered security architecture rather than a single product category.
The model needs protection. The agent needs guardrails. The identity needs governance. The browser needs controls. And the underlying enterprise data needs to be protected.
Ultimately, the question isn't simply:
"Are we using AI securely?"
Security teams need to ask a series of more specific questions:
- Which AI is being used?
- Which agents are operating?
- What identities are they using?
- What tools and applications are they connected to?
- What data can they access?
- And what actions are they allowed to take?
Where DoControl + Spin.AI Fit Into AI Security?
DoControl's view of AI security starts with a simple reality:
AI can only be as secure as the data and access surrounding it.
As AI becomes embedded across SaaS environments, organizations need visibility not only into human users, but also the non-human identities and agentic activity interacting with enterprise resources.
DoControl helps organizations address the data, access, and identity layers of this problem through SaaS Data Loss Prevention (DLP), Data Access Governance, SaaS application visibility, access controls, automated remediation, and visibility and alerting around non-human identities and agentic activity.
The goal is to help security teams answer a critical question:
What can AI access?
If sensitive data is already overshared, accessible to unnecessary identities, exposed externally, or available through overly permissive applications and integrations, AI can amplify an existing access problem.
Securing AI therefore requires securing the data underneath it.
Following DoControl's acquisition by Spin.AI, that approach can be complemented by another increasingly important control plane: the browser.
Spin.AI's browser security capabilities help organizations address browser-based risks surrounding SaaS and AI application usage, including unsanctioned applications and risky browser extensions.
Together, the two perspectives reinforce a broader principle:
AI security isn't one category. It's an ecosystem.
Organizations need controls around how AI enters and interacts with the enterprise, which identities and agents are operating, what applications they connect to, and what enterprise data they can ultimately reach.
Because as AI becomes more autonomous, the security question is no longer simply whether an organization is using AI.
It's whether the organization still controls what AI can see, what AI can access, and what AI can do.
Frequently Asked Questions About AI Agent Security
What is AI agent security?
AI agent security is the practice of protecting autonomous or semi-autonomous AI agents as they interact with enterprise data, applications, tools, APIs, and other systems. It includes protection against risks such as prompt injection, tool misuse, excessive permissions, sensitive data exposure, identity abuse, memory poisoning, and unintended agent actions.
What are the biggest AI agent security risks?
Common AI agent security risks include direct and indirect prompt injection, excessive permissions, tool misuse, sensitive data exposure, identity and privilege abuse, malicious or compromised MCP connections, memory poisoning, agentic supply-chain attacks, and unauthorized actions.
What is the difference between AI security and AI agent security?
AI security is the broader discipline of protecting AI models, applications, infrastructure, data, identities, and usage. AI agent security is one part of that discipline focused specifically on autonomous systems that can use tools, access information, and take actions.
Are AI agents non-human identities?
AI agents can operate as non-human identities when they authenticate to systems and receive permissions to access resources or perform actions. However, not every NHI is an AI agent. Traditional service accounts, workloads, API keys, and automation can also represent non-human identities.
What is MCP security?
MCP security focuses on protecting interactions between AI applications or agents and the external tools, resources, and systems made available through the Model Context Protocol. Security considerations include MCP server trust, permissions, tool integrity, sensitive data access, malicious instructions, and unauthorized tool use.
How do you secure AI agents?
Organizations can reduce AI agent risk by discovering agents and their connections, enforcing least privilege, governing agent identities, protecting sensitive data, securing tools and MCP servers, monitoring agent activity, testing against agent-specific attacks, and requiring human approval for appropriate high-risk actions.
Why isn't AI agent security enough on its own?
AI agents are only one part of the enterprise AI ecosystem. Organizations may also need controls around models, AI applications, non-human identities, browsers, SaaS access, and sensitive enterprise data. A secure agent can still create risk if the data, identity, application, or environment surrounding it is poorly governed.
.png)