An agent is an AI system permitted to act rather than only to answer. It can send the mail, update the record, open the ticket, move the file. Everything else about it is a variation on that one change, and that one change is what makes the security question different.
It is also a field where the practice is ahead of the guidance. Established frameworks cover identity, least privilege, logging and change control, and all of that applies unchanged. Dedicated guidance specific to agentic systems is being written now rather than settled, and this page tries to be clear about which of what follows is well established and which is current good practice that may not age well.
What actually changes
Three things, and only the third is genuinely new.
Consequence becomes irreversible. A wrong answer is a bad draft. A wrong action is a sent message, a deleted record, a payment. Review after the fact stops being sufficient, because there is nothing left to review before the effect.
The chain gets longer. An agent may call a tool whose output it reads, then call another based on that. Each step is an opportunity for the sequence to leave the path anyone anticipated, and the failure is frequently not in any single step.
Untrusted content can steer behavior. This is the new one. Where a system reads content and then acts, an instruction placed in that content can influence what it does. A support agent that reads an incoming message and can also send mail is a system where the message can, in principle, direct the sending.
The control that matters most
Constrain what the system is able to do, rather than instructing it about what it should do.
An instruction in a prompt is a request. A permission boundary is a fact. If an agent cannot reach an endpoint, no instruction it encounters can make it reach that endpoint, and no amount of clever phrasing changes the outcome. Every other control on this page is weaker than that one, and teams reach for the prompt because it is faster to change.
OWASP names the failure directly as LLM06:2025 Excessive Agency in its Top 10 for LLM Applications, describing systems granted more capability than the task requires. The mitigation is unglamorous scope reduction.
Identity, applied strictly
Whatever the agent does runs under some identity, and that identity's reach is the blast radius. The principles are the ordinary ones from AI identity and access management, applied with less tolerance.
- A distinct identity per capability, not one credential that can do everything the agent might ever need.
- Scoped to the specific resources the task requires, rather than to the system that contains them.
- Never the operator's full entitlements. An agent running with a person's complete access is that person's access, exercised by software, without the judgement that normally accompanies it.
- Read and write separated. Most agent value comes from reading. Writing should be a deliberate, separately granted addition.
NIST's SP 800-207 supplies the underlying principle, that no implicit trust follows from location, and it applies to a process as much as to a person.
Approval, placed where it is worth the friction
Human approval before an action is the most effective control available and the one most degraded by overuse. An approval step on every action trains people to approve without reading, which is worse than no step at all because it manufactures a record of consent that means nothing.
The workable pattern is to sort actions by reversibility and reach. Reading anything, and writing to a scratch area, need no gate. Actions that are reversible and internal can proceed with a record. Actions that leave the organization, move money, touch a system of record or affect many items at once are where the gate earns its cost.
Two supporting limits are worth having regardless. A cap on how many items one instruction can affect, so an error is bounded. And a rate limit, so a loop is expensive rather than catastrophic.
Isolation
Where an agent executes code or handles files, the environment it does so in should be one you are willing to lose. Ephemeral, without standing credentials, with outbound access restricted to destinations on a list.
That last point is the one that repays attention. Restricting where an agent may connect outward converts a whole class of exfiltration into a blocked connection, and it does not depend on detecting a malicious instruction. It is covered from the interface side in securing enterprise AI APIs.
The record, and the ability to undo
An agent's log needs to answer a harder question than an assistant's: not only what was said but what was done. Which tools ran, with what arguments, in what order, under which identity, and what each returned. Without the arguments, an audit can establish that something happened and not what it did.
Reversal is worth designing rather than assuming. Some actions undo cleanly, some undo partially, and some do not undo at all. Knowing which category each capability falls into, before granting it, is what makes the difference between an incident and an outage. In practice this often means preferring an action that creates something reversible, a draft rather than a send, a flag rather than a deletion.
Stopping it
Every agent deployment needs a way to halt it that does not depend on the agent cooperating: a switch that disables its credentials or its endpoint, operable by someone on call, tested at least once.
Untested is the usual state, and the failure mode is mundane rather than dramatic. The person who can revoke the credential is unavailable, or the switch turns off the wrong environment, or nobody is certain whether it worked. A stop control that has been exercised once is worth several that have not.
What is settled, and what is not
Worth separating honestly, because this area attracts confident advice.
Settled. Least privilege, scoped credentials, isolation, logging with arguments, approval gates on consequential actions, restricted outbound access, and a tested stop. None of it is specific to AI and all of it is well established. NIST's Generative AI Profile takes the same line where it lists autonomous agents among the threats to be assessed using established security measures.
Not settled. How to reliably prevent an instruction in content from influencing behavior; how to evaluate an agent's safety before deployment in a way that generalizes; how to attribute responsibility across a chain of automated steps. Techniques exist for all three and none is mature enough to rely on as a control. Treat them as defense in depth rather than as the reason an agent is safe to deploy.
OWASP maintains a dedicated agentic AI threats and mitigations resource, and MITRE's ATLAS catalogues adversary techniques against AI systems. Both are worth a reader's time, and this page does not summarize their contents.
A conservative starting position
Begin with an agent that can read broadly and write to one place. Add each further capability as a decision with an owner, a scope and a record. Put an approval gate on anything leaving the organization. Keep the operator's identity out of it. Test the stop.
That is a smaller deployment than the demonstrations suggest, and it is the version that can be expanded on evidence rather than rolled back after an incident.
Where to go next
The access model is AI identity and access management, the interface controls are securing enterprise AI APIs, and the record is AI logging, monitoring and auditing. Accountability and oversight are governance questions, covered by AI Governance.
LABUSA works through agent scope and boundaries as part of designing and securing AI environments, usually by reducing what a proposed agent may do before considering how it should do it. Get in touch to discuss a specific case.
Sources and further reading
- OWASP GenAI Security Project, OWASP Top 10 for LLM Applications, 2025, including LLM06 Excessive Agency.
- OWASP GenAI Security Project, Agentic AI: Threats and Mitigations. Cited as a pointer for further reading; its contents are not summarized here.
- MITRE, ATLAS, a knowledge base of adversary techniques against AI systems.
- National Institute of Standards and Technology, Zero Trust Architecture, SP 800-207, August 2020.
- National Institute of Standards and Technology, AI Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024.
The OWASP and MITRE material is community and research guidance, authoritative on threats and mitigations rather than on regulatory obligation. Every source above was opened and read on 20 August 2026.