Answer capsule
An agent's safety boundary is shaped by the functions, permissions, and autonomy it receives—not by the fluency of its interface.
What the source establishes
- The OWASP Top 10 for LLM Applications 2025 includes Excessive Agency as a distinct application risk.
- OWASP connects excessive agency to excessive functionality, excessive permissions, and excessive autonomy.
- The project recommends minimizing extensions, permissions, and autonomous actions to what the application actually needs.
- OWASP is community security guidance, not a certification or proof that an implementation is secure.
Model the agent as a workload identity
A production agent is not merely a chat window with better answers. Once it can read systems, call tools, create records, send messages, alter configurations, or trigger transactions, it behaves like a workload identity operating across an enterprise boundary. The CIO should require an inventory that connects each agent to its owner, purpose, approved tools, data domains, credentials, environments, and prohibited actions. This makes excessive agency visible before a prompt injection, ambiguous instruction, or software defect turns a plausible response into an unauthorized enterprise action.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Separate functionality from permission
A connector may expose dozens of operations even when one workflow needs only two. Giving the agent the full connector and relying on instructions to avoid the rest collapses application design into prompt discipline. Reduce the functions presented to the model, then give the execution identity only the data and actions required for the approved task. Separate read, draft, approve, and execute capabilities; scope credentials to a tenant and environment; and keep sensitive administration outside the agent path. A narrow tool surface also makes evaluation and incident analysis more tractable because the possible action set is bounded.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Place autonomy behind consequence thresholds
Not every correctable action needs the same approval. Retrieval or a reversible draft may run automatically, while external communication, financial commitment, production change, personnel decision, or destructive operation may require a named human checkpoint. Define those thresholds in policy and enforce them in the application, not solely in natural-language instructions. The approval screen should show the proposed action, target, material inputs, and expected effect so the reviewer can make a real decision. Rate limits, transaction ceilings, time windows, and two-person controls can further contain impact when an agent behaves outside expectation.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Test the path from instruction to effect
Traditional access review asks who has a permission. Agent review must also ask how untrusted content, retrieved material, tool output, or a user's phrasing could influence use of that permission. Exercise indirect prompt injection, confused-deputy scenarios, cross-tenant references, stale approvals, tool errors, retry loops, and attempts to invoke hidden operations. Log the instruction, policy decision, tool call, target, response, approval, and resulting state in a form operations teams can reconstruct. Passing an OWASP-inspired test is evidence about tested conditions; it is not a security certificate or a substitute for threat modeling the deployed architecture.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Decision test
Ask whether the source changes the decision itself, the evidence required, the implementation sequence, or only the language used to describe an existing capability. Record which claims are directly supported, which are provider statements, which require an independent test, and which remain unknown. A source-linked review should make uncertainty easier to see, not bury it inside a blended score.
Questions to take into review
- Whose authority is the agent exercising?
- Can each tool call be attributed and reversed?
- What actions can the assistant execute?
- Which record remains authoritative for incident and change state?
- Which telemetry is missing or sampled?
- Can the model change production or only advise?
- Which services are common and which remain workload-specific?
- How can a team change a model without rewriting the application?
The publication supports research and executive decision preparation. It does not provide legal, financial, accounting, employment, clinical, cybersecurity, investment, procurement, or implementation advice.