AI Agent Security Risks and the Controls Companies Need

AI agent security risks begin when a model can do more than generate an answer. Give an agent access to email, cloud systems, customer records, code, payment tools, or internal APIs, and a manipulated instruction can become a real action.

The central lesson is simple: secure the agent as a system, not only as a model. That means controlling its identity, permissions, tools, memory, data, network access, and approval gates. Model safeguards still matter, but they cannot replace the controls surrounding the model.

If you are new to the topic, AI Agents Explained covers how these systems plan and act, while AI Agents vs. Chatbots explains why action-enabled agents create a different risk profile from conversational software.

Why It Matters

A traditional read-only chatbot may return a wrong or unsafe answer. An action-enabled agent can also call a tool, change a record, expose data, send a message, run code, or trigger another workflow. The practical risk depends on what the agent can reach and what it is allowed to do.

Vercel's official security bulletin illustrates the point without being an example of an agent obeying a malicious prompt. Vercel said an incident began with the compromise of Context.ai, a third-party AI tool whose Google Workspace OAuth application had been authorized by an employee. The compromised OAuth access became a route into the employee's Workspace account and some internal Vercel systems. The attackers accessed environment variables that were not marked Sensitive; Vercel said values stored as Sensitive were not affected.

This was primarily a third-party supply-chain, OAuth, and identity failure. It shows why an AI tool should receive no more access than its task requires and why companies need a fast way to revoke a connected application's access.

Why AI Agent Security Differs From Chatbot Security

An AI agent usually combines a model with instructions, tools, credentials, state or memory, and an orchestration layer. Each component adds an attack surface. A model may interpret untrusted content as instructions. A tool may accept an unsafe argument. A credential may be broader or longer-lived than necessary. Memory may preserve poisoned information. An orchestrator may continue a flawed sequence across several steps.

That does not mean every agent is equally dangerous. An agent limited to summarizing public information presents a very different risk from one that can issue refunds or modify production systems. The useful question is not simply, "Is this an AI agent?" It is, "Which data, tools, identities, and destinations can this agent use, and what happens if its judgment is wrong?"

For a plain-English explanation of the underlying components, see What Is an AI Agent?. For systems in which several agents exchange tasks or results, Multi-Agent Systems Explained covers the added coordination layer.

Four High-Priority Risks From the OWASP Agentic Top 10

The OWASP Top 10 for Agentic Applications 2026 provides a useful framework for autonomous and action-enabled systems. The first four categories capture many of the risks companies encounter when agents use tools and data, although OWASP's complete list contains ten categories.

1. Agent Goal Hijacking

An attacker places instructions inside content the agent is expected to process, such as a webpage, document, support ticket, email, log entry, or tool response. The model may treat that content as part of its task and change its behavior without an obvious technical exploit.

Oasis Security's Claudy Day research demonstrated a chain of three Claude.ai vulnerabilities that combined invisible prompt injection with conversation-history exfiltration in a default session. Oasis reported that Anthropic fixed the prompt-injection issue and was addressing the remaining issues at the time of the update. This was a responsible security disclosure, not evidence of a widespread attack.

2. Tool Misuse and Unexpected Code Execution

An agent may have legitimate access to a tool while receiving malicious or misleading input. The danger is not only that the model produces a bad answer; it may pass dangerous parameters to a tool, run code, expose a secret, or modify a system.

Tenet Security's Agentjacking research showed how fake instructions placed in public Sentry error reports could influence coding agents that consumed the telemetry. Tenet reported an 85% success rate in controlled testing across several coding agents and identified 2,388 organizations with exposed, injectable Sentry DSNs. That figure describes potential exposure, not 2,388 confirmed compromises. Tenet's description of Sentry's response should also be understood as Tenet's account, not an independent finding.

3. Identity and Privilege Abuse

Agents often act through service accounts, OAuth grants, API keys, or employee credentials. Shared identities make it difficult to determine which agent performed an action, while overbroad identities allow the agent to reach systems unrelated to its job.

The Vercel case belongs here because compromised third-party OAuth access became a path into internal systems. The control objective is to give every agent or agent service a distinct identity, a named owner, narrowly scoped permissions, and an expiration or revocation path.

4. Agentic Supply-Chain Vulnerabilities

Agents depend on models, packages, plugins, skills, tool servers, connectors, and external content. A weakness or malicious instruction in any of those components can shape what the agent sees and does.

Trend Micro's MCP scan found 1,467 exposed Model Context Protocol servers in its latest scan, up from 492 in its earlier scan. Those numbers describe the servers Trend Micro discovered, not every MCP server worldwide. Snyk's ToxicSkills study examined 3,984 skills from ClawHub and skills.sh and found that 36.82% had at least one detected security issue; 13.4% had at least one critical-level issue. These are findings from defined datasets, not universal rates for all agent skills.

OWASP's remaining categories address unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents. Together they show why agent security requires defense in depth rather than one universal safeguard.

Where AI Agent Risks Enter the System

• During design and setup, teams may grant broad access because it is faster than defining the minimum permissions for each task.
• During integration, a connector, skill, MCP server, package, or OAuth application may introduce excessive trust or a vulnerable dependency.
• At runtime, untrusted content may be interpreted as instructions, or a valid tool may receive an unsafe argument.
• In memory and state, poisoned or outdated information may influence later actions, retries, and decisions.
• In multi-agent workflows, one agent's error or compromised output may be accepted by another agent and spread through the system.

The Governance Gap Behind the Risk

Gravitee's follow-up survey of 750 senior technology leaders found that 54% reported a confirmed or suspected AI-agent security or data-privacy incident in the previous year, including 34.9% who reported a confirmed incident. Mean monitoring coverage was about 52%, and only 19.7% said all agents were fully secured and governed before launch.

Those figures are vendor-sponsored, self-reported survey evidence, not a measured incident rate for every company. They are still useful as a signal that adoption and governance are moving at different speeds.

IBM's Cost of a Data Breach findings provide broader shadow-AI context. Organizations with high levels of shadow AI had average breach costs $670,000 higher than organizations with low or no shadow AI. Customer personally identifiable information was compromised in 65% of shadow-AI incidents, compared with 53% across the overall breach sample. The comparison is about shadow AI generally, not AI agents alone.

Controls That Reduce AI Agent Security Risks

No single control covers prompt injection, identity abuse, malicious dependencies, memory poisoning, and unsafe tool use. Databricks' Agentic AI Security Framework identifies 35 agentic risks and six mitigation groups, reinforcing the need for layered controls.

Inventory Every Agent and Assign an Owner

Maintain a current inventory of agents, models, tools, data sources, credentials, MCP servers, skills, and external destinations. Assign a business owner and a technical owner who can approve access, review behavior, and stop the agent.

Use Distinct Identities and Least Privilege

Give each agent or agent service its own identity. Avoid shared employee accounts and reusable fleet-wide keys. Scope credentials to the exact tools, records, and actions required, make them short-lived where possible, and review access regularly.

Treat External Content as Untrusted

Separate user goals and system policies from webpages, documents, emails, logs, and tool output. Sanitize and label external content, detect instruction-like payloads, and prevent retrieved text from silently changing the agent's permissions or operating rules.

Restrict Tools, Arguments, and Network Destinations

Use tool allowlists, schema validation, transaction limits, and destination allowlists. Block unnecessary network egress. A model should not be able to choose an arbitrary endpoint, command, or database operation simply because a tool interface makes it possible.

Validate Memory and Dependencies

Review what enters long-term memory, attach provenance and expiration rules, and give users a way to inspect or delete stored data. Verify packages, agent skills, plugins, and MCP servers before use; pin versions where practical and monitor for changes.

Add Human Approval for High-Impact Actions

Require an authorized person to approve actions such as sending money, changing production systems, deleting data, granting access, or communicating externally on the company's behalf. Approval should occur before execution and show the proposed action, target, and supporting evidence.

Log Actions and Build an Emergency Stop

Record prompts, tool calls, arguments, results, approvals, identity use, and policy decisions in a tamper-resistant audit trail, subject to privacy rules. Alert on unusual access or repeated failures. Maintain a tested method to pause the agent, revoke credentials, and isolate affected integrations quickly.

Test the Whole Workflow

Evaluate the model and the surrounding system. Test indirect prompt injection, malicious tool output, excessive permissions, memory poisoning, dependency changes, data leakage, and failure recovery before launch and after material updates.

A Practical Pre-Deployment Check

• Can the agent access anything unrelated to its defined task?
• Does it have a distinct identity, named owner, and documented revocation process?
• Can untrusted content influence tool calls, memory, or approval logic?
• Are tools, arguments, spending limits, and network destinations constrained?
• Do high-impact actions stop for informed human approval?
• Are all material actions logged and monitored?
• Has the full workflow been tested against realistic adversarial inputs?

Common Misconceptions

Sandboxing Alone Is Enough

Sandboxing can contain code execution, but it does not by itself prevent data leakage, unsafe API calls, memory poisoning, or misuse of an approved external service. It is one layer of a larger design.

A Secure Model Guarantees a Secure Agent

The deployment can still fail through OAuth, credentials, tool schemas, dependencies, memory, permissions, or business logic. The model is only one component of the security boundary.

Only Large Companies Need These Controls

The relevant risks depend on the agent's data, tools, permissions, and exposure—not simply the size of the company. A small business agent with access to customer records or payments can still create meaningful harm.

The Bottom Line

AI agent security is the discipline of limiting what an agent can see, decide, and do—and containing the consequences when it makes the wrong decision. Least privilege is essential, but it is not sufficient on its own. Secure deployments combine identity controls, trusted dependencies, untrusted-content handling, tool restrictions, memory safeguards, monitoring, testing, approval gates, and rapid revocation.

Start with the systems and actions that matter most. The more authority an agent receives, the stronger its evidence, approvals, monitoring, and recovery controls should become.

Explore more reporting and explainers in AI & Automation. Get the Morning Glance briefing—AI-agent context without the noise.

Frequently Asked Questions

What are the biggest AI agent security risks?

Major risks include goal hijacking through untrusted content, tool misuse, identity and privilege abuse, malicious or vulnerable dependencies, unexpected code execution, memory poisoning, insecure communication between agents, and cascading failures.

How is AI agent security different from regular cybersecurity?

It extends regular cybersecurity to a system that interprets natural-language content, selects tools, and may take multi-step actions. Traditional identity, access, application, data, and network controls still apply, but they must also account for model behavior and untrusted instructions.

What is the single best control for an AI agent?

There is no single sufficient control. Least privilege reduces impact, but prompt injection, malicious dependencies, unsafe tool arguments, and memory poisoning require additional defenses. Use layered controls matched to the agent's actual access and actions.

Do simple AI agents need the same controls as high-risk agents?

No. Controls should be proportional to the data, tools, permissions, and consequences involved. A public-information research agent needs fewer controls than an agent that can send payments, change production systems, or access regulated data.

Can human approval make an AI agent safe?

Human approval can reduce risk for high-impact actions, but only if the reviewer sees accurate context and has time and authority to stop the action. It should support—not replace—least privilege, tool restrictions, logging, testing, and emergency revocation.