AutoHedge
AutoHedge safety boundaries: a risk prompt is not transaction authorization
Inspect environment discovery, plain-text task history and signing helpers; separate advisory model output from enforceable transaction policy and confirmed results.
What you will learn
- Do not turn a recommendation into authority
- Read the actual signing function
- Keep secrets and operational evidence separate
Before you start
- Basic Python, Git and dependency-management knowledge
- A fictional evidence task with no wallet or signing authority
Explain the inspected implementation and its counterexamples without mistaking a simulation or generated text for a verified financial outcome.
Key takeaways
- Advisory risk text is not a hard authorization gate.
- Inspect decoded intent before any separately authorized signing integration.
- HTTP success, business status and a confirmed outcome are different states.
Do not turn a recommendation into authority
The risk prompt requests position size and drawdown analysis, while the worker produces string output. The inspected wrapper does not enforce numerical ceilings or require a typed approval before returning the director’s answer. Prompts are useful guidance, but they are not an independently enforced authorization system.
If a future integration attaches signing tools, it needs a separate policy boundary that validates the intended asset, amount, destination and request identity against an authorized instruction. This is a design requirement, not a feature proven in the inspected default path. This review did not add such integration or grant a model control of a wallet.
Read the actual signing function
get_order checks that mint and amount strings are nonempty, derives taker/receiver/payer from its configured keypair and requests an unsigned transaction. That local input check is not amount-range validation or proof of venue acceptance. execute_trade loads a keypair, decodes a supplied transaction, signs its message, populates a signature list and posts it with a request ID.
The inspected execute_trade function does not compare decoded transaction contents with a separately approved asset/amount/destination policy before signing. It calls raise_for_status and serializes the response JSON, rather than interpreting every business-status field as a verified success. These are source-level observations, not a comprehensive security audit or a test of current Jupiter service behavior.
Keep secrets and operational evidence separate
Signing reads SOLANA_PRIVATE_KEY, not the README’s WALLET_PRIVATE_KEY label. Parent-directory .env discovery and import-time environment loading can make ambient configuration relevant. A research-only process should have no signing key and no signing tool; absence of a prompt requesting a trade is not an adequate credential boundary.
Task text is stored in plain text in recent_tasks.txt, and search logging includes a query prefix. Treat prompts and logs as potentially sensitive. Record attempted requests, returned statuses and failures without publishing credentials. No wallet was loaded, no transaction decoded or signed, and no live operational safety claim was validated by this editorial review.
Implementation steps
- 1
Keep signing keys out of the research environment.
- 2
Audit actual tool attachments and ambient .env discovery.
- 3
Design explicit intent, policy and result checks for any future integration.
- 4
Redact task history and logs according to their sensitivity.
Copy-ready example
{"riskTextIsAuthorization":false,"signingVariableInSource":"SOLANA_PRIVATE_KEY","signingKeysLoaded":0,"transactionsDecoded":0,"actualSignatures":0,"actualTrades":0,"productionSecurityVerified":false}Frequently asked questions
Is a generated risk score permission to sign?
No. Model output and independently enforced authorization are separate; the inspected wrapper does not establish that policy boundary.
Does a 200 response necessarily mean a confirmed trade?
Not from the wrapper alone. It returns response JSON without independently validating all business-result and confirmation states.
Sources
- autohedge/main.pySource checked 2026-09-08
- autohedge/workers.pySource checked 2026-09-08
- autohedge/prompts.pySource checked 2026-09-08
- autohedge/cli.pySource checked 2026-09-08
- autohedge/env_loader.pySource checked 2026-09-08
- autohedge/tools/ultra_tools.pySource checked 2026-09-08
- autohedge/tools/exa_search_tool.pySource checked 2026-09-08