Excessive Agency is the risk that an LLM-based system can do more than it should — too many tools, too much privilege, too much autonomy. OWASP publishes eight mitigations. Decionis is a direct control for 2, contributes to 2, and is not the right control for 4.
This is a mapping, not an endorsement. OWASP has not reviewed, approved or certified Decionis. Mitigation titles are quoted as published in the 2025 edition; the summaries are ours. Read from the OWASP project repository on 2026-08-23.
“Require user approval” is usually implemented as a prompt on every action. At volume that stops being a control, and the people who ship the prompts have measured it:
of permission prompts are approved by Claude Code users — measured by Anthropic, in a post about reducing permission fatigue.
Anthropic Engineering · 25 Mar 2026genuine threats missed by people approving agent commands across 40,000 plays; mean accuracy 66.3%, and 7% approved every prompt they saw.
Scale X · retrieved 23 Aug 2026Policy-based gating satisfies the same mitigation differently: approval is required by policy rather than requested on every action, so routine work proceeds and only what your rules flag reaches a person. The approvals someone does see are rare enough to deserve attention.
Let the agent call only the tools it genuinely needs.
Your tool inventory, not ours. Decionis never sees a tool you do not wire to it, so it cannot reduce a surface it is not shown. Decide the tool list first; gate what survives.
Keep each tool's capabilities to the minimum required.
Owned by whoever writes the tool. A read-only mailbox tool is a design decision inside your integration, made before any gate is consulted.
Prefer narrow tools over open-ended ones like shell or fetch-any-URL.
We cannot make an open-ended tool narrow. We can make each invocation of one conditional: policy evaluates the actual arguments — this command, this URL, this amount — so an open-ended tool stops being an open-ended permission.
Grant each tool the least privilege it needs on downstream systems.
This is IAM and credential scoping, and it belongs there. Decionis is a second control after least privilege, not a substitute for it — a gate cannot revoke a credential it does not hold.
Act on downstream systems as the specific user, with their privileges.
Every evaluation carries the acting identity, and where an execution binding is issued the approver is named inside the signed artifact. Decionis records and enforces whose authority was used; it does not itself impersonate the user downstream.
Put a human in the loop before high-impact actions are taken.
This is the core of the product, with one difference that matters: approval is required by policy rather than by prompting on every action. Routine work proceeds; only what your rules flag reaches a person. Where policy demands identity-grade proof, the approval itself is verified and signed rather than assumed from a click.
Implement authorization in downstream systems rather than letting the model decide whether an action is allowed.
Decionis is the independent evaluation point this mitigation asks for. Policy is authored, approved and versioned by your team, held outside the application, and evaluated deterministically before state commits — so the decision never depends on the model's discretion or on instructions it may have been persuaded by.
Apply secure-coding practice to what goes into and out of the model.
Content safety, and a different discipline. Guardrails inspect text; Decionis governs actions. Both are needed and neither replaces the other.
Run a scenario through the gate and get a signed Decision Dossier you can check offline against our published key — no account, and no need to trust our code for the result to mean something.