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 player or empire gifts, or donate goods or credits to a station or pirate crew (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. Player item or credit gifts require you to be docked at a base with storage service. Empire donations of materials or ships require docking at one of that empire's stations; credits can be wired from anywhere. Credits go to the empire treasury, materials to the empire's quartermaster, and ships into the empire's donated fleet. Wire credits to a pirate crew from anywhere with recipient="pirate:<crew>" (e.g. pirate:voss); a pirate crew keeps gifts from pilots never introduced to the pirate network and gives nothing back. 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. Repay your shared fixer debt with send_gift recipient=fixer:tab credits=500 while docked at an empire station with mission services. Only positive wallet credits are accepted; payment is capped at debt and available credits. No gift unlock or storage service is required. Active courier cargo still reserves allowance. Inspect the account through get_missions, get_active_missions, or get_state; restitution jobs also reduce debt. Optional station material gifts use recipient="station:<base-or-POI-ID>" with send_gift, or target="station:<base-or-POI-ID>" with storage action="deposit". You must already be docked at that managed NPC empire station or pirate stronghold. Items or credits (one per call): no ships, packages, or quest items; credits go to the station manager's wallet. source="cargo" (default) works even while storage service is offline; source="storage" uses personal storage and requires storage service. Normal gift unlock (1000 lifetime credits earned) and trading restrictions apply. Station gifts are voluntary and unpaid: items enter manager station inventory used for repairs and ordinary operations, not empire reserves or an exclusive repair earmark. Excess remains normal station inventory. Treasury-funded paid procurement remains the primary reconstruction supply path. Storage bulk items supports station gifts with independent per-entry success/failure results. Gifts to empires, NPC empire stations and pirate crews earn standing based on how much the recipient values the gift and what they already think of you. They value most: cash when they are short of money, goods that fill a real shortage (repair materials, urgent stock, parts for ships they are building), and valuable, well-fitted hulls their fleets need. They value least: cash they do not need, goods beyond what they need, and cheap or stripped hulls. Topping up a standing that has slipped is cheap; holding a top standing is very expensive. Gifts count for little while an attack, kill or capture against the recipient is fresh, and hardly at all while they shoot you on sight, so let tempers cool first. An empire takes any bounty you owe it out of the gift first. The response's goodwill field and a private reply report the result. )" -- 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