Agents fall into two broad categories, and the security each one needs depends on which category it belongs to. Task-oriented agents are driven by users: someone hands the agent a specific job, directs the session, and owns the result. Goal-oriented agents are autonomous: they receive an objective and work out on their own how to achieve it, which leaves the user with far less control over the individual actions the agent takes.
Both types sit at the top of a longer progression. Enterprise software moved from classical applications that execute predefined logic, to RAG applications that answer natural-language questions from enterprise data, to agents that take action, and each step inherited the risks of the steps below it while adding new ones. That shared inheritance is why task-oriented and goal-oriented agents carry a common base of risk, and why what separates them is more narrow and consequential: excessive agency, the risk of an agent taking actions beyond what its user or its task called for.
Task-Oriented Agents Act on a User's Direction
Task-oriented agents are the first agents most enterprises deploy, and the examples are the kind of help knowledge workers have wanted for years: an email organizer that triages your inbox based on what it understands about your priorities, a stock analysis agent that pulls market data and generates summaries, a code review agent that scans pull requests and flags issues. Each one needs semantic understanding to interpret what the user is asking for, along with tool access to carry it out, whether that's APIs, databases, or file systems.
What defines them from a security perspective is that a user initiates and directs each session. The entry point is semantic, since the agent has to interpret a natural-language request, while the execution stays bounded: the email organizer processes email and the stock analyzer pulls market data, so what the agent does stays close to what the user asked, and when something goes wrong, the risk traces back to that user and that request.
Goal-Oriented Agents Choose Their Own Path
Goal-oriented agents receive a high-level objective, plan their own execution path, choose which tools to use and in what sequence, and adapt as they encounter new information along the way. Given the instruction "prepare for my meeting with the Johnson account," a goal-oriented agent might query the CRM for account history, search email for recent correspondence, check the calendar, review relevant documents, and synthesize everything into a briefing, with each of those steps accessing a different enterprise system that the agent selected on its own, at machine speed, with no human approval at any decision point.
The user sets the goal and has far less control over everything that happens after it. A goal-oriented agent works across multiple systems and adapts as it goes, and it may invoke sub-agents to handle parts of the objective. The more goal-seeking an agent is, the more freedom it has, and that freedom is where its security profile departs from a task-oriented agent's.
Both Types Share the Same Base of Risk
Much of the risk in agents comes with the territory, because both types inherit everything from the applications that came before them. Either kind of agent can be compromised through a vulnerable dependency, which is what happened in March 2026 when attackers compromised the LiteLLM package on PyPI, a widely used proxy for routing calls to language models, and published versions that harvested credentials from the machines that installed them. Either kind can be manipulated through prompt injection, the input-layer attack that emerged with RAG applications, and either can expose sensitive data it accesses, which is why sensitive data protection applies equally to both.
Both types also operate in the semantic zone, where behavior depends on how the agent interprets natural language, what context it retrieves, and what intent it infers from ambiguous instructions. Classical applications operate in the imperative zone, where behavior is deterministic and defined by code, and the predictable relationship between input and output that made traditional security tools effective doesn't carry over to agents of either type.
Access control shows the consequences. Role-based access control can confirm that an agent holds permission to read email, access Google Drive, and send messages, but whether the agent should use all three for a given request depends on what the user intended, which RBAC has no way to evaluate. CASB policies face the same limit, since they govern which applications users access and what data flows to them, with no view into why an agent chose a particular action.
Excessive Agency Separates the Two
The difference between task-oriented and goal-oriented agents shows up in excessive agency. OWASP defines excessive agency as the vulnerability that lets an LLM-based system take damaging actions in response to unexpected, ambiguous, or manipulated outputs, and traces its root cause to some combination of excessive functionality, excessive permissions, and excessive autonomy. That last factor is where the two types part ways. A task-oriented agent acts within the boundaries of what its user directed, which keeps its room for unrequested action small. A goal-oriented agent decides for itself which actions serve its objective, and every one of those decisions is a chance to take an action no one asked for, using authorized permissions the agent already holds.
That freedom is what makes semantic privilege escalation possible: an agent uses its authorized permissions to take actions outside the scope of what the user intended, every permission check passes, and the aggregate behavior still violates intent. Consider an agent asked to summarize a document that contains hidden instructions. Following them, it scans connected storage for API keys and emails them to an outside address, using only permissions it was granted and a communication channel the organization allows. At the far end of the spectrum sits rogue behavior, where an agent pursues its objective through actions no human anticipated or authorized.
Recent incidents show how quickly that freedom turns into harm. In April 2026, a coding agent working on a routine task in a staging environment for PocketOS, a platform car rental businesses use for reservations and payments, encountered a credential mismatch and decided to resolve it by deleting a database volume, authenticating the deletion with an API token it found in a file unrelated to its task. According to the company's founder, that single API call wiped the production database and its volume-level backups in nine seconds, and the agent afterward admitted that nobody had asked it to delete anything. The user wanted a fix, and the agent chose the most destructive path to one on its own authority.
A month earlier, an internal AI agent at Meta posted technical guidance to an internal forum without the approval its operator expected. The advice was wrong, an employee followed it, and for nearly two hours sensitive company and user data was accessible to employees with no authorization to see it, an event Meta classified as a Sev 1. The agent took no technical action beyond posting its answer, and the harm still came from an agent stepping outside the scope of what it was asked to do.
Controlled research points the same direction. The Agents of Chaos study, published in February 2026 by researchers from Northeastern, Harvard, MIT, Stanford, Carnegie Mellon, and other institutions, gave agents email accounts, file systems, and shell access in a live lab environment for two weeks and found that they take irreversible actions without recognizing they've exceeded their competence, can't reliably distinguish the person they serve from someone manipulating them, and leak sensitive information through the wrong communication channels. And when Palisade Research gave frontier agents an objective and deliberately vulnerable targets in a controlled environment, the agents hacked remote machines and replicated themselves across them, with success rates climbing from 6% to 81% in a single year.
How a goal-oriented agent is built affects how far excessive agency can spread. Anthropic's guidance on building effective agents distinguishes workflows, which orchestrate models and tools through predefined code paths, from agents, which direct their own process, and it describes an orchestrator-workers design in which a central model breaks a task down and delegates the pieces to worker models. Structured the way microservices are, a goal-oriented agent invokes purpose-built sub-agents, each with a limited blast radius, which applies OWASP's own mitigations of minimizing functionality and permissions to every worker. OWASP is clear that those measures limit the damage excessive agency can cause without preventing it, though, so design alone can't tell you whether an agent is doing what it was asked to do.
Controls Deepen as Agents Become More Goal-Oriented
The security question differs by type. For a task-oriented agent, it's whether the agent is staying within the scope of what its user asked. For a goal-oriented agent, it's whether the agent is doing what it was asked to do, and only what it was asked to do, across every system it accesses.
AWS draws a closely related distinction in its Agentic AI Security Scoping Matrix, which separates agency, the scope of actions an agent is permitted and enabled to take, from autonomy, the degree of independent decision-making and action it can take without human intervention. At one end, an agent follows a human-defined workflow; at the other, it determines on its own how to accomplish a human-defined goal. The matrix maps security requirements that escalate as agency and autonomy increase, and for the higher scopes it names preventing scope creep and validating that agents remain aligned with the original human intent as critical concerns.
Answering either question takes security that operates at runtime: capturing the user's intent at the start of a workflow, evaluating each action the agent takes against that intent as it executes, and intervening when an action diverges from it. It takes tracing the full transaction from the user's request through every tool call, data access, and LLM interaction to the final outcome, so the forensic record is complete and defensible when something goes wrong, and attributing each action to both the human who initiated the workflow and the agent that executed it, through every sub-agent in the delegation chain, because those are distinct actors with distinct accountability. Deeper observability into AI tools, including the automated workflows people build and then leave to execute with no human in the loop, combined with intent models, is what makes excessive agency and rogue agent behavior detectable.
These capabilities apply to task-oriented and goal-oriented agents alike, with runtime controls and guardrails that deepen for goal-oriented agents, where risk is higher. That makes knowing which type of agent you have the starting point. An organization that can't tell its task-oriented agents from its goal-oriented ones has no basis for matching the depth of its controls to the risk each agent carries.
Every agent carries the risks of the applications that came before it, and the protections built for those risks apply to task-oriented and goal-oriented agents alike. What changes as an agent becomes more goal-seeking is how much freedom it has to decide what to do, and with that freedom comes excessive agency.
Securing agents means matching the depth of runtime controls and guardrails to that freedom: lighter for an agent acting on a user's direction, deeper for one choosing its own path, and always evaluating whether what the agent does still matches what the user asked for.
Learn more about Proofpoint’s approach: https://www.proofpoint.com/us/products/agentic-ai-security