AI Agent Security: A Practical Guide to Threats and Controls

AI agent security is the practice of protecting autonomous AI agents - and every system, credential, and dataset they can reach - from misuse, manipulation, and attack across their entire lifecycle. It matters because an agent is not ordinary software. Ordinary software does a fixed set of things you can read in its code. An agent decides what to do at runtime, and that decision can be steered by untrusted input it encounters while working: a web page it browses, a document it summarizes, a tool result it reads. The consequence is stark - the same agent identity that behaved correctly a moment ago may be executing an attacker's intent the next. This guide lays out the threat model that matters and a practical, ordered control stack you can actually implement, mapped across the agent lifecycle.

The goal is not to make agents un-attackable, which is not achievable. It is to build enough defense in depth that when an agent is manipulated - and some will be - the result is a contained, observable event rather than a breach. That means constraining what an agent is allowed to do before anything goes wrong, checking its high-impact actions as they happen, watching what it actually does, and being ready to respond. Let us start with what you are defending against.

The threat model: what actually goes wrong

Four threat classes account for most real agentic incidents. They rarely occur in isolation; a typical attack chains an injection into a tool misuse into an exfiltration. Understanding them as a system, not a checklist, is what makes the control stack make sense.

Prompt injection (direct and indirect)

Prompt injection is the delivery mechanism for most agent attacks. Direct injection is a malicious instruction typed straight into the agent. Indirect injection is the dangerous one: the instruction is hidden in content the agent consumes while doing its job - a web page, an email, a code comment, a tool response - so the attacker never interacts with the agent directly. Because agents routinely read untrusted external content, indirect injection is a structural property of how agents work, not an edge case. We cover the mechanism and defenses in indirect prompt injection explained.

Excessive agency

Codified as OWASP LLM06, excessive agency is the harm that follows when an agent can take damaging actions in response to unexpected or manipulated output. OWASP names three root causes: excessive functionality (tools the agent does not need), excessive permissions (access beyond the task), and excessive autonomy (high-impact actions with no verification). Over-privilege is the amplifier for everything else - a manipulated action is only as harmful as the access behind it. This is why least privilege sits so high in the control stack; see least privilege for AI agents.

Tool and MCP misuse

Agents act through tools and MCP servers - the shell, the database client, the API caller. Tool misuse is when a manipulated agent turns those legitimate capabilities against you: using a file tool to read secrets, a network tool to reach an attacker endpoint, a deploy tool to alter infrastructure. Nothing here is a software vulnerability in the classic sense; the tools work exactly as designed. The abuse is in which tool gets called, with what arguments, at whose direction. That is precisely what runtime governance exists to catch.

Data exfiltration

The endgame of many attacks. Simon Willison's lethal trifecta captures why it is so hard to prevent: exfiltration becomes near-guaranteed when an agent simultaneously has access to private data, exposure to untrusted content, and the ability to communicate externally. The important insight is architectural - remove any one leg and the chain breaks. An agent whose identity simply cannot make external network calls cannot exfiltrate, no matter what injection it reads. We go deep in the lethal trifecta and AI agent data exfiltration.

The practical control stack

The controls below are ordered deliberately. Each layer assumes the one before it will sometimes fail, and bounds the damage when it does. You implement them in this sequence because each depends on the last - you cannot scope permissions for agents you have not inventoried, and you cannot investigate incidents without the audit trail monitoring produces.

1. Inventory: you cannot secure what you cannot see

Everything starts here. Most organizations cannot answer basic questions - how many agents are running, what MCP servers they call, what each can access - because agents arrive bottom-up as shadow IT, installed by developers and employees without a ticket. Build a complete, continuously updated inventory of every agent and MCP server, the identity each uses, and who owns it. Practical starting points are how to build an AI agent inventory and how to build an MCP server registry.

2. Least privilege: bound what any agent can do

Once you can see agents, scope them. Give each agent its own dedicated identity with the minimum permissions its task requires, short-lived credentials rather than static keys, and no ability to modify its own scope. Least privilege is the single highest-leverage control because it bounds the damage of every other failure - a prompt injection that hijacks an agent with no dangerous permissions achieves nothing. Treat it as an architectural control, not hygiene. The full treatment is in least privilege for AI agents.

3. Runtime governance: check actions before they execute

Least privilege sets the outer boundary; runtime governance makes finer decisions inside it. On agents that expose a hook, each tool call can be evaluated against policy - allow, deny, or log - before it runs, out of band from the agent so a code-writing agent cannot bypass it. This is where tool misuse and dangerous single actions get stopped in the moment: an unexpected shell command, a network call to an unknown host, a bulk file read. Because the check happens before execution, a manipulated action never lands. This layer is what makes the difference between watching a breach and preventing one.

4. Monitoring and anomaly detection: watch what agents actually do

Not every threat is a single blockable action; some are patterns - an agent that slowly drifts from its normal behavior, a dormant scope suddenly used, a burst of access at an odd hour. Continuous monitoring and anomaly detection catch what point-in-time policy misses, and they produce the signal that feeds incident response. See runtime monitoring and anomaly detection for AI agents for the detection patterns that matter.

5. Incident response: contain and investigate

Assume something will eventually get through. When it does, you need to detect it, contain the affected agent (revoke its credentials, disable it), and investigate what happened using a reliable audit trail. Agentic incidents have their own shape - the culprit is an autonomous process acting under a machine identity, not a person - so the playbook differs from a classic breach. Build it before you need it, following the AI agent incident response playbook.

Mapping the stack across the agent lifecycle

The controls above are not one-time gates; they apply continuously across an agent's life. It helps to see them mapped to lifecycle stages, because each stage has a natural control emphasis:

• Onboarding / install. Discovery catches the agent the moment it appears; vetting and least-privilege scoping happen before it does real work.
• Configuration. Identity is assigned (dedicated, not shared), permissions are scoped to the task, and static long-lived keys are replaced with short-lived credentials.
• Runtime / operation. Runtime governance evaluates each tool call, and monitoring watches for anomalies and drift as the agent works.
• Change / update. Re-vetting on update catches drift, because the agent, skill, or MCP server you approved may not be the one running next week.
• Incident. Detection, containment, and investigation kick in, drawing on the audit trail the earlier stages produced.
• Retirement. The agent's identity and credentials are revoked and removed, so nothing orphans into a standing risk.

This lifecycle view is also how agentic security maps to governance frameworks. The structure aligns with the govern-map-measure-manage functions of the NIST AI Risk Management Framework, and the threats align with the OWASP Top 10 for Agentic Applications. For the framework mapping in full, see the OWASP Top 10 for Agentic Applications guide, and for the complete enterprise program that wraps all of this together, the complete enterprise AI security guide.

Why no single control is enough

It is tempting to look for the one control that solves agent security. There isn't one. Prompt-level defenses can be overridden. Least privilege bounds damage but does not detect misuse. Runtime governance blocks known-bad actions but cannot anticipate every pattern. Monitoring catches anomalies but after they begin. The whole point of the ordered stack is that each layer covers the gaps of the others: an injection that beats the prompt hits an agent with no dangerous permissions, whose one risky call is denied at runtime, whose anomalous behavior is flagged by monitoring, and whose activity is fully recorded for response. Defense in depth is not a slogan here; it is the only structure that works against a principal that can be turned against you mid-task.

Where visibility fits, and where Anomity sits

Every layer of the stack shares one precondition: you can only secure agents you can actually see. The recurring 2026 finding that only about a fifth of organizations can see what their agents access is the gap that makes the rest impossible - you cannot scope, govern, monitor, or investigate an agent you never inventoried.

That is exactly where Anomity operates. Its category is agentic endpoint security, built on the principle that you can't govern what you can't see. A lightweight, unprivileged Endpoint Sensor on every managed endpoint (Windows, macOS, and Linux) discovers and inventories eight AI artifact types - agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs - which gives you the inventory the whole stack depends on. On agents that expose a hook, Anomity evaluates each tool call and returns allow, deny, or log before it runs, delivering the runtime-governance layer directly. Continuous policy evaluation surfaces drift and anomalies, violations route to your SIEM, Slack, email, and Jira, and every artifact change lands in a queryable 90-day audit trail that feeds monitoring and incident response. Metadata only leaves the endpoint over HTTPS - never source, never prompts, secrets redacted at the source. Anomity is SOC 2 Type II and complements your EDR/XDR, DLP, network and gateway controls, and GRC program rather than replacing them.

You can't govern what you can't see.The Anomity principle

The bottom line

AI agent security is the practice of protecting autonomous agents and everything they can reach, across their whole lifecycle, from a threat model dominated by prompt injection, excessive agency, tool misuse, and data exfiltration. Because agents choose their actions from untrusted input, no prompt-level fix is a boundary; durable security comes from an ordered, defense-in-depth stack - inventory, then least privilege, then runtime governance, then monitoring, then incident response - applied continuously as the agent is installed, configured, operated, updated, and retired. Every layer depends on seeing your agents in the first place, so start with discovery. Read least privilege for AI agents and the complete enterprise AI security guide for the next layers of depth, or book a 30-minute demo to see your own agent fleet mapped.