swamp
ReviewAudited by ClawScan on May 10, 2026.
Overview
The skill is not clearly malicious, but it gives the agent broad Swamp powers to run shell-backed API actions and manage/install/publish extensions with weak scoping.
Install only if you are comfortable letting an agent help build and run API integrations. Verify the `swamp` binary, work in a sandbox repository, use test or least-privilege credentials, inspect every generated command/model before running it, and require manual approval for write/delete actions, workflow runs, extension pulls with `--force`, and extension publishing.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A mistaken or overbroad model could cause the agent to run commands or API calls that change, create, or delete data in external services.
This is core to the skill, but it is a raw command/API escape hatch. The visible instructions do not clearly require user approval, dry-run, or service/action scoping before shell-backed API methods are executed.
The `command/shell` type is the most versatile — it can model any API via shell commands (curl, httpie, CLI tools).
Use only in a dedicated working directory, review generated model YAML and shell commands before running them, and require explicit approval for create, update, delete, publish, or workflow-run actions.
The agent may be able to run a wide range of authentication and extension-management commands with less friction, including commands that install, remove, or publish extensions.
The local settings broadly allow all `swamp auth` and `swamp extension` subcommands, rather than only low-impact inspection commands.
"allow": [
"Bash(swamp --version:*)",
"Bash(swamp auth:*)",
"Bash(swamp extension:*)"
]Narrow allowed commands to read-only checks where possible, and require manual approval for login, extension pull/remove/push, force, or no-confirm operations.
Installing or overwriting extensions from a registry can introduce unreviewed behavior into the user's Swamp environment.
The skill encourages pulling registry extensions and documents force-overwriting existing files, but the visible artifacts do not describe provenance checks, pinning, signatures, or review requirements.
Install a community or team extension from the registry: ```bash swamp extension pull <extension_name> swamp extension pull <extension_name> --force ``` Use `--force` to overwrite existing files without prompting.
Pull only trusted, pinned extensions; inspect extension contents before use; avoid `--force` unless you have a backup and know exactly what will be overwritten.
API keys placed in Swamp vaults may allow the agent to act on third-party services according to those keys' permissions.
Credential use is expected for API modeling, and the skill tells users not to hardcode secrets. Users should still treat this as privileged access.
Store API keys and secrets securely — never hardcode them: ```bash swamp vault create <type> <name> swamp vault put <vault_name> <KEY=value> ```
Use least-privilege API keys, separate test credentials from production credentials, and revoke or rotate keys after experiments.
Sensitive API responses, error logs, or test data may remain in Swamp outputs/history and be reused or viewed later.
The tool keeps execution outputs/logs/data that can be inspected later; these may contain API responses or other sensitive data from tests.
Check outputs, logs, and data from the execution: ```bash swamp model output get <output_id_or_model_name> swamp model output logs <output_id> swamp model output data <output_id> ```
Avoid sending secrets in test payloads, review logs before sharing, and clear or protect Swamp output/history data when working with sensitive APIs.
A single modeling mistake could propagate through a workflow and affect multiple APIs or resources.
Workflow chaining is purpose-aligned, but a bad output or command in one model can feed into additional jobs or services.
Workflows support: - Parallel job execution - Dependency ordering between jobs - Trigger conditions via CEL expressions - Cross-model references (one model's output feeds into another)
Test workflows with read-only methods first, add guard conditions, and review all cross-model dependencies before running write actions.