Decionis
Standards mapping

Decionis mapped to OWASP LLM06: Excessive Agency

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.

Mitigation 6 is where most systems fail

“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:

93%

of permission prompts are approved by Claude Code users — measured by Anthropic, in a post about reducing permission fatigue.

Anthropic Engineering · 25 Mar 2026
1 in 3

genuine 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 2026

Policy-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.

All eight mitigations

  • LLM06.1

    Minimize extensions

    Not our layer

    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.

  • LLM06.2

    Minimize extension functionality

    Not our layer

    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.

  • LLM06.3

    Avoid open-ended extensions

    Decionis contributes

    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.

  • LLM06.4

    Minimize extension permissions

    Not our layer

    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.

  • LLM06.5

    Execute extensions in user's context

    Decionis contributes

    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.

  • LLM06.6

    Require user approval

    Decionis is a control

    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.

  • LLM06.7

    Complete mediation

    Decionis is a control

    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.

  • LLM06.8

    Sanitise LLM inputs and outputs

    Not our layer

    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.

See a verdict, then verify it yourself

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.