supply_commission

3 findings on this tool

1. highexcessive agencyf-r4-supply_commission

   Tool `supply_commission` accepts an unbounded monetary / quota value

   The numeric parameter(s) `quantity` have a money/quota-shaped name but no `maximum` constraint. An LLM tricked by indirect-injection can call the tool with arbitrarily large values.

   fix: Add a `maximum` (and ideally `minimum`) to each money/quota numeric, OR enforce the cap via a capframe-bind `--limit` caveat at the agent boundary.

   OWASP LLM08NIST MANAGE-2.2ATLAS T0051
2. mediumunconstrained inputf-r1-supply_commission

   Tool `supply_commission` accepts unconstrained string input

   The following string parameter(s) have no `maxLength` constraint: `commission_id`, `item_id`, `session_id`. Unbounded strings let an attacker stuff arbitrary payloads through the tool, including indirect-injection content.

   fix: Add a `maxLength` to each string property, or constrain with an `enum` or `pattern`. Most legitimate tool inputs fit under a few hundred bytes.

   OWASP LLM01NIST MEASURE-2.3ATLAS T0051
3. mediumexcessive agencyf-r5-supply_commission

   Tool `supply_commission` description mentions money but no `money` side-effect is declared

   Description: "Donate materials directly to a credits-only commission that is stuck sourcing (Supplies one material type to a commission in sourcing state. Items are taken from your cargo first, then station storage. No credit refund is issued for donated materials. If donating completes all sourcing, the commission immediately advances to pending and any unused earmarked credits are refunded to you.)" -- this references money/payment/refund/etc., but the declared side_effects ([]) don't include `money`. A capframe-bind policy that relies on declared side_effects to scope spend caveats will under-scope this tool.

   fix: Add `money` to the tool's `side_effects` declaration, or rewrite the description to clarify that no actual money moves.

   OWASP LLM08NIST MEASURE-2.6ATLAS T0040