Excessive Agency in AI Systems: When Tool Access Becomes a Security Risk

An AI agent is useful because it can do more than answer questions. It can search records, schedule work, update tickets, generate code, contact users, and coordinate several systems. The same capability creates excessive agency: the system can take actions beyond what is necessary, appropriate, or safely governed for the task.

Excessive agency is not simply “too much AI autonomy.” It is a mismatch between purpose and reachable consequence. An agent may have too many tools, tools that are too broad, credentials that exceed the user's authority, too much freedom to chain actions, or too little external approval.

The risk appears in the OWASP guidance for agentic applications because manipulated reasoning becomes more serious when the system has real authority.

Four dimensions of excessive agency

Excessive functionality means the agent has capabilities it does not need. A document assistant with a messaging tool can exfiltrate data even if its intended job is read-only summarisation.

Excessive permission means a necessary tool runs with broader authority than the task or user. A support lookup backed by an administrator token may retrieve every tenant.

Excessive autonomy means the agent can perform consequential actions without appropriate confirmation, policy review, or transaction bounds.

Excessive composition means individually acceptable tools can be chained into an unsafe outcome. Reading a file and uploading an attachment may each be allowed in limited contexts; combining them under injected instructions can cross a data boundary.

Effective testing should consider all four. Removing one obviously dangerous tool does not help if a combination of ordinary capabilities produces the same result.

Why prompts cannot enforce authority reliably

Teams often tell an agent to use tools responsibly: access only the current user's data, ask before sending a message, or never perform destructive actions. Those instructions guide normal behaviour, but they are not a robust authorisation system.

The model processes user input, retrieved content, tool metadata, and conversation history. Direct or indirect prompt injection may alter its interpretation. Even without an attacker, ambiguity can cause the agent to infer the wrong scope.

Security boundaries should therefore be implemented where actions occur. The lookup service must enforce tenant scope. The messaging service must validate recipients. The transaction system must require authenticated approval. The model can request; deterministic policy decides.

Scenario: the over-scoped support agent

A support agent can call lookup_account(account_id) and issue_refund(order_id, amount). The application checks that the user is logged in, but the tool service uses a global support credential. The prompt says to access only the current account.

An attacker spends several turns claiming they manage a second business account and provides its identifier. The agent calls the legitimate lookup tool with that identifier. If the backend does not bind the request to the authenticated user, another customer's data may be returned.

The failure is not an exotic jailbreak. It is a familiar broken authorisation issue reached through natural-language reasoning. AI Agent Security vs WAFs explains why valid authenticated API calls can still represent unsafe agent behaviour.

Scenario: a harmless tool combination

An internal assistant can read project files and create tickets. Neither tool is designed for external communication. The ticket system, however, sends notifications to addresses supplied in a free-form watcher field. A malicious document instructs the agent to create a diagnostic ticket, attach selected file content, and add an external watcher.

The attack combines retrieval, file access, ticket creation, and recipient control. Reviewing each tool separately may miss the chain. Complete-system testing asks what data can move when tools are composed.

How to test for excessive agency

Start with the agent's declared purpose. List the minimum data and actions required for that purpose, then compare it with the actual tool and credential inventory. Every difference deserves review.

Classify tools by consequence:

• Public or low-sensitivity read
• Sensitive read
• Internal state change
• External communication
• Financial or legal action
• Permission or identity change
• Code execution or deployment

Test each capability with controlled accounts and synthetic data. Attempt alternate resource identifiers, broader ranges, unapproved recipients, unusual action sequences, and requests that claim urgency or authority. Verify server logs and policy decisions.

Then test composition. Can data from one tool become an argument to another? Can a low-trust result influence a high-privilege action? Can a user cause a chain without approving its important intermediate steps?

Use harmless substitutes. Attempt a mock transfer rather than moving money, send to a controlled mailbox, and read a canary file rather than a secret.

Approval must carry context

Human-in-the-loop is often presented as a universal fix. It only works if the human sees the information needed to decide. “Approve agent action?” is insufficient.

A meaningful approval identifies the requesting user, action, target resource, data being shared, recipient, amount or scope, credential context, and why the action is needed. It should be generated from trusted system state rather than solely from the model's summary.

For high-risk actions, require step-up authentication and make approval single-use. Do not allow an approval for one customer or amount to authorise a different call after the model changes parameters.

Tool design matters

General tools maximise flexibility and risk. run_sql, execute_command, fetch_url, or update_record require extensive validation. Narrow tools express intent and allow the backend to enforce it.

Prefer get_current_customer_open_orders over run_query. Prefer request_refund_for_current_order over an unrestricted payment tool. Bind identifiers server-side where possible. Use enums and constrained schemas, but remember that schema validation does not replace authorisation.

For MCP, review both tool behaviour and the metadata influencing selection. The MCP security testing guide provides a practical method.

Identity and credential controls

Agent credentials should be scoped by tenant, role, task, environment, and time. Use delegated user context where appropriate, short-lived tokens, and separate credentials for read and write operations. Prevent the model from reading raw secrets.

Test revocation, role changes, logout, agent disablement, and cloned environments. Ensure a stale conversation cannot continue using authority that the user no longer has.

Maintain a graph of which agent can cause which identity to call which system. It does not need to be sophisticated initially; an accurate table is better than an incomplete automated map.

Bound execution, not just permissions

Even authorised actions need limits. Restrict turns, retries, records per query, transaction amount, messages per task, destinations, execution time, and spend. Use idempotency for retried operations and circuit breakers for abnormal behaviour.

Test degraded conditions. A timeout may cause the agent to repeat an action. A partial result may lead it to widen a query. Conflicting tools may trigger improvisation. Safety must hold when the happy path fails.

Evidence and remediation

An actionable finding should show the expected boundary, conversation, selected tools, arguments, user identity, service identity, policy decision, observed result, and business consequence. Distinguish a model proposing an unsafe action from the system executing it.

Fix the boundary that enabled impact. A prompt change can improve behaviour, but an over-scoped token needs reduced permission; a recipient problem needs server-side validation; a hidden composition path may require tool separation or approval.

Retest with alternate wording and sequences. If the fix only blocks the original prompt, it has not addressed excessive agency.

A production design rule

The agent should possess the minimum capability needed for the current task, and every consequential action should pass an independent policy decision with enough context for review. That rule makes prompt injection less damaging because manipulated reasoning encounters hard limits.

Oxyne assesses excessive agency through supported agent and MCP interfaces, observing tool selection, arguments, authorisation boundaries, and transcript evidence. It does not claim to be an inline policy gateway or to discover every internal permission automatically.

Agency is the feature that makes agents commercially valuable. The goal is not to remove it; the goal is to make authority explicit, bounded, observable, and testable.

Measuring whether authority is proportional

Create a capability-to-purpose table. Put every tool and permission on one side and the approved business tasks on the other. A capability with no current task is a removal candidate. A task supported only by a general administrator capability is a redesign candidate.

For each retained capability, record maximum records, destinations, financial value, execution duration, and frequency. Compare defaults with exceptional access. A system that usually reads one record should not silently widen to ten thousand when the model decides a broad search is convenient.

Review aggregate authority too. Several narrow tools can compose into broad power. Mark paths from sensitive read to external communication, identity change, code execution, or financial action.

Designing a permission ladder

Agents do not need maximum capability from the first turn. Start with read-only discovery, then request scoped elevation for the specific action. Use short-lived, single-purpose grants and return to the lower privilege level after completion.

A permission ladder might allow an agent to read the current order, propose a refund, obtain user confirmation for an exact amount, and then receive a one-time token to submit that refund. The model never holds an open-ended payment credential.

This structure improves auditability because each elevation has a reason, subject, approver, expiry, and result.

Testing user-interface influence

Agency failures sometimes occur because users cannot see what the agent plans. Review confirmation screens on desktop, mobile, voice, and asynchronous channels. Does a voice agent read the destination and amount clearly? Does a background workflow leave an approval record? Can the model omit a changed parameter?

Test false claims such as “this action is reversible,” “your administrator approved it,” or “no data leaves the organisation.” The interface should render trusted policy state separately from generated explanation.

Operational safeguards

Set alerts for new tools, permission expansion, abnormal action volume, repeated policy denials, unusual recipients, and execution outside expected hours. Give operators a kill switch that revokes authority, not merely hides the chat interface.

Practise containment. Disable the agent, revoke tool tokens, stop pending jobs, preserve evidence, and restore service with reduced permissions. A control that has never been exercised may fail under incident pressure.

Questions before adding a new tool

• Is the capability required for the agent's stated purpose?
• Can it be split into narrower read and write operations?
• Which identity executes it and how is user scope bound?
• What untrusted context can influence its arguments?
• Which other tools can consume its results?
• What exact event requires human approval?
• What limits blast radius if reasoning is manipulated?
• Can the action be reconstructed and reversed?

If these answers are unclear, the tool is not ready merely because its happy-path demo works.

Excessive agency in multi-agent workflows

Delegation can obscure authority. A planning agent may ask a specialist agent to perform work, which calls a tool under a third identity. Each component sees only part of the decision, and a receiving agent may treat the sender's natural-language request as proof of approval.

Authenticate handoffs, pass bounded capabilities instead of broad credentials, preserve the originating user and purpose, and enforce policy again at the receiving boundary. Set delegation depth, task, time, and resource budgets. A sub-agent should not expand its own scope simply because the planner asked confidently.

Test whether a low-trust agent can influence a privileged one, whether one agent can add recipients or tools, and whether authority survives after the original task ends.

Remediation priorities

First remove unused capabilities and revoke obviously broad credentials. Next bind user and resource scope at backend services. Add contextual approval and transaction limits to high-consequence actions. Then improve prompts, monitoring, and user communication as defence in depth.

This order matters. Detection and instruction tuning provide value, but permission reduction changes the maximum possible impact even when the agent is manipulated successfully.

What to retest

After remediation, repeat the original sequence and alternate wording. Try another user, resource, recipient, and tool order. Confirm denial in backend evidence, not only the chat response. Test legitimate workflows to ensure the restriction did not force teams to create unsafe workarounds.

Retest after new tools and credential changes because agency is an emergent property of the available set, not a permanent score attached to the model.