Exploit Stage — VM Deploy Handoff (@deploy)

The LLM exploit-analysis stage (scanner/exploit.py, commit bce6238, live-verified against a real claude -p) was handed off to the @deploy cross-team agent for VM runtime provisioning on the polymarket-infra box, and @deploy accepted. This note records the agreed runtime shape, the technical facts that shaped it, and the operator-gated blockers. Negotiation transcript: /Users/levander/coding/polymarket_fetch/AGENT_HANDOFF.md.

For Agents

The exploit stage runs as a systemd oneshot + timer on the shared polymarket-infra e2-small box under a dedicated unprivileged user bsc-exploit. It is slither-free, writes nothing to disk, reads exactly 3 env vars, and upserts verdicts straight to Postgres. Status (2026-06-03): live-validated against prod (one clean local run, exit 0) and the BSC_EXPLOIT_ENV secret is now seeded with all 3 keys — @deploy is unblocked, awaiting role write+dispatch (see Live validation — 2026-06-03 and Pending — blocked on operator).

Live validation — 2026-06-03

First production run: clean pass, verdicts grounded

scanner.exploit (commit bce6238) was run once locally against the day’s batch batch-2026-06-03, writing to the prod Supabase bsc_contract_analysis table after the operator minted the 1-year CLAUDE_CODE_OAUTH_TOKEN. Result: 16 High-finding contracts → 14 analyzed (all false_positive), 2 needs_review, 0 failures, exit 0.

• Verdicts are high-quality and grounded, not rubber-stamped. Spot-checked 4 rationales — each correctly identified contract provenance and cited specific functions/lines: DooarSwapV2Pair weak-prng = standard UniV2 TWAP timestamp truncation; stake_pool emergencyWithdraw = onlyRole(ADMIN_ROLE) + the insight that deposit() forwards funds to masterAddress so the contract custodies ~zero drainable balance; Vault = GMX/Gambit-derived with a shared OZ nonReentrant guard, the reentrancy-eth flag mislabeled (only ERC20 outflow); VaultSupervisor’s Solady incorrect-shift + OZ Math.mulDiv incorrect-exp = well-known library-detector FPs. All injection_observed=false, per_finding correctly populated with finding_keys. 14/14 false_positive is the honest, correct outcome for a day’s batch of forked / library-heavy unaudited BSC contracts — the LLM triage layer working as designed (vulnerable ≠ exploitable), not a defaulting bug.
• Source-size budget defers large proxy implementations (a real limitation). Both needs_review were large proxy→implementation contracts where build_source could not retain the finding’s code snippet within the source budget, so the stage deliberately marked them needs_review (rationale “source too large to retain finding code”) rather than analyze truncated/mutilated code. This is by design (the findings-aware truncation guard) — big contracts get deferred and retried, not verdicted. It produces a small steady trickle of needs_review rows that do NOT fail the run or affect exit codes. Future tuning lever: raise the source budget or improve per-file selection so large implementations can still be analyzed.

Handoff outcome

• What moved: scanner.exploit (LLM exploit-analysis stage), pinned at commit bce62380a5bdf759facb512b0ba809180c63f79e.
• Who owns runtime: @deploy is writing the deploy role (Ansible-driven).
• Trigger model: runs after the existing GitHub-Actions daily scan+load populates the day’s bsc_finding batch (the 04:17 UTC scan/load → the 06:00 UTC exploit pass).

Agreed VM runtime shape

On the polymarket-infra e2-small box.

User + filesystem

• Dedicated unprivileged user bsc-exploit, home /opt/bsc-exploit, no sudo.
• /opt/bsc-exploit/repo/ = shallow clone of github.com/wowjeeez/bsc-vuln-scanner pinned to a specific commit (bce62380a5bdf759facb512b0ba809180c63f79e), NOT tracking main. Deliberate deploys only (Ansible git fetch + checkout <SHA>).
• uv installed; .venv materialized via uv sync --frozen --no-dev.
• requires-python = ">=3.12" → pin Python 3.12 on the VM.

Claude CLI

• claude CLI installed user-local at ~bsc-exploit/.local/bin.
• Authenticated via the 1-year CLAUDE_CODE_OAUTH_TOKEN from claude setup-token.
• The only writable-dir need is the CLI’s own config/cache under $HOME (~/.claude; optionally pin via CLAUDE_CONFIG_DIR). The stage code itself writes nothing.

Secrets

• A new GitHub Actions secret BSC_EXPLOIT_ENV in wowjeeez/terraform — separate from POLYMARKET_FETCH_ENV, least-privilege so bsc-exploit cannot see Telegram / polymarket tokens.
• CD materializes /opt/bsc-exploit/.env mode 0600. Three keys only:
  • CLAUDE_CODE_OAUTH_TOKEN
  • DATABASE_URL
  • ETHERSCAN_API_KEY
• Per “gotcha #25”: the GH secret is the only source of truth — local secrets/*.env are gitignored and ignored by CD.

systemd unit

• oneshot service + timer at *-*-* 06:00:00 UTC with Persistent=true (catches up if the box was down). Runs after the 04:17 UTC GH-Actions scan+load has populated that day’s bsc_finding batch.
• User=bsc-exploit
• WorkingDirectory=/opt/bsc-exploit/repo
• EnvironmentFile=/opt/bsc-exploit/.env
• RuntimeMaxSec=7200
• ExecStart=/opt/bsc-exploit/.venv/bin/python -m scanner.exploit
• Output → journald.
• OnFailure= alert on exit code 1 or 2 (exit 0 = silent).

Technical facts that shaped the spec

The exploit stage is slither-free

Even though slither-analyzer + solc-select are in the main dependency closure (so uv sync --no-dev still installs them), scanner.exploit never imports or invokes them — it uses a proxy-following Etherscan source fetch, no compilation. The VM therefore needs NO solc-select install step (that belongs to GH-Actions / the scan stage only). The two deps are harmless dead weight in the venv.

Stage writes nothing to disk

No scratch / output / cache files. Source is held in memory, the prompt is piped to claude via stdin, JSON is captured from stdout, and verdicts are upserted straight to Postgres. The only writable path required is the claude CLI’s own $HOME config/cache.

Exactly 3 env vars

ETHERSCAN_API_KEY, DATABASE_URL, CLAUDE_CODE_OAUTH_TOKEN.

DATABASE_URL must be the Session Pooler (:5432), NOT the :6543 transaction pooler

The stage upserts and connects with prepare_threshold=None; the transaction pooler breaks prepared-statement-less upserts. Use the same DSN the GH scan/load uses (Session Pooler, :5432). This matches the existing findings-loader / supabase-findings-store connection rule.

Exit codes (alert contract)

Code	Meaning	Alert?
0	success / nothing-to-do	no (silent)
1	DB error / rate-limit-stop / all-contracts-failed	yes
2	misconfig (missing secret)	yes

A Claude rate-limit stops the batch cleanly and self-heals on the next run via the unchanged-source cache (re-analysis is skipped for contracts whose source hasn’t changed).

Future-update protocol

• Phase (a) — now: @bscvuln pings @deploy with a new SHA → @deploy bumps the pin + redeploys.
• Phase (b) — later: graduate to workflow_dispatch.

Pending — blocked on operator

CLEARED (2026-06-03) — BSC_EXPLOIT_ENV is now seeded with all 3 keys

The three out-of-band items have all landed in the GH-Actions secret on wowjeeez/terraform:

1. ✅ 1-year CLAUDE_CODE_OAUTH_TOKEN (minted via claude setup-token).
2. ✅ Session-pooler (:5432) DSN for DATABASE_URL.
3. ✅ ETHERSCAN_API_KEY.

@deploy’s dispatch gate is cleared — remaining work is @deploy writing and dispatching the VM role.

Stood down — not an open item

"Rotate the Supabase DB password" — RESOLVED, do not resurface

The previously-flagged item to rotate the Supabase DB password was stood down. The rogue DB writer in the Round-53 incident turned out to be the operator’s own forgotten macOS LaunchAgent com.levander.polymarket-bot, not a third party — resolved in Round 54. No credential rotation is needed.

Related

• adhoc-analysis-and-queue — on-demand analysis by address + the bsc_analysis_request queue (commit 272a224) that extends this stage; its build_source (text, truncated) fix supersedes the 2026-06-03 source-budget explanation of the two needs_review proxy contracts above
• contract-scanner — the 5-stage pipeline; the exploit stage is the LLM analysis layer downstream of triage
• supabase-findings-store — the public.bsc_finding store the exploit stage reads from and upserts verdicts to
• findings-loader — the GH-Actions scan/load that populates the day’s batch (04:17 UTC) before this stage runs (06:00 UTC); shares the Session-Pooler DSN rule
• LOG
• TOPICS