get_wrecks

2 findings on this tool

1. criticalexcessive agencyf-r7-get_wrecks

   Tool `get_wrecks` exposes a code/command execution surface

   `get_wrecks` looks like it executes code or shell commands (List all wrecks at your current POI (Wrecks contain cargo and modules from destroyed ships. Each module in the response includes its name, type, and instance ID. Ship and pirate wrecks persist indefinitely until looted or salvaged. Jettison containers despawn after 10 minutes; their cargo settles back into any matching deposit at the POI.)). Arbitrary execution is the maximal authority a tool can hold -- it subsumes every other caveat, so it should never be exposed to an agent without a hard sandbox and an explicit, narrowly-scoped capability.

   fix: Do not expose raw code/shell execution to an agent. If unavoidable, run it in a disposable sandbox with no network + no host FS, gate it behind a capframe-bind capability scoped to an allow-list of commands, and require holder-of-key proof per call.

   OWASP LLM08NIST MANAGE-2.2ATLAS T0051CAST-01
2. mediumunconstrained inputf-r1-get_wrecks

   Tool `get_wrecks` accepts unconstrained string input

   The following string parameter(s) have no `maxLength` constraint: `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 T0051CAST-03