Least Agency for AI Agents: Applying the OWASP Top 10 for Agentic Applications

The least agency boundary An AI agent sits inside a task boundary containing its approved goal, tools, data and decisions. Actions outside the boundary, such as self-granted permissions, unapproved payments, external data transfer and scope changes, are blocked. AI agent one defined task Task boundary Bounded goal Scoped tools Needed data Routine decisions Self-granted access Unapproved payment External data transfer Self-set new goal
Least agency keeps the agent inside the boundary its task requires.

An AI agent connected to enterprise systems can do much more than give a wrong answer. It can change records, execute transactions, retrieve confidential data and trigger workflows across connected applications. If its instructions are manipulated or its tools are too broadly permissioned, the impact reaches far beyond the original conversation. That is why AI agent security has become an architecture decision, not just a model or prompt decision.

The OWASP Top 10 for Agentic Applications, published by the OWASP GenAI Security Project on December 9, 2025 as the 2026 edition, gives security teams a shared framework for these risks. Its first three entries are ASI01: Agent Goal Hijack, ASI02: Tool Misuse and Exploitation, and ASI03: Identity and Privilege Abuse. Together, they expose a common weakness in many agent deployments: organizations give agents more autonomy and access than their assigned tasks require.

OWASP’s answer is a design principle called least agency. This guide explains what least agency means, how it differs from least privilege, and how CTOs and enterprise architects can build it into their AI agent security architecture before agents reach production systems.

Key takeaways

  • Least agency means giving an AI agent only the goals, tools, data and decision-making authority it needs for one defined task.
  • Least privilege limits what an agent can access. Least agency also limits what it is allowed to decide and do with that access.
  • Goal hijack, tool misuse and identity abuse all become far less damaging when the agent’s authority is narrow.
  • Least agency must be enforced at runtime through a policy layer, a tool gateway, scoped identities, sandboxing and human approval for high-impact actions.

What is least agency in AI agent security?

Least agency is the principle that an AI agent should receive only the minimum autonomy, tools, data and decision authority required to complete a defined task.

The agent should not have open-ended freedom to interpret instructions, expand its responsibilities or execute high-impact actions without approval.

The OWASP Top 10 for Agentic Applications presents least agency, together with strong observability, as a foundational principle for securing agentic systems. It builds on the earlier OWASP risk of excessive agency (LLM06:2025 in the OWASP Top 10 for LLM Applications), which describes what goes wrong when an AI system has more functionality, permissions or autonomy than its task needs.

Least agency has to shape the architecture before agents are connected to production systems. Adding it after deployment usually means unwinding permissions that teams already depend on.

Least agency vs least privilege for AI agents

Least privilege is an established security concept, and it still applies to AI agents. An agent should never hold permissions beyond what its task requires. But least privilege alone does not cover the full risk, because an agent can stay inside its permitted access and still take actions that are wrong for its purpose.

Least privilege
Least agency
Core question
What can the agent access?
How much can the agent decide and do on its own?
Controls
Data access, system permissions, credentials
Goals, tool operations, action approval, delegation
Example limit
The agent can read supplier records
The agent can recommend a supplier but cannot approve a purchase
Failure it prevents
Out-of-scope data access
Out-of-scope decisions and actions

The two are complementary. Least privilege for AI agents limits reach. Least agency limits autonomy within that reach. A secure design needs both.

Why too much autonomy creates AI agent security risks

Traditional application security focuses on controlling what a user or service can access. Agentic systems add a second dimension: what the system is allowed to decide and do.

An agent may receive a task, break it into smaller steps, select tools and act on the results. Its decisions can change as it processes new information. That flexibility is what makes agents useful, and it is also what makes them open to manipulation. It is a key difference covered in our comparison of AI agents vs RPA, where rule-based bots follow fixed paths and agents choose their own.

Consider an enterprise procurement agent. Its assigned task is to compare supplier quotations and prepare a purchase recommendation for a procurement manager. It has access to supplier records, internal pricing data and a procurement API.

Scoped to the task

Least agency applied
  • Read supplier records
  • Compare quotations and pricing
  • Draft a purchase recommendation for review
  • Approve purchases
  • Change supplier bank details

Over-permissioned

Authority exceeds the task
  • Read, compare and recommend
  • Approve purchases on its own
  • Modify supplier bank details
  • Initiate payments
  • One manipulated instruction becomes a financial incident

If the same agent can also approve purchases, modify supplier bank details and initiate payments, its authority exceeds the task. A manipulated instruction or an unsafe tool call could turn a recommendation workflow into a financial incident.

The issue is architectural. A prompt telling the agent to behave responsibly cannot compensate for excessive permissions in the systems it controls.

This is the same reason regulated teams pair AI with policy engines and guardrails, as we explored in our article on customer-facing AI in banking.

What the OWASP Top 10 for Agentic Applications covers

The OWASP framework identifies ten risk categories for agentic applications, numbered ASI01 to ASI10. The risks are connected, so addressing one category in isolation is not enough.

ID
Risk
What it means in practice
ASI01
Agent Goal Hijack Focus
Malicious content redirects the agent’s objective
ASI02
Tool Misuse and Exploitation Focus
Legitimate tools are used in unsafe ways
ASI03
Identity and Privilege Abuse Focus
Agent credentials or inherited permissions are misused
ASI04
Agentic Supply Chain Vulnerabilities
Compromised tools, models, plugins or MCP servers
ASI05
Unexpected Code Execution
Agent-generated code runs without safe isolation
ASI06
Memory and Context Poisoning
Corrupted memory or context changes future behavior
ASI07
Insecure Inter-Agent Communication
Agent-to-agent messages are spoofed or tampered with
ASI08
Cascading Failures
One fault spreads across connected agents and systems
ASI09
Human-Agent Trust Exploitation
People are misled into approving harmful actions
ASI10
Rogue Agents
Agents drift from or act outside their intended purpose

Three of these deserve particular attention when designing the control model for least agency.

ASI01Agent Goal Hijack

Agent Goal Hijack occurs when malicious or misleading instructions alter an agent’s intended objective. These instructions can arrive through user input, retrieved documents, emails, websites or any other content the agent processes. This is why indirect prompt injection is one of the most serious AI agent prompt injection security concerns.

For example, an agent asked to summarize a supplier document may encounter hidden instructions telling it to retrieve confidential records and send them to an external destination. Unless the architecture draws a clear boundary between trusted instructions and untrusted content, the agent may treat those instructions as part of its task.

A practical defense includes:

  • Define the agent’s permitted objective in a policy layer outside the model’s generated reasoning.
  • Treat retrieved documents, external content and tool responses as untrusted data.
  • Validate proposed actions against the original task and its permitted scope.
  • Prevent the agent from changing its own permissions or redefining its authorized objective.
  • Require human approval when an action falls outside the task’s predefined boundaries.
Prompt filtering helps flag suspicious instructions, but it should not be the primary security boundary. The system must enforce what the agent can do even when its reasoning has been successfully manipulated.

ASI02Tool Misuse and Exploitation

Tool misuse occurs when an agent uses legitimate tools in unsafe or unintended ways. The tool itself may work exactly as designed. The problem is that the agent has access to an operation that should not be available for its current task.

A customer support agent may need to view an order and prepare a refund request. It does not need unrestricted access to customer records, payment processing or account administration.

Strong AI agent tool security therefore defines permissions at the operation level:

Read invoiceAllowed
Delete invoiceNot granted
Draft payment requestAllowed
Release fundsNot granted

An agent that can read an invoice should not automatically be able to delete it. An agent that can draft a payment request should not automatically be able to release funds.

Use allowlisted tools with narrowly defined operations, validated input schemas and server-side authorization. Restrict network access and execution environments so that a compromised agent cannot reach unrelated services.

ASI03Identity and Privilege Abuse

AI agents need identities that can be authenticated, authorized and audited. Using a shared administrator account, or passing a user’s broad access token to an agent, creates unnecessary exposure. If the agent is compromised, the attacker may inherit permissions far beyond the task and use them for AI agent privilege escalation.

This is where AI non-human identities matter. Each agent or workload should have a distinct identity with defined permissions, a named owner and lifecycle controls. Good AI agent identity management follows a few rules:

  • Credentials are short-lived where possible and stored in managed secret systems.
  • Tokens are issued only for the operations the task requires.
  • Delegated access keeps clear boundaries.
  • One agent never inherits another agent’s permissions simply because both participate in the same workflow.

Not sure how much authority your agents really have?

Our architects map agent identities, tool permissions and approval paths, then show you where autonomy exceeds the task.

How to build least agency into AI agent security architecture

Least agency becomes enforceable when it is implemented across the agent runtime, the identity layer, the tool gateway and the enterprise applications themselves. A practical AI agent security architecture uses five control layers.

1

Define a bounded goal

Every agent should have a specific responsibility, an allowed outcome and clear limits. A research agent may collect and compare information. A finance agent may prepare a transaction for human review. Neither should be able to expand its own role.

The policy layer evaluates proposed actions against the assigned task. Any change to goals or operating scope should require an authorized configuration update, not a conversational instruction.

2

Apply permission boundaries to every tool

Create a tool registry that defines which agents can access which operations. AI agent permissions should distinguish read, write, update, delete and execute actions.

ReadWriteUpdateDeleteExecute

The tool gateway validates the agent identity, the requested operation, the input parameters and the resource scope before forwarding a call. This is the core of AI agent access control. Do not rely on the model to decide whether it is allowed to invoke a tool.

3

Sandbox agent execution

AI agent sandboxing limits the blast radius if an agent’s behavior is manipulated.

Run agents in isolated environments with restricted filesystem access, controlled network egress and explicit resource limits. Separate development, testing and production environments. Avoid exposing unrestricted shell access or direct database credentials to general-purpose agents. The same isolation thinking applies when agents create their own data environments, as covered in our guide to AI agent database provisioning.

Where an agent needs to execute code, use a managed execution environment with strict limits on runtime, memory, network access and available libraries.

4

Manage AI non-human identities

Assign each agent a distinct workload identity and connect it to an authorization service that evaluates permissions at runtime. This is zero trust for AI agents: no agent is trusted by default, and every request is verified.

Avoid permanent credentials and shared service accounts. Use short-lived tokens, scoped access and controlled delegation. Keep an auditable record of which agent requested an action, which identity authorized it and which service executed it.

This matters even more in multi-agent systems. A coordinator agent should not automatically pass its full permissions to every sub-agent. Each participant needs its own identity and an explicit delegation boundary.

5

Add human in the loop approval for high-impact actions

Not every agent action needs a person in the loop. Requiring approval for every read or routine update makes the system slow and frustrating, and people start approving without reading.

Actions with significant financial, operational, legal or security consequences should have explicit approval gates. Examples include:

Releasing payments
Changing access permissions
Deleting production data
Modifying supplier bank details
Sending sensitive information outside the organization

The approval must be bound to the exact proposed action, its target and its parameters. If the agent changes the request after approval, the system should require a new authorization. The reviewer should see enough context to make a real decision: the data involved, the reason for the request and the potential impact. This keeps people in charge of the decisions that matter while the agent handles the preparation work.

Runtime policy enforcement: making least agency work in production

A policy document cannot enforce least agency on its own. The restrictions must stay active while the agent is operating.

That requires a control layer between the model and enterprise tools. Every proposed action passes through identity verification, permission checks and policy evaluation before execution. A simplified runtime policy enforcement workflow looks like this:

Least agency runtime workflow
User request
Agent runtime
Goal and scope validation
Tool gateway
Identity and permission check
Risk and policy evaluation
Routine action
Execute in sandbox
High-impact action
Human approval
Authorized execution
Audit and monitoring

The workflow should fail closed for sensitive operations. If identity validation or policy evaluation is unavailable, the agent should not proceed with any action that could expose data or change critical systems.

Observability is equally important. Teams need traces that connect the original request, model decisions, tool calls, identity checks, approvals and execution results. These traces show investigators what happened and where a control failed. Our article on AI agent observability explains why agent workflows need this level of visibility.

For enterprise deployments that use the Model Context Protocol, MCP security needs equivalent controls for tool discovery and invocation. An available MCP tool should not automatically become an authorized tool. Read more about Model Context Protocol (MCP) and enterprise AI agents for the integration considerations.

AI agent governance: how to measure the authority an agent needs

Security teams should assess agent autonomy as carefully as they assess application permissions. Strong AI agent governance and agentic AI risk management depend on measuring the gap between what an agent can do and what it needs to do.

Useful measures include:

The number of tools available to each agent compared with the number its task requires
The percentage of tool calls blocked by policy
The number of high-impact actions routed through human approval
The frequency of permission changes and expired credentials
Attempts to access data outside the assigned scope
Unauthorized goal changes and suspicious tool invocation patterns

These indicators reveal agents that have accumulated unnecessary authority. They also show whether approval workflows are working or simply adding friction.

When planning a new deployment, start with the task and work backward. Define the minimum data access, tool operations and decision authority required. Then test the agent against malicious instructions, unexpected tool responses, compromised credentials and attempts to exceed its scope. These AI agent security best practices belong in the design phase, which is why any practical guide to building secure AI agents should treat them as core requirements rather than a security layer added after deployment.

How Seaflux helps enterprises build secure AI agents

Seaflux is an agentic AI development company and AWS Select Consulting Partner that designs and builds production AI agents for enterprises in fintech, healthcare and logistics. Our AI agent development services treat least agency as a design requirement from day one, so security controls are part of the architecture instead of a patch applied later.

Our secure AI agent development work covers:

Agentic AI security assessment

We map your existing agents, their identities, tool permissions, execution environments and approval paths, then identify where autonomy exceeds the business requirement.

AI agent security architecture

We design the policy layer, tool gateway, scoped non-human identities and sandboxed execution that enforce least agency at runtime.

Human-in-the-loop workflow design

We build approval gates for high-impact actions so your teams stay in control of the decisions that carry real financial, legal or operational weight.

Observability and governance

We instrument agents with end-to-end tracing and governance metrics so you can see every tool call and prove compliance.

Secure cloud foundations

Our cloud computing services provide the isolated environments, secret management and network controls that agent sandboxing depends on.

For regulated industries, we combine this with our HIPAA compliant software development practices and generative AI development expertise. If you are still deciding where agents fit in your organization, our AI strategy consulting services help you prioritize use cases and define the right level of autonomy for each one.

Conclusion: autonomy needs an architectural boundary

The OWASP Top 10 for Agentic Applications makes one point hard to ignore: an agent’s ability to act creates security responsibilities that ordinary chatbot safeguards cannot handle.

Least agency gives teams a practical way to manage those responsibilities. It limits the goals an agent can pursue, the tools it can invoke, the information it can access and the decisions it can execute independently, while keeping people responsible for the actions that matter most.

For enterprise architects, the next step is to review existing agent deployments and find where autonomy exceeds the actual business requirement. Start with agents connected to production systems, sensitive data or financial workflows. Map their identities, tool permissions, execution environments and approval requirements.

How many of your deployed agents can currently take an action that their assigned business task does not actually require?

Reviewing that gap is the starting point for a safer agentic architecture. Seaflux offers a free Agent Architecture Consultation to help you assess agent permissions, identity boundaries and runtime controls before you expand autonomy.

Book a free Agent Architecture Consultation

Frequently Asked Questions (FAQ): Get the Answers You Need

Krunal Bhimani

Krunal Bhimani

Business Development Executive

Claim Your No-Cost Consultation!

Let's Connect