AI Agent Security: A Practical Guide

AI agent security is the discipline of keeping an autonomous agent from being tricked, over-permissioned, or turned into a tool for an attacker: threat modeling what it can reach, enforcing least privilege on every tool it holds, sandboxing what it's allowed to touch, and validating what flows in and out of it. It matters more than general AI security because an agent doesn't just generate risky text, it takes action. A model that gets fooled produces a bad sentence. An agent that gets fooled has usually already acted on it.

Why Securing an Agent Is a Bigger Problem Than Securing a Model

AI security covers the threat categories that apply to any AI system: adversarial inputs that push a model toward the wrong output, data poisoning that corrupts training, prompt injection that hijacks instructions, model theft, and model inversion. Every one of those still applies to an agent, because an agent is built on a model underneath. What changes is what happens after the model gets fooled.

Rework's ACE Framework draws a hard line between two of its capabilities: Generate and Execute. Generating a draft reply is low stakes; a bad draft just gets deleted before anyone sees it. Executing that action, actually sending it, updating a record, issuing a refund, is where consequences live. A plain chatbot mostly lives on the Generate side of that line. An agent, by definition, crosses it. That's exactly why the Tools and Guardrails building blocks in how AI agents work exist: Tools define the ceiling on what an agent can do, and Guardrails define what it must never do regardless of what it's told. Security is what keeps both of those honest when someone is actively trying to break them.

The Agent Threat Model: Three Places Attacks Land

Most agent security incidents trace back to one of three surfaces.

Prompt injection is the one to take most seriously. It has held the top spot, LLM01, in the OWASP Top 10 for LLM Applications for the second consecutive edition, precisely because it's cheap to attempt and hard to fully close off. Direct injection is a user typing an instruction meant to override the system prompt. Indirect injection is worse for agents specifically: the instruction is hidden in a document, email, ticket, or web page the agent is asked to process, so whoever is attacking the agent never has to interact with it directly at all.

Least Privilege: Give the Agent Only the Tools Its Job Needs

The single highest-leverage security decision you make is also the most boring one: scope every tool to the narrowest access that lets the agent do its actual job, nothing more.

In practice, that means a support triage agent gets read access to tickets and a narrow write path to update ticket status, not a standing credential to your entire helpdesk admin panel. It means a CRM hygiene agent can edit specific fields, not delete records. It means every tool call runs under its own scoped token instead of one shared, powerful API key that every agent in your stack reuses, because that shared key turns one compromised agent into a compromised everything.

This is the same discipline behind the AI Access Provisioning Agent blueprint, which exists specifically to check every access request against policy and flag anything that looks like privilege escalation instead of granting it by default. Apply that same standard to the agent's own permissions, not just the permissions it manages on behalf of other people. If you wouldn't give a new hire standing access to everything on day one, don't give it to an agent either.

Sandboxing: Containing What the Agent Can Touch

Least privilege limits what an agent can reach. Sandboxing limits what happens if it reaches the wrong thing anyway.

A few practical patterns worth adopting:

• Stage before you grant write access. Run a new agent in a mode where it proposes actions but a human approves them, then graduate specific, low-risk action types to autonomous once you've watched it get them right consistently.
• Cap spend and rate per action type. A runaway loop or a manipulated agent can't do much damage if it's rate-limited and capped on cost per run.
• Separate environments for untrusted content. An agent that summarizes an inbound email shouldn't be running in the same context that holds write access to payroll.
• Require human confirmation on the irreversible actions. Sending an external communication, moving money, and deleting a record are exactly the cases where the cost of a false positive (asking a human unnecessarily) is much lower than the cost of a false negative (acting on a manipulated instruction).

This is the practical side of what Governance Requirements by AI Pattern describes: governance requirements should follow risk, and risk concentrates at the Execute step. An agent that can only draft is a much smaller sandbox to secure than one that can also send, pay, and delete.

Defending Against Prompt Injection Specifically

Because prompt injection is the top-ranked risk, it deserves its own defenses beyond least privilege and sandboxing.

Separate the instruction channel from the content channel wherever your platform allows it, so text pulled from a document or email is structurally marked as data to evaluate, not as commands to follow. Treat everything retrieved from outside your organization, a scraped page, an inbound message, an uploaded file, as untrusted by default, the same way a web application treats user input. Filter and screen inputs before they reach the model, understanding that no filter catches every attempt from a determined attacker, which is why this is one layer among several, not the whole defense. And keep a human in the loop for the specific action types where a successful injection would do real damage, not for everything, just the irreversible or high-value cases.

No single control here is sufficient on its own. That's the point. Defense in depth, several weaker layers stacked instead of one strong one, is the accepted approach because agent security failures tend to slip past exactly one layer at a time.

What Secure Enough Looks Like

The NIST AI Risk Management Framework organizes AI risk work into four functions: GOVERN, MAP, MEASURE, and MANAGE. Applied to an agent, that translates into a short, concrete checklist: govern who can approve new tool access for an agent, map the actual threat surface for each agent you run instead of relying on one generic AI policy, measure what the agent is doing against that threat model on an ongoing basis, and manage incidents with a real response plan instead of finding out from a customer.

The urgency here isn't hypothetical. Gartner predicts that by 2028, 25% of enterprise breaches will trace back to AI agent abuse, from both external attackers and malicious insiders. Separately, Gartner forecasts that 25% of enterprise generative AI applications will have at least five minor security incidents a year by 2028, up from 9% in 2025. Both numbers point the same direction: as agents get more tool access and more autonomy, incidents scale with them, not because the technology is getting worse, but because the attack surface is growing faster than most teams' controls.

Key Facts

• Agent security is a bigger problem than model security because agents act, not just generate. A fooled model produces bad text; a fooled agent produces a bad action.
• The three main attack surfaces are prompt injection, data exfiltration, and over-permissioned tools. Prompt injection (OWASP LLM01) has ranked the top LLM risk for two consecutive editions.
• Least privilege means scoping every tool to the narrowest access the agent's actual job needs, with its own token, not a shared god-mode credential.
• Sandboxing means staging write access, capping spend and rate, and requiring human confirmation on irreversible actions.
• Gartner predicts 25% of enterprise breaches will trace back to AI agent abuse by 2028, and 25% of enterprise GenAI applications will have five or more minor security incidents a year by 2028, up from 9% in 2025.

Where to Go Next

Security tells you an agent can't easily be tricked into acting wrongly. AI agent observability tells you whether it's acting wrongly anyway, since even a well-secured agent can drift, and you need to be able to see that. For a concrete look at how these controls show up in a real design, the AI Security Monitoring Agent and AI Access Provisioning Agent blueprints both build least-privilege and human-approval logic into their core design rather than bolting it on after launch.