An AI agent is software that does not merely answer; it acts. Give it a goal and a set of tools, and it will read files, call APIs, send messages, and chain those actions together to reach the goal on its own. That autonomy is the entire point, and it is also the security problem: an agent is a new identity with real permissions, driven by inputs you do not fully control. The moment it can take an action, the question stops being “what will it say” and becomes “what can it do, as whom, and who is watching.”
Agentic attack paths are the routes that open when that autonomy meets over-broad permissions, weak identity boundaries, and thin monitoring. This guide keeps the discussion defensive and structural. It is not about tricking an agent; it is about understanding where an agent’s reach ends, why that boundary is often larger than intended, and what evidence tells a defender that the boundary is holding.
What makes an agent an attack path
A traditional program does a fixed thing. An agent decides what to do next based on context, and that context can include untrusted content — a web page it reads, an email it processes, a document it summarizes. Combine decision-making with tools that can change the world, and you have created an actor whose behavior is not fully predetermined and whose instructions can be influenced by data it encounters. The attack path is the chain from that influence to a consequential action: read a record, move a file, call an external service, grant an access.
The useful mental shift is to stop thinking of the agent as a feature and start thinking of it as a principal — an identity in your systems with credentials, scopes, and a blast radius. Everything you already know about limiting what an identity can do applies, which is why IAM Roles and Least Privilege and What an Attack Path Is are the right companions. An agent does not invent new categories of harm so much as it walks the existing ones faster and more tirelessly than a human would.
Toy example
Imagine a fictional analytics firm, Harbor Metrics, that deploys an internal agent to help staff answer data questions. To be useful, it is given read access to a warehouse, the ability to run queries, and a tool to post summaries into a chat channel. Later, someone extends it to read shared inboxes so it can “answer questions about client threads.” Each grant was reasonable in isolation. Together they describe an identity that can read client email, query sensitive data, and publish to a channel — a wide reach that no single person approved as a whole.
A defender reviewing this does not need a live incident to find the problem. The exercise is to draw the agent’s identity boundary: list, on an invented worksheet, every tool it holds, the scope of each, and what the combination could accomplish if a single instruction were subverted by content it processed. The realization is usually that the union of grants exceeds anyone’s intent. The fix is boring and effective — remove the inbox tool, scope the warehouse role to the specific tables the job needs — and it is the kind of finding a periodic review catches long before it matters.
What evidence matters?
For agents, the strongest evidence is a clear record of identity and action: which identity the agent runs as, what tools and scopes it holds, and an auditable log of the actions it actually took, with timestamps and the inputs that triggered them. An agent that acts through a shared or human-owned account is a monitoring dead end, because its actions blur into everyone else’s; an agent with its own distinct, least-privileged identity is one you can actually watch. That separation is the single most valuable piece of evidence you can arrange in advance.
After identity comes behavior. Baselines matter: what tools does this agent normally invoke, at what volume, against which systems? A sudden reach into a resource it has never touched, or a spike in outbound calls, is the kind of deviation worth a look. The reasoning in Service Accounts and Secrets and Logs: What to Keep and Why transfers directly, because an agent is essentially a very busy service account whose decisions you need to be able to reconstruct after the fact.
Where the identity boundary really sits
Teams routinely underestimate an agent’s boundary because they reason tool-by-tool instead of about the union. The real boundary is the total set of resources reachable by the identity the agent runs as, multiplied by the tools it can invoke, plus anything those tools can reach downstream. If a query tool can hit any table, the boundary is the whole warehouse regardless of the task. If a messaging tool can post anywhere, the boundary includes every channel. Delegation makes it worse: an agent that can call another service inherits, in practice, part of that service’s reach.
Drawing the boundary explicitly is the advanced move. Treat your diagram of where permissions end as a claim that needs evidence, not as a comfort. State what it cannot prove, which telemetry might be missing, and which action would be unsafe to take without human authorization. Least privilege and segmentation do the heavy lifting: scoping the identity narrowly, keeping tools to the minimum the job requires, and using Network Segmentation and Flat Networks so that a subverted agent meets walls rather than open plains. Privileged Access Reviews applied to non-human identities is how the boundary stays honest over time.
Monitoring an actor that improvises
Monitoring an agent differs from monitoring a fixed script precisely because the agent improvises. You cannot enumerate every action in advance, so you watch for shape rather than exact steps: actions outside the agent’s normal repertoire, use of high-consequence tools, sequences that end in data leaving the environment, or a human-in-the-loop checkpoint being bypassed. Requiring explicit approval for a small set of irreversible or sensitive actions — deleting data, granting access, sending funds, publishing externally — turns the riskiest moments into deliberate decisions instead of silent ones.
Because agents can move quickly, the value of monitoring is partly in the pause it enables. A high-consequence action that waits for approval gives a human the chance to notice that the agent’s stated reason does not match the request. The signals overlap with classic detection work: unusual identity behavior and unexpected reach are the same tells covered in Lateral Movement Signals and Valid Accounts , now applied to a principal that never gets tired.
Common mistakes and false positives
The signature mistake is granting broad tool access before logging and approvals exist, on the theory that capability can be tightened later. In practice it rarely is, and the agent quietly accumulates reach. A related error is running the agent as a human’s account or a shared service identity, which destroys attribution: you can no longer tell the agent’s actions from a person’s. Assuming the model’s own guardrails substitute for access control is a third; a refusal is not a permission boundary, and it should never be the only thing standing between an agent and a sensitive resource.
False positives are real and worth handling gracefully. An agent legitimately expanding into a new task will trip novelty-based alerts, and a burst of activity may simply be a busy day. The goal is not zero deviation but explained deviation: a change tied to an approved new use, an owner who confirms the expanded scope, a baseline updated on purpose. Treat an unexplained deviation as a question, not a verdict, and let the answer either close it or justify a real response.
What to do next
Give every agent its own least-privileged identity, then draw its boundary as the union of tools, scopes, and downstream reach, and cut whatever the job does not need. Put logging and human approval in place before widening capability, not after. Watch for behavior outside the agent’s normal shape, and require deliberate approval for the small set of irreversible actions. Review these non-human identities on the same cadence you review privileged human ones, because their scopes drift just as quietly.
If an agent appears to have taken a harmful action, treat it as you would any incident: preserve the logs, follow your response process, and involve the right people rather than debugging it live in production. The sibling guides Secure AI Tool Intake and Prompt Injection for Defenders address how agents acquire tools and how untrusted input steers them, and Shadow AI Data Leaks covers the ungoverned edge where such agents often first appear.
How this guide was made
This page is defensive education drawn from public frameworks and adversary-technique catalogs, using an invented firm and toy data so nothing here is operational. It makes no claim to certification, legal advice, or incident-response authority, and it describes no method for manipulating an agent. The intent is to help you reason about identity boundaries, permissions, and monitoring for autonomous software, not to provide a playbook for any specific platform.
Official references
For orientation rather than certification, the OWASP Top 10 for Large Language Model Applications catalogs agent- and tool-related weaknesses such as excessive agency, and the NIST AI Risk Management Framework with its NIST AI RMF Generative AI Profile frames how to govern autonomous AI systems. The NIST Cybersecurity Framework 2.0 supplies the identity, logging, and least-privilege language that agentic defense rests on.
Related guidebooks
Build outward from here with IAM Roles and Least Privilege and Privileged Access Reviews , applied to non-human identities. For the AI-specific inputs and edges, Prompt Injection for Defenders and Secure AI Tool Intake explain how agents are steered and how they should be admitted in the first place.
