AI Agent Security: Risks, Controls, and a Practical Checklist

A support agent issues a refund it was never supposed to approve, and a coding agent reads a GitHub issue with hidden instructions and pushes a private repo somewhere public. Both used the credentials you gave them, did exactly what they decided the task required, and were never "hacked," which leaves your customer (or your auditor) asking one question: what was controlling them?

With AI agents processing so much information, and often making decisions, security is becoming a top concern for buyers when choosing which companies to work with. AI agent security involves understanding and controlling what an autonomous agent can read, decide, and do, and being able to prove those controls.

The way I like to think about agentic security is to approach it in the same way you would a human teammate: control what it can access, oversee decisions that carry risk, and keep evidence your approach is working. Here's what you need to know about AI agent security risks.

Why AI Agents Are a Different Security Challenge

An AI agent is an autonomous worker that reads data, makes a judgment on that data, and takes an action based on that judgment, so you have to secure all three stages, not the model alone. That ingest → judgment → action loop is the whole frame for the rest of this guide, because risk lives at each stage.

Think about how much we've built around a human worker to manage that same loop:

• Access controls over what they can see.
• Training and oversight for the judgments they make.
• Approvals and audit trails for the actions they take.

We've spent decades assembling that ecosystem. Agentic workflows ask you to hand the same loop to software that runs faster, at a larger scale, and without any of that scaffolding by default.

The model is one part of the attack surface. The larger part is everything downstream of it: the data the agent can reach, the tools you've connected, and the actions you've authorized. A large language model (LLM) that can only draft text is a contained risk. The same model wired to your production database, your payment system, and your email is a very different one.

That's why autonomy is the thing that amplifies risk. The same flaw, say an agent that can be talked into running an unintended command, is minor on a read-only reporting agent and systemic on one that can move money or delete records. Identical weakness, wildly different consequences, depending entirely on what the agent is allowed to touch and do.

Two versions of this problem are now landing on every security team at once:

1. The AI tools your employees adopt internally
2. The AI and agentic features you build into your own product.

This guide is about securing the agentic side of both. And it isn't a distant concern. Gartner expects at least 15% of day-to-day work decisions to be made autonomously through agentic AI by 2028, up from essentially none in 2024.

The assurances buyers have always relied on, like a SOC 2 report, were built for systems that behave predictably. An agent that reasons and acts on its own needs a different set of controls, plus different evidence that those controls exist and work.

What Are the Main AI Agent Security Risks Today?

The Open Worldwide Application Security Project (OWASP) published its Top 10 for Agentic Applications in December 2025, and many still hold up as the main agentic security risks today:

• Prompt injection: slipping hidden instructions into the content the agent reads so it follows them
• Agent goal hijack: redirecting the agent's objective mid-task
• Tool misuse: getting the agent to abuse tools it's legitimately allowed to use
• Identity and privilege abuse: exploiting an agent's over-broad, standing permissions
• Memory and context poisoning: tampering with what the agent stores so it acts wrongly later
• Agentic supply-chain risk: malicious third-party tools and connectors the agent trusts

When agents first became prominent, prompt injection was the first risk people became aware of. As teams added guardrails against it, attackers moved to other areas where they could cause harm, like identity, memory, and the tools agents use.

To understand the risk, I generally look at it across the agent's three stages (the ingest → judgment → action loop):

Risks at ingest

This covers what the agent reads and the first risk we mentioned above, prompt injection. It tends to happen in one of two ways:

1. Indirect prompt injection: an attack where an agent reads content from an external source (a web page, a document, an email, a support ticket) that carries instructions hidden inside it, then follows those instructions as if you had given them.
2. Direct prompt injection: a user typing a malicious instruction into the chat.

Indirect injection is usually the bigger problem for agents, because an agent can pull in outside content on its own, so hidden instructions can hijack it without anyone typing a thing. OWASP also notes there's no fool-proof way to prevent prompt injection, so the goal is to limit the damage it can do.

Risks at judgment

Judgment is how an agent decides what to do. This is where goal hijack and memory poisoning sit, because both corrupt the agent's decision-making rather than its inputs. Memory poisoning is the quieter of the two, as a tampered memory can sit unnoticed until the agent finally acts on it. Hallucinated or unsafe tool calls also originate here, when the agent decides to call a tool with bad parameters.

Risks at action

Here we're talking about what the agent does, and it's where risks do the most damage. The failures usually take one of these forms:

• Excessive agency: the agent has more functionality, permissions, or autonomy than its task requires, so an unexpected or manipulated decision turns into a damaging action.
• Tool misuse: the agent causes harm with entirely legitimate permissions. It was allowed to issue refunds, so it issued one it shouldn't have.
• Identity and privilege abuse: agents running as over-privileged non-human identities.
• Agentic supply-chain risk: malicious third-party tools and Model Context Protocol (MCP) servers you connect, where a malicious tool is a malicious instruction with a direct line to your agent.
• Denial of wallet: unbounded consumption, where a runaway loop burns through compute or spend with no ceiling.

None of these require a sophisticated attacker. Most require only an agent that was trusted with more than it needed.

How to Secure AI Agents: Controls That Reduce Risk

Securing an AI agent means minimizing the risk and opportunity for errors. The best way to do this is to put controls at each stage of the loop. Here's what that looks like at ingest, judgment, and action, plus the monitoring and testing that run across all three:

• Ingest controls: Treat everything the agent retrieves (tool outputs, fetched pages, documents) as untrusted input, the same way you'd treat raw user input to any application. Filter and validate it. And keep agents that read untrusted content away from your most sensitive data and highest-impact actions, so a poisoned input has nowhere valuable to go.
• Judgment controls: Apply least privilege and give each agent its own scoped identity. The common failure is letting an agent inherit a human's broad access or run on a shared service account, which backs its judgment with far more power than its task needs. Where important data is being viewed, edited, or used to make decisions, validate the agent's plan before it executes, not just its output after.
• Action controls: Put tool calls behind allowlists, validate their parameters, and rate-limit them. Also require human approval for sensitive or irreversible operations. Sandbox or isolate execution so a compromised agent can't reach the rest of your environment. And keep a kill switch, a way to stop an agent immediately when something goes wrong.

Often, the most effective lever you have is ensuring there's a human-in-the-loop at the points where key judgments or reviews are required. Requiring a person to verify the plan or sign off on the output before a costly action goes through is how companies keep ownership of risk they can't hand off.

When you employ a human, you own the liability for what they do, and you shouldn't fully outsource that liability to an agent. A human checkpoint pulls that familiar model of judgment and accountability back into an automated workflow.

Decide where to require a human by risk and potential impact if something were to go wrong at any stage of your agentic workflows. The larger and less reversible the action, the stronger the case for a human gate over an automated check.

Most teams aren't starting from scratch here. If you sell software to enterprises, you almost certainly already run a SOC 2 program, and that's the right baseline to build on. SOC 2 already covers access control, change management, monitoring, and incident response. Agentic workflows build on those same foundations, so the practical move is to layer AI-specific controls onto the SOC 2 you already run. I walked through how to do that in how to extend your SOC 2 for AI.

Where do additional frameworks fit?

The rise of AI has brought with it a number of AI-first and agentic frameworks. ISO 42001 formalizes your AI governance system, the EU AI Act sets legal obligations by risk tier, and AIUC-1 focuses on the technical implementation of agents.

Right now, most companies don't need all three, and as I mentioned above, the best first step is often layering AI-focused controls on top of SOC 2. Certifications like ISO 42001 or AIUC-1 generally make sense when:

• Buyers or contracts require third-party proof of your AI
• Your agents take consequential actions or make high-impact decisions
• AI is the core of your product

The Practical AI Agent Security Checklist

Looking for a starting point to judge whether an agent is safe to put into production? Use this to pressure-test any agent before and after it ships. It follows the same ingest → judgment → action loop, then adds the govern-and-prove layer. If you can't check an item, that's your starting point for any agentic security work.

Scope and identity

• Each agent has its own scoped identity, not a shared account or an inherited human login
• Least privilege applied to both the data the agent can read and the actions it can take
• Every agent is inventoried with a named owner and a documented purpose

Ingest

• All retrieved and tool-returned content is treated as untrusted input
• Inputs are filtered and validated before the agent acts on them
• Agents that read untrusted content are isolated from sensitive data and high-impact actions

Judgment

• The agent's plan is validated before execution for high-stakes tasks
• Autonomy is constrained to what the task actually requires
• Stored memory and context are protected from tampering

Action

• Tool calls run behind allowlists, with parameter validation and rate limits
• Human approval is required for sensitive or irreversible actions
• Execution is sandboxed or isolated from the wider environment
• A kill switch can stop the agent immediately

Release and testing

• A release gate documents intended use, acceptance criteria, and failure/data-leakage tests
• A disable-or-rollback plan exists before launch
• Monitoring and anomaly detection run on agent activity
• Continuous adversarial red-teaming (including agentic pen testing) runs before and after launch

Govern and prove

• Tamper-evident, immutable logs make every agent action attributable
• Access is mapped to SOC 2 CC6 and reviewed on a schedule
• An AI acceptable-use policy and AI disclosure are in place
• An incident-response plan covers agent-specific failures
• Evidence is mapped to your chosen AI framework (ISO 42001, EU AI Act, or AIUC-1)

Where to Start Securing Your AI Agents

The best starting point for AI agent security is almost never a new tool. It's an inventory, a clear picture of how, when, and where agents are used across your organization and in your product.

Find the agents you already have running, write down what each one can access, and scope those permissions down to the task. Most teams will likely be surprised by what they find:

• Agents nobody owns
• Permissions far broader than the task requires
• Forgotten agents still running long after their project ended

Start at the points in your organization where risk is highest, such as agents that can move money, ship code, change records, or reach customer data.

None of this takes a new tool or a new certification. It takes knowing what your agents can do and being able to show you've kept them in bounds. If you'd like help building that into your security program, talk to our team.

Frequently Asked Questions

What's the difference between AI security and AI agent security?

AI security covers models and data broadly. AI agent security adds the autonomy problem: because an agent takes actions on its own, the attack surface includes its identity, its connected tools, and its permissions, not just the model.

Is prompt injection still the top AI agent risk?

It's still a top vector, but no longer the whole story. OWASP's 2025 agentic list ranks goal hijack, tool misuse, and identity and privilege abuse alongside it.

Do AI agents need their own identities and access controls?

Ideally, yes. Treat each agent as a scoped non-human identity with least privilege and periodic access reviews. Letting an agent inherit a human's access or run on a shared service account is how over-privilege and tool misuse happen.