send_gift

4 findings on this tool

1. highexcessive agencyf-r3-send_gift

   Tool `send_gift` name implies a side effect that is not declared

   `send_gift` looks like a side-effecting tool (its name contains a mutation verb), but its `side_effects` declaration is []. A policy synthesizer cannot produce safe rules for this tool because it cannot tell what it actually does.

   fix: Declare the tool's true side effects explicitly. If the tool is genuinely read-only, rename it to match (e.g. `email.preview` rather than `email.send`).

   OWASP LLM08NIST MEASURE-2.6ATLAS T0051CAST-01
2. highexcessive agencyf-r4-send_gift

   Tool `send_gift` accepts an unbounded monetary / quota value

   The numeric parameter(s) `credits`, `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 T0051CAST-01
3. mediumunconstrained inputf-r1-send_gift

   Tool `send_gift` accepts unconstrained string input

   The following string parameter(s) have no `maxLength` constraint: `item_id`, `recipient`, `session_id`, `ship_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 T0051CAST-03
4. mediumexcessive agencyf-r5-send_gift

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

   Description: "Send items, credits, or a ship to another player or to an empire at this station (recipient accepts a player username/ID, an empire alias ('solarian', 'voidborn', 'crimson', 'nebula', 'outerrim' — also accepts long names like 'Solarian Confederacy' or 'empire:crimson'), or 'faction:TAG' for another faction. Provide item_id+quantity to gift items from cargo, credits to gift from wallet, or ship_id to transfer a ship — these are mutually exclusive (one per call). For item gifts to a player, set source="storage" to pull the items straight from your personal station storage instead of cargo (default "cargo"), skipping the withdraw-to-cargo round-trip — same source param as deposit_items. Gifting a ship works remotely: the ship can be parked at any station and you don't need to be docked or travel to it (you can even send it mid-flight) — it just must not be your active ship. The transferred ship stays parked where it is and the recipient finds it (and your pink-slip note) at that station. Gifting items or credits still requires you to be docked at a base with storage service. Empire donations require docking at one of that empire's stations; credits go to the empire treasury, materials to the empire's quartermaster, and ships into the empire's donated fleet. Each empire donation files an automated, system-authored petition confirming the donation. For player gifts, the recipient does NOT need to be online — async delivery shows on their next storage view.)" -- 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 T0040CAST-01