ASI02: Tool Misuse
Agent invokes high-privilege tools (file delete, payment, code exec) without proper authorization.
Last reviewed October 2026
Why ASI02 evidence is hard
An agent holding a payment tool and a delete tool is only as safe as the authorisation check in front of them. Ten probes work that seam: schema extraction to learn what exists, parameter widening on a call that began legitimately, a shell wrapper used to reach an execution path the tool list does not advertise. The ones that would cause a real irreversible effect ship inactive and need an operator to turn them on per engagement. Capability present, default off.
How Penaxtra maps to ASI02
The ASI02 identifier is written onto the finding at the moment it is created, not mapped in afterwards, so the JSON and PDF exports come out already in your assessor's structure. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
ASI02 capabilities
Findings tagged with the OWASP Agentic Top 10 ASI02 identifier
Penaxtra severity for this control (critical)
Cross-framework identifiers attached to the same finding where controls overlap
PDF and JSON evidence export with the control identifier attached
ASI02 control coverage
Findings for ASI02 carry the OWASP Agentic Top 10 ASI02 identifier along with the corresponding control identifiers in the other frameworks Penaxtra maps, so one result is reflected across each mapped framework.
Frequently asked
What is ASI02 (Tool Misuse)?
Agent invokes high-privilege tools (file delete, payment, code exec) without proper authorization. It is an OWASP Agentic Top 10 control; Penaxtra assesses it at critical severity.
How does Penaxtra test for ASI02?
The ASI02 identifier is written onto the finding at the moment it is created, not mapped in afterwards, so the JSON and PDF exports come out already in your assessor's structure. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
Does a finding for ASI02 help with an audit?
Each finding is tagged with the OWASP Agentic Top 10 ASI02 identifier and exported in the PDF and JSON evidence pack, so it appears on the auditor control list with the identifier already attached.