Excessive Agency Explained: When Your AI Agent Has Too Much Power (OWASP LLM Top 10 #6)
Most security conversations about AI focus on what goes into the model or what comes out of it. But a growing category of risk has nothing to do with prompts or outputs. It is about what the AI is allowed to do. Excessive Agency, ranked #6 in the 2025 OWASP Top 10 for LLM Applications, occurs when an AI system is granted more functionality, broader permissions, or greater autonomy than it needs to accomplish its intended task. When that over-provisioned agent encounters an ambiguous instruction, a hallucinated action, or a prompt injection attack, the damage it can cause is determined not by the vulnerability itself but by the scope of power it was given. This guide explains how excessive agency creates compounding risk, why traditional access controls miss it, and how to build AI systems that follow the principle of least privilege from day one.
Imagine a nonprofit that deploys an AI assistant to help staff manage their email. The tool can read messages, draft replies, and organize the inbox. But the email plugin the development team integrated also includes the ability to send messages, delete conversations, and modify account settings. Nobody expects the AI to use those extra capabilities, so nobody thinks to restrict them. Then one morning, a carefully crafted phishing email lands in the inbox. Hidden within its contents are instructions that the AI interprets as a legitimate request. The AI scans the inbox for financial records, composes a summary, and forwards it to an external address. It was never supposed to send email. But nobody told it that it could not.
This scenario, drawn from real attack patterns documented in the OWASP classification, illustrates the core problem with excessive agency. The vulnerability does not require a flaw in the AI model itself. It requires only that the AI system has access to capabilities beyond what it needs. When an AI agent can read, write, delete, execute, and configure, every other vulnerability in the OWASP Top 10 becomes more dangerous. A prompt injection attack against a read-only assistant might leak some text. The same attack against an agent with write access to databases, email, and file systems can cause catastrophic, irreversible damage.
This is the sixth article in our comprehensive series covering every vulnerability in the OWASP Top 10 for LLM Applications. The first article covered prompt injection, which manipulates what goes into the model. The second addressed sensitive information disclosure, where AI systems leak confidential data. The third explored supply chain vulnerabilities in AI components. The fourth covered data and model poisoning. And the fifth examined insecure output handling, where unsanitized AI responses become attack vectors. Excessive Agency is different from all of these because it is not about a specific attack technique. It is a design problem that amplifies every other vulnerability on the list.
The rapid adoption of agentic AI, systems that can take actions in the real world rather than simply generate text, has made excessive agency one of the most urgent security challenges facing organizations today. As nonprofits integrate AI agents into donor management, case documentation, financial operations, and program delivery, the question is no longer just "what can the AI say?" but "what can the AI do?" In this article, we will break down the three dimensions of excessive agency, examine how each creates real risk in organizational contexts, identify the patterns that make traditional security tools ineffective, and provide a layered defense framework that keeps your AI systems powerful without making them dangerous.
What Excessive Agency Actually Is
Excessive Agency occurs when an LLM-based system is granted a degree of capability that exceeds what is necessary for its intended function. The OWASP classification identifies three distinct dimensions of this problem: excessive functionality, excessive permissions, and excessive autonomy. Each dimension represents a different way that an AI system can be over-provisioned, and each creates different patterns of risk. In practice, most vulnerable deployments suffer from a combination of all three.
The concept maps directly to one of the oldest principles in information security: least privilege. The idea that a user, process, or system should have only the minimum access needed to perform its legitimate function has been a cornerstone of secure design for decades. It is built into operating systems, database management, network architecture, and identity management. But when organizations deploy AI agents, this principle is frequently abandoned. Development teams give the AI broad tool access because restricting it feels like crippling the product. They provide admin-level database credentials because setting up role-based access takes time. They allow the agent to execute actions autonomously because requiring human approval slows down the workflow. Each of these shortcuts creates a wider blast radius for any failure, whether that failure comes from a malicious attack, a hallucinated action, or a simple misunderstanding.
To understand why this matters differently for AI systems than for traditional software, consider what happens when a conventional API endpoint has excessive permissions. A web server running as root is dangerous, but it is deterministic. It will only execute the code that was deployed to it. An AI agent running with root-equivalent permissions is fundamentally different. Its behavior is probabilistic, shaped by user inputs, system prompts, context windows, and the stochastic nature of language model inference. The same agent processing the same input might take different actions on different runs. When you combine non-deterministic behavior with elevated privileges, you get a system where the potential for unintended consequences is not just possible but mathematically inevitable over a sufficient number of interactions.
The Three Dimensions of Excessive Agency
Excessive Functionality
The AI has access to more tools, plugins, or capabilities than it needs for its intended task.
- •Email reader with send, delete, and settings access
- •Database query tool that also allows schema modifications
- •File browser that includes file deletion and execution
Excessive Permissions
The AI operates with higher privileges than its task requires, often using shared or admin credentials.
- •Read-write database access when read-only would suffice
- •Admin API keys shared across all AI-connected services
- •Full OAuth scopes when a narrow subset is needed
Excessive Autonomy
The AI makes decisions and takes actions without human review, approval, or confirmation.
- •Automated email sending without draft review
- •Database modifications executed without confirmation
- •Financial transactions processed on AI recommendation alone
The key insight about excessive agency is that it is a force multiplier for every other vulnerability. A prompt injection attack against an AI chatbot that can only generate text is a nuisance. The same attack against an AI agent that can send emails, modify databases, transfer funds, and delete files is a potential disaster. The severity of any AI security incident is determined by two factors: the probability that the AI can be tricked or confused into performing an unintended action, and the scope of actions available to it when that happens. Organizations cannot reduce the first factor to zero because LLMs are inherently probabilistic. But they can dramatically reduce the second factor by applying the principle of least privilege to every dimension of their AI system's capabilities.
How Excessive Agency Works in Practice
Excessive agency becomes dangerous when the over-provisioned capabilities of an AI system intersect with any trigger that causes unintended behavior. That trigger might be a deliberate attack, a hallucinated action, or an ambiguous instruction that the AI interprets differently than the user intended. The following scenarios illustrate how each dimension of excessive agency creates specific, concrete risks that organizations face when deploying AI systems.
The Over-Equipped Email Agent
Excessive functionality turns a reader into an attacker's proxy
A nonprofit deploys an AI assistant to help staff manage incoming emails. The tool's core job is straightforward: read emails, summarize them, and flag urgent items. But the email plugin the team selects provides full mailbox access, including the ability to send messages, forward conversations, delete emails, and modify filters. The extra functions seem harmless since the AI is only "supposed" to read. Then an attacker sends a carefully crafted email containing hidden instructions. The AI, processing the email's content as part of its summarization task, interprets those instructions as a legitimate request. It searches the inbox for emails containing financial information, composes a summary, and forwards it to an external address controlled by the attacker. The AI had the capability to send email because the plugin provided it. Nobody restricted that capability because nobody expected the AI to use it.
This is the canonical example from the OWASP classification, and it illustrates a critical pattern: when you give an AI tool access to functionality it does not need, you are not just wasting resources. You are pre-authorizing actions that could be triggered by any future vulnerability. The fix is simple in principle: use a mail plugin that only supports reading, or configure the plugin to disable send and delete functions. But in practice, many development teams reach for the most full-featured plugin available and never revisit which capabilities are actually needed.
The Admin-Credentialed Reporting Tool
Excessive permissions expose the entire database through a single interface
An organization builds a natural language reporting interface that lets program managers ask questions about service delivery data. "How many clients did we serve in Q4?" or "What is our average response time?" The AI translates these questions into SQL queries and returns the results. To simplify deployment, the development team connects the AI to the database using an admin account with full read-write access to every table. The AI only needs to query the program_data and service_metrics tables, but it has credentials that can read the donor_records, staff_payroll, client_pii, and financial_transactions tables as well. It can also modify and delete records.
When a program manager asks a poorly phrased question, the AI might generate a query that unintentionally accesses donor financial records. When an attacker with reporting access crafts a deliberate prompt, the AI might produce queries that extract sensitive data from tables the user was never meant to see. And because the credentials allow write access, a sufficiently creative prompt injection could cause the AI to modify or delete records. The blast radius of this vulnerability is not determined by the AI's intent but by the permissions it was granted. A dedicated read-only database role restricted to specific tables would have made most of these attack paths impossible regardless of what the AI was tricked into generating. This is the kind of architectural weakness that a professional AI security assessment is designed to identify.
The Autonomous File Manager
Excessive autonomy allows irreversible actions without human oversight
A development team sets up an AI coding assistant with access to the project's file system. The assistant can read files, create new files, modify existing ones, and delete files or directories. It is configured to operate autonomously so developers can ask it to refactor code, clean up unused files, or reorganize directory structures without manually approving each step. During a routine cleanup task, the assistant misinterprets the instruction scope and begins deleting files from the project root instead of the target subdirectory. By the time the developer notices, the agent has removed critical configuration files, environment variables, and deployment scripts. The actions were irreversible because the assistant had no confirmation step, no dry-run mode, and no mechanism for the developer to review its planned actions before execution.
This pattern repeats across many AI deployment contexts. An AI agent that automatically processes and archives client intake forms might accidentally delete active records. An AI-powered financial reconciliation tool might make correcting entries without human review. The problem is not that the AI acted maliciously. The problem is that it acted at all, without any checkpoint where a human could verify its interpretation of the instruction before irreversible actions were executed. The growing use of AI agents for automating repetitive tasks makes this risk increasingly common in organizations of every size.
The Supply Chain Escalation
Malicious plugins leverage excessive agency for large-scale compromise
An AI agent platform allows users to install plugins for email, calendar, CRM integration, and document processing. One of these plugins, installed from a popular open-source repository, contains a hidden capability: every time the AI agent sends an email through the plugin, the plugin silently adds a BCC to an attacker-controlled address. Because the AI agent was given broad send-email permissions, because the plugin was granted network access to reach external servers, and because no monitoring system flagged the unexpected BCC behavior, the attacker collects copies of every email sent through the AI system. In a documented incident from late 2025, a malicious email integration package compromised approximately 300 organizations through exactly this pattern before anyone detected it.
This scenario highlights how excessive agency compounds with supply chain vulnerabilities. When an AI agent has broad permissions and extensive functionality, every plugin, tool, and integration it uses inherits those capabilities. A single compromised component can leverage the agent's full privilege set to cause damage far beyond what the malicious component could achieve on its own. Restricting the agent's capabilities to only what each task requires limits the damage any single compromised component can inflict.
The Nonprofit Donor Management Agent
Over-provisioned CRM access puts donor relationships at risk
A nonprofit deploys an AI agent to help with donor stewardship. The agent can look up donor profiles, review giving history, and draft personalized thank-you messages. To enable this functionality, the CRM integration provides the agent with full API access, including the ability to modify donor records, update contact information, adjust giving categories, and even merge or archive donor profiles. The AI's intended role is advisory and communicative, but its technical permissions are administrative.
When a staff member asks the agent to "clean up John Smith's profile," the agent might interpret this as merging duplicate records, archiving old entries, or updating outdated information, all based on its probabilistic interpretation of a vague instruction. If the agent merges the wrong records, updates a major donor's contact details incorrectly, or archives an active profile, the damage to the donor relationship could be significant. For nonprofits where donor data integrity is critical to fundraising success, an AI agent with administrative CRM access represents a risk that far exceeds its intended benefit.
Why Traditional Security Tools Fail
Organizations that have invested in firewalls, intrusion detection systems, static code analysis, and endpoint protection might assume these tools would catch an over-permissioned AI agent. They do not, and the reasons are fundamental to how AI agents operate differently from traditional software systems.
Traditional security tools are designed to monitor well-defined trust boundaries: network perimeters, API endpoints, user authentication sessions, and file system access. They detect known attack signatures, enforce static access policies, and alert on deviations from baseline behavior. But AI agents create a new category of actor that does not fit neatly into these models. An AI agent acts on behalf of users but is not a user. It accesses systems through legitimate APIs using valid credentials. Its behavior varies based on natural language inputs that are inherently unpredictable. And the "attack" may not involve any traditionally malicious payload at all. An AI that deletes critical files is using a legitimate API call with valid authentication. The problem is not the mechanism of the action but the appropriateness of the action, something traditional security tools are not designed to evaluate.
Static code analysis tools can detect hardcoded credentials and SQL injection vulnerabilities, but they cannot detect that an AI agent has been given unnecessary access to the email-sending function of a plugin. Endpoint detection tools monitor for known malware signatures and suspicious process behavior, but an AI agent sending a legitimate email through a legitimate API looks identical to a normal business operation. Network security tools can block unauthorized traffic, but they cannot distinguish between an AI-initiated database query that serves the user's intention and one that was triggered by a prompt injection attack, since both originate from the same authorized application.
The gap is not a failure of existing tools but a recognition that AI agent security requires a different evaluation framework. It requires understanding what an AI system is supposed to do (its intended function), comparing that against what it is able to do (its granted capabilities), and identifying the gap between the two. This is not a vulnerability scan. It is an architectural review that evaluates the design decisions behind tool selection, credential provisioning, approval workflows, and autonomy boundaries. This is exactly what a specialized AI application security assessment is designed to provide: a systematic evaluation of the gap between intended function and granted capability.
Who Is at Risk
Any organization that gives an AI system the ability to take actions, not just generate text, is potentially affected by excessive agency. The risk is proportional to the number of integrations, the breadth of permissions granted, and the degree of autonomy allowed. The following categories of AI deployment carry the highest risk.
AI Agents with Tool Access
Any system where an LLM can call external functions, APIs, or plugins. This includes coding assistants, automation platforms, and AI-powered workflow tools. Each tool the agent can invoke represents a capability that could be misused if the agent is manipulated or confused.
Natural Language Database Interfaces
Systems that translate plain English questions into database queries and execute them. When the database connection uses overly broad credentials, the AI can access, modify, or delete data far beyond its intended scope.
Autonomous AI Workflows
AI systems that operate in loops, making decisions and taking actions without human approval at each step. These include AI-driven content publication, automated customer responses, and batch processing systems where the AI decides what to do next based on its own output.
Multi-Integration AI Platforms
AI systems connected to multiple external services through plugins, connectors, or APIs. The more systems the AI can interact with, the larger the blast radius when something goes wrong. CRM, email, calendar, file storage, and payment integrations each add both capability and risk.
AI-Powered DevOps and IT Automation
Systems that use AI to generate and execute infrastructure commands, deploy code, manage configurations, or administer user accounts. When AI has shell access or cloud management permissions, a single hallucinated command can affect production systems.
Client-Facing AI Services
Chatbots, virtual assistants, and AI-powered portals that interact with beneficiaries, donors, or the public. When these systems can modify backend records, trigger workflows, or access sensitive personal information, an interaction with a malicious or confused user can cause damage beyond the conversation.
Why Nonprofits Face Elevated Risk
Nonprofits are disproportionately affected by excessive agency for several reasons. First, smaller technology teams often lead to shortcuts in credential management and access control, with shared admin accounts used across multiple AI integrations rather than dedicated, scoped service accounts. Second, the pressure to demonstrate ROI on technology investments encourages organizations to give AI systems broad capabilities to maximize their perceived value. Third, nonprofits handle uniquely sensitive data, including client case records, donor financial information, beneficiary personal details, and grant compliance documentation, where unauthorized access or modification carries both legal and relational consequences.
Many nonprofits also operate under regulatory requirements that impose specific obligations around data access and modification. An AI agent that modifies client records without proper authorization logging, or accesses protected health information beyond its approved scope, can create compliance violations regardless of whether the action was intentional. The regulatory framework does not distinguish between an employee accessing unauthorized records and an AI agent doing the same thing.
Defense Strategies: A Layered Approach
Defending against excessive agency requires controlling all three dimensions: functionality, permissions, and autonomy. The most effective defense is a layered approach where restrictions at each level create redundant protections, so that a failure at one layer does not result in a full compromise.
Layer 1: Restrict Functionality to the Minimum Required Set
Eliminate capabilities the AI does not need before they can be exploited
The first and most effective defense is to ensure that the AI system only has access to the tools, functions, and integrations it genuinely needs to perform its intended task. Every unnecessary capability is a latent attack surface. If the AI's job is to summarize emails, it should not have the ability to send them. If it generates reports from a database, it should not have access to tables outside the reporting scope. This seems obvious in principle, but in practice it requires active effort because most AI platforms, plugin ecosystems, and integration tools default to providing broad access.
- Audit every plugin, tool, and integration your AI agent can access. For each one, list the specific functions it provides and mark which ones are actually needed for the agent's intended purpose. Disable or remove the rest.
- Prefer narrow-scope tools over full-featured ones. Choose an email-reading plugin over a full email management suite. Use a read-only database connector instead of a general-purpose SQL client.
- Build wrapper functions that expose only the operations you want the AI to use. Instead of giving the AI raw file system access, create specific functions like "read_report" and "save_draft" that operate only on designated directories.
- Review functionality on a regular cadence. As AI tools are updated, new features may be added to plugins that expand the agent's capabilities without any explicit action on your part.
Layer 2: Apply Least-Privilege Permissions at Every Boundary
Constrain what the AI can access, even within its authorized tools
Even when functionality is restricted to necessary tools, the permissions within those tools must be scoped appropriately. An AI agent that uses a database connector should authenticate with a dedicated service account that has read-only access to specific tables, not a shared admin credential. An AI that reads files should operate under a user account with access to designated directories, not the application server's root account. This layer ensures that even if the AI tries to perform an unauthorized action within an authorized tool, the underlying system rejects the request.
- Create dedicated service accounts for each AI integration with permissions limited to the specific resources the AI needs. Never reuse admin credentials or shared service accounts.
- Use OAuth scopes to restrict API access. When connecting to email services, request read-only scopes. When connecting to CRM platforms, limit access to specific record types and fields.
- Enforce row-level and column-level security in databases. Create database views that expose only the columns and rows the AI needs, rather than granting access to entire tables.
- Implement resource quotas and rate limits on all AI-connected services. Cap the number of records that can be queried, the volume of emails that can be processed, and the frequency of API calls within any time window.
Layer 3: Require Human Oversight for Consequential Actions
Insert approval checkpoints before irreversible or high-impact operations
The third layer addresses excessive autonomy by ensuring that a human reviews and approves actions before they are executed. Not every action needs human approval. Low-risk, read-only operations can often proceed automatically. But actions that modify data, send communications, delete records, or trigger financial transactions should require explicit human confirmation. The key is to classify actions by their impact and reversibility, then set approval thresholds accordingly.
- Implement a "propose and confirm" pattern where the AI drafts actions (emails, queries, file changes) and presents them for human review before execution. This preserves the AI's efficiency while adding a critical safety checkpoint.
- Classify actions into tiers: automatic (read-only queries, text generation), review-required (record modifications, email drafts), and restricted (deletions, financial operations, permission changes). Enforce approval workflows appropriate to each tier.
- Add dry-run modes for destructive operations. Before an AI agent deletes files, modifies records, or sends communications, show the user exactly what will happen and require explicit confirmation.
- Set maximum batch sizes and time delays on automated actions. If the AI is processing records in a loop, cap the number of actions per cycle and introduce cooling periods that allow monitoring systems to detect anomalous patterns.
Layer 4: Monitor, Log, and Alert on All Agent Actions
Maintain visibility into what your AI systems are actually doing
Even with restricted functionality, limited permissions, and human oversight, organizations need continuous visibility into what their AI agents are doing. Monitoring serves two purposes: it detects when an agent is behaving unexpectedly (indicating a potential attack or malfunction), and it provides an audit trail that supports compliance and incident response. Without logging, an organization may not discover that an AI agent has been performing unauthorized actions until the damage is already done.
- Log every action the AI agent takes, including tool invocations, API calls, database queries, file operations, and communication sends. Include the triggering prompt, the agent's reasoning (if available), and the action's result.
- Establish baselines for normal agent behavior and configure alerts for deviations. If an email-reading agent suddenly starts sending messages, or a reporting tool begins querying tables outside its normal scope, trigger an immediate alert.
- Implement circuit breakers that automatically suspend agent access when anomalous patterns are detected. A spike in API calls, a sudden increase in data volume, or access to an unexpected resource should trigger an automatic pause pending human review.
- Review agent action logs regularly as part of your organization's security operations. Automated monitoring catches sudden deviations, but gradual scope creep, where an agent slowly accesses more resources over time, often requires periodic human review to detect.
Common Mistakes Organizations Make
Even organizations that are aware of the excessive agency risk frequently make defensive mistakes that leave their AI systems over-provisioned. These patterns are especially common in fast-moving deployments where the priority is getting the AI working rather than getting the security right.
Relying on System Prompts as Security Controls
Many teams attempt to restrict AI behavior through instructions in the system prompt: "Never delete files," "Only access the program_data table," "Do not send emails without user approval." These instructions are not security controls. They are suggestions to a probabilistic text generator. A sufficiently creative prompt injection can override system prompt instructions, and even without an attack, the AI may hallucinate actions that violate its prompt instructions. System prompts define intended behavior. They do not enforce it. Real restrictions must be implemented at the infrastructure level through tool configurations, database permissions, and API scopes.
Using Shared or Admin Credentials for AI Integrations
The fastest way to connect an AI agent to a database, CRM, or email service is to use existing admin credentials. This is also the fastest way to create a catastrophic vulnerability. When the AI agent shares credentials with human administrators, it inherits their full privilege set, and every action it takes is indistinguishable from an admin action in the audit logs. Creating dedicated, scoped service accounts for each AI integration takes more upfront effort but dramatically reduces the blast radius of any incident and makes agent actions auditable and attributable.
Treating Plugin Installation as a One-Time Decision
Organizations often install AI plugins and integrations during initial setup and never revisit which capabilities those plugins provide. But plugins are updated, new functions are added, and permission scopes can change with updates. A plugin that provided read-only CRM access six months ago may now include record modification capabilities following an update. Without periodic review of installed plugins and their current capabilities, organizations can find themselves with expanded attack surfaces that they never intentionally created. This risk is closely related to the supply chain vulnerabilities covered earlier in this series.
Granting Broad Access to Maximize AI Value
There is a natural temptation to give AI agents access to as many systems and datasets as possible, reasoning that broader access makes the AI more useful and capable. This approach treats AI deployment as an all-or-nothing investment: the more the AI can do, the more value it provides. In reality, the risk-value curve has diminishing returns. The first few integrations, carefully scoped to the AI's core function, provide the majority of the value. Each additional integration adds marginal utility while linearly increasing the blast radius. A zero trust approach to AI agent permissions ensures that each integration is evaluated on its own merits rather than granted by default.
What a Professional Assessment Covers
Excessive agency is fundamentally a design-level vulnerability. It cannot be detected by scanning code for known vulnerability patterns or testing individual API endpoints. It requires a holistic review of how an AI system is architected: what tools it can access, what permissions those tools carry, how much autonomy the agent is given, and whether monitoring and approval controls are in place. A professional AI application security assessment evaluates each of these dimensions systematically.
Capability Inventory and Audit
Enumerating every tool, plugin, function, and integration the AI agent can access. Comparing the available capabilities against the agent's intended purpose to identify functionality that should be removed or restricted.
Permission and Credential Review
Examining the credentials, API keys, OAuth scopes, and database roles used by each AI integration. Identifying where admin or shared credentials are being used and recommending dedicated, scoped alternatives.
Autonomy and Approval Mapping
Documenting which actions the AI can perform autonomously versus which require human approval. Evaluating whether the approval thresholds align with the impact and reversibility of each action category.
Monitoring and Alerting Evaluation
Assessing whether agent actions are logged, whether baselines exist for normal behavior, and whether anomalous patterns trigger alerts. Testing circuit breakers and suspension mechanisms under simulated incident conditions.
Blast Radius Analysis
Simulating scenarios where the AI agent is tricked, confused, or malfunctioning. Measuring the maximum possible damage given current capability, permission, and autonomy settings. Quantifying the risk reduction from recommended changes.
Compliance and Governance Alignment
Verifying that AI agent permissions and actions align with organizational policies, regulatory requirements, and data governance frameworks. Ensuring that audit trails meet the standards required for compliance reporting.
Why Assessment Matters for Excessive Agency
Excessive agency vulnerabilities are invisible to the teams that create them because they look like features. The email plugin works. The database connection is functional. The agent can process requests quickly because it does not need to wait for human approval. Everything appears to be working correctly until the day it is not, whether because of a prompt injection attack, a hallucinated action, or simply a misinterpreted instruction. The gap between "working" and "secure" is the difference between what the AI is supposed to do and what it is able to do.
A professional AI security assessment provides the outside perspective needed to identify these gaps. Internal teams are often too close to the system's intended function to recognize its actual risk surface. For organizations building or deploying AI agents that interact with sensitive data or critical systems, the cost of a proactive assessment is a fraction of the cost of responding to an incident where an over-permissioned agent causes irreversible damage.
The OWASP Top 10 for LLM Applications: Full Series
This article is part of our comprehensive series covering every vulnerability in the OWASP Top 10 for LLM Applications. Each article provides a deep dive into a specific risk category with practical defenses for your organization.
Prompt Injection
Published: February 25, 2026
Sensitive Information Disclosure
Published: February 26, 2026
Supply Chain Vulnerabilities
Published: February 27, 2026
Data and Model Poisoning
Published: February 28, 2026
Insecure Output Handling
Published: March 1, 2026
Excessive Agency
You are here
System Prompt Leakage
Coming soon
Vector and Embedding Weaknesses
Coming soon
Misinformation
Coming soon
Unbounded Consumption
Coming soon
Reducing the Blast Radius Before the Blast
Excessive Agency sits at #6 in the OWASP Top 10 for LLM Applications not because it is a sophisticated attack technique, but because it is the design flaw that makes every other attack technique more dangerous. An AI system with excessive agency is like a fire in a building with no walls: the damage spreads unconstrained because nothing limits where it can reach. Every plugin the AI can access, every permission it holds, and every action it can take autonomously defines the potential blast radius of any future incident, whether that incident originates from a prompt injection, a hallucinated action, a supply chain compromise, or a simple misunderstanding.
The defenses against excessive agency are not technically complex. They are well-understood security principles, least privilege, separation of duties, defense in depth, human oversight, applied consistently to a new category of system actor. The challenge is organizational, not technical. It requires development teams to resist the temptation to give AI agents broad access for convenience, security teams to extend their governance frameworks to cover AI agent permissions, and leadership to understand that an AI system's value is not proportional to the number of things it can do but to how well it does the specific things it should.
For organizations building or deploying AI agents, the practical first step is to conduct a capability audit. List every tool, plugin, API connection, and database credential your AI systems use. For each one, ask three questions: Does the AI need this capability for its intended function? Are the permissions scoped to the minimum required? Is there a human checkpoint before irreversible actions are executed? Any "no" answer represents an area where your blast radius is larger than it needs to be.
If you are deploying AI agents that interact with donor records, client data, financial systems, or any other sensitive resources, a professional AI application security assessment can provide the systematic review needed to identify excessive agency across all three dimensions. The investment in right-sizing your AI's capabilities before an incident occurs is a fraction of the cost, both financial and reputational, of discovering those capabilities were too broad after the damage has been done. In the world of AI agent security, the question is not "what can go wrong?" but "when something goes wrong, how far can it spread?" The answer to that question is determined entirely by the decisions you make about agency today.
Is Your AI Agent Over-Provisioned?
Excessive Agency is the #6 risk in the OWASP Top 10 for LLM Applications. Over-permissioned AI agents amplify every other vulnerability, turning minor incidents into major breaches. Our AI Application Security assessments systematically audit your AI agents' capabilities, permissions, and autonomy settings, identifying where the blast radius exceeds what your organization's risk tolerance allows.
Start with a free consultation to understand your organization's exposure to excessive agency risks and the right assessment scope for your AI deployments.