Shannon

The scan worker runs as a dedicated non-root user in its own container and receives only the selected provider's API key, not the operator's home directory, cloud credentials or other providers' keys. Inside that container nothing narrows the key further: it stays in the worker's process environment and the model's bash tool is spawned with that full environment, so any command the model runs can read it. Target login credentials and TOTP secrets exist only when the operator supplies a config file. A hijacked agent can therefore spend or exfiltrate the one provider credential, but not reach other systems with it.

There is no approval step anywhere between the model and the shell or the target. Main agents get bash, edit and write plus the exploitation prompts run live attacks by default, and sub-agents get the same shell. The only human-facing gates are an authorized-use banner at launch and confirmations on stop/reset commands. Effects on the target (created users, modified or deleted data) cannot be undone by the tool; local deliverables are git-checkpointed and the scanned repo is read-only.

Agents are given a raw bash tool and a browser/curl path to any host, with no argument validation beyond a required 1-600 second timeout on each bash call. Scope (which host to attack, rules of engagement) is stated in the prompt only. The one code-enforced restriction is an optional path deny list (code_path avoid rules) delivered through a third-party permission extension; it applies to file tools and recognised bash file commands, and its loading is not tamper-resistant. A separate task-formation step does use a copied, jailed source tree with a fixed read-only tool allowlist.

Model-run commands execute inside a per-scan Docker container started by the CLI, as a non-root user, with the scanned repo mounted read-only and no unsandboxed fallback if Docker is missing. The container is not hardened beyond that: Docker's default seccomp profile is turned off for the whole container, no capabilities are dropped, there are no memory, CPU or PID limits, and egress is unrestricted. The sandbox environment holds the model provider key, mounts every scan workspace read-write (world-writable on the host), and shares a network with an unauthenticated Temporal dev server, so a hijacked command can read the key and reach the control plane or other scans' data.

The agent's job is to read hostile content: live responses from the target application and the target's source code. Nothing in code separates that content from instructions or limits what a hijacked agent can do after reading it. The same agents that read it hold an unrestricted shell, unrestricted network access and the provider key, and run unattended, so a successful injection could both exfiltrate the key or workspace data and take irreversible actions against the target. The project's own safety doc warns against pointing it at adversarial codebases.

Shannon keeps no long-term memory (sessions are in-memory), but its main and child agents are built on a pi resource loader created with the scanned repository as working directory and none of the options that turn off project-level loading. Under the pinned pi version that means the repo's AGENTS.md/CLAUDE.md files and .pi/SYSTEM.md load automatically with no workspace-trust decision; other repository-supplied resources are not integrity-protected either. Only the task-formation and SAST sessions disable project-level loading. Phase hand-off files in the deliverables directory also carry earlier agents' output (including target-derived content) into later agents.

The extensions Shannon ships are few and pinned: an in-repo bash-timeout extension and the pi-permission-system package, resolved from a lockfile with integrity hashes and installed with a frozen lockfile at image build; the Playwright CLI is pinned by version without a hash. Runtime extension loading, however, is not integrity-protected.

In the default unauthenticated scan the only secret is the provider API key, read from the environment or from a 0600 config file on the host and forwarded by name into the container. It is not scrubbed from the model's shell environment. No telemetry or crash reporting exists. The scan log records every tool call's complete arguments with no redaction, so any password, token or TOTP secret the model types into a command lands in workflow.log; error paths, by contrast, go through a closed vocabulary rather than raw text. When the operator supplies an authenticated-scan config, target usernames, passwords and TOTP secrets are substituted directly into the agents' prompts.

Each tool call by a main agent or sub-agent is written to a per-scan workflow.log with a timestamp, an actor label and the full JSON arguments, plus delegation lines linking sub-agents to parents; success is implied rather than recorded and only failures or slow calls get a second line. There are no correlation IDs and no approvals to record. The log lives in the scan workspace directory that the agent's own shell can write, trace lines are not flushed per write, and a log-write failure is swallowed (warned once) while the scan continues.

Time is bounded at several layers: each bash call needs a timeout of at most 10 minutes, each agent activity has a 2 hour wall-clock limit, and at most five pipelines run concurrently. But main and child agent sessions have no turn or token/cost cap, retries run up to 50 attempts with minutes of backoff, so total runtime and spend before limits trip is measured in many hours. Stopping a scan cancels the workflow, aborts the sessions, force-terminates after a grace period and stops the container, which kills in-flight commands; there is nothing scheduled to continue afterwards, though effects on the target are not reverted.