Use GitHub's Report a vulnerability flow on this repository to open a private security advisory: https://github.com/swcstudiospace/hypergrok-autonomous-desk/security/advisories/new. SWC Studio reads advisories there; there is no email channel. Do not put keys, signatures, wallet exports, account payloads, approval tokens or exploitable details in a public issue.

What "vulnerability" means for a repository of instructions and a small set of scripts: any prose, snippet or code path that could lead a role to reach /exchange other than through scripts/desk_send.py on a valid policy-gate approval; that could make the gate pass a ticket outside the policy, past a ceiling, on the wrong network, into an unprotected book or after a halt; that could let a role write autonomy.json, risk-limits.md or the gate key, forge or reuse an approval, resume a halt, handle a main-wallet key or seed phrase, move funds, resend an unknown-result order, or print a secret. Those are bugs; report them.

On the original desk a human read every ticket. On this one the last reader is a script, so the question to ask is what a compromised or misbehaving agent could do, and the honest answer has two halves.

Inside the scripts, it can do nothing the policy does not allow. The gate recomputes the arithmetic, reads the account itself, and refuses anything outside the user's limits, the autonomy ceilings, the rate caps, the loss stop or the halt; the approval is an HMAC over the ticket bytes keyed by a file no role can read, expires in ten minutes and is spent by one send; the sender records intent before sending and never retries. An agent that writes a flattering ticket gets a FAIL with the numbers; an agent that edits the ticket after a PASS gets a dead approval; an agent that calls the sender twice gets the not-sent gate.

Outside the scripts, an agent with shell access and the key in its environment could in principle sign its own exchange action. What it could then do is bounded by the key, not the gate: anything a trade-only API wallet can do within the exchange's own margin and position limits, which is to open, modify, close and cancel, and never to withdraw, transfer, bridge or approve another agent. The mitigations, in the order they apply:

• The Claude Code guard (hooks/guard.py) denies any raw /exchange request, any Exchange( construction outside desk_send.py, every fund-moving and agent-approving action name, kill_switch.py resume, and writes to the user's files by every shell idiom it knows. Deny wins over bypassPermissions. In Grok Bot the re-scoped Require Approval rule does the same job at the product level.
• The settings template denies the session from reading the key file and gate.key, so the key reaches the process only inside desk_send.py.
• The API wallet is trade-only, provisioned by the user, revocable in the Hyperliquid app in one action.
• The desk starts on testnet, the ceilings are tight, the first cycles run with the user watching, and the journal records every cycle so a deviation is visible the next time a human reads it.
• Watches alert on a stale heartbeat, a halt, an approaching loss stop and an unprotected position, so the desk asks for a human when it cannot continue.

Neither half is a guarantee of profit or of safety. The gate is arithmetic against a written policy; the rest is a narrow key and a set of denies. Say exactly that when asked.

• Only a trade-only Hyperliquid API wallet key ever reaches the desk computer: through Grok Bot's secure secret store, or a mode-600 file the Claude Code session is denied from reading; never through chat, settings, a command file or the repository.
• All Bots for one user share a computer and sign-ins, so Bot identity is not a credential boundary; the key's permissions, the gate and the guard are.
• If a send times out or errors after leaving the machine, do not retry. Reconcile the client order id first, and treat a replacement as unsafe until the original send's expiresAfter has passed and a further check is clean - not finding an order is not proof it will never arrive. An unresolved unknown result halts the desk.
• Only the user resumes a halt. A role that resumed one, or that edited autonomy.json to make a ticket pass, is a defect to report.
• Suspected key misuse: the user revokes the API wallet in the Hyperliquid app first, halts the desk, then the desk investigates from the send ledger and events log.

Supported versions: