Your keys stay yours.

It reads public market data on your machine. Trading starts on paper; a real trade is signed in your own wallet, and the tools your agent gets cannot sign or send at all. Below: how to check a release, what runs on every push, and how to report a problem.

Read every line: the source on GitHub, AGPL-3.0, with a security policy.

Paper first: Every run starts on the simulated wallet. Live is devnet unless you start with --mainnet.
Keys: It never sees, stores or imports your private key or seed phrase. It keeps only your public key.
Signing: Nothing is sent without a keypress and your wallet's approval.
Caps: A separate local process holds your per-trade and daily caps and refuses any transaction over them before it reaches your wallet.
The model: The analyst and the MCP server have no build, sign or send tool. Your agent reads data or books paper trades.
Agents: An agent you opt in with --agent-paper can only book paper trades inside a mandate you armed.
Network: Local servers bind 127.0.0.1 only, with per-use tickets.
Telemetry: None. No account, no crash reports. A once-a-day version check that solgent update --off turns off.

Check a release yourself.

Each release is built by a public GitHub workflow from a tagged commit. Three checks, weakest to strongest, each under a minute.

Replace <version> with the release you downloaded.

checksum

SHA256SUMS

The file is byte-identical to what was published. Download SHA256SUMS next to it and compare.

macOS

shasum -a 256 -c SHA256SUMS --ignore-missing

Linux

sha256sum -c SHA256SUMS --ignore-missing

expectsolgent-<version>-src.tar.gz: OK

proves: The bytes you hold match the bytes the pipeline hashed.
does not prove: That the pipeline itself was honest. That is the attestation.

attestation

Sigstore · SLSA

A public GitHub workflow built this exact file from a public commit. Every file in SHA256SUMS has a build-provenance attestation signed through Sigstore.

GitHub CLI

gh attestation verify solgent-<version>-src.tar.gz --owner solgentapp

the CycloneDX SBOM and its link to the tarball

gh attestation verify solgent-<version>.cdx.json --owner solgentappgh attestation verify solgent-<version>-src.tar.gz --owner solgentapp --predicate-type https://cyclonedx.org/bom

expectThe repository, the workflow file .github/workflows/release.yml and the commit.

proves: The file with this hash was produced by that workflow, on GitHub's runners, from that commit.
does not prove: That the source at that commit is safe. Read it; it is small.

provenance

npm

For the npm package, once it is published: it carries an npm provenance statement that points at the same workflow and commit.

npm

npm view solgent@<version> --json | grep -A3 '"provenance"'

inside a project that depends on solgent

npm audit signatures

expectA provenance entry naming the same workflow and commit as the attestation.

proves: The package on npm came from the same workflow and commit as the release files.
does not prove: That the code is correct. Rebuild it from the tag to compare the bytes yourself.

Releases are published by the solgentapp organisation on GitHub.Every check, including a reproducible rebuild

Checked on every push.

Every push to main runs the secret, dependency and workflow checks in public. Each release is scanned again every week.

Every release carries
file	what it is
`SHA256SUMS`	The hash of every release file, for the checksum check.
`solgent-<version>.cdx.json`	A CycloneDX SBOM, with its own attestation.
SLSA provenance	A Sigstore-signed attestation for every file in `SHA256SUMS`, stored by GitHub.
`scan-results.json`	Per file: the sha256, the VirusTotal report and per-engine summary, the attestation and the SBOM link.

A flagged scan is never removed or re-rolled. It is investigated like a report: reproduce with the exact hash, compare against the attested build, then fix the cause or document the false positive next to the result.

Report it privately.

Please do not open a public issue for a security problem. GitHub's private vulnerability reporting creates an advisory only the maintainers can see.

Report a vulnerability Read SECURITY.md

Include the version or commit, your OS and terminal, steps to reproduce and the impact you expect. solgent doctor output helps and contains no secrets. Attach a proof of concept to the private report.

We do not currently pay bounties. We will never contact you first by DM about a report; anyone doing so in our name is not us.

What to expect
step	target
Acknowledgement	within 3 days
First assessment	within 7 days
Fix or mitigation	30 days for high impact, 90 days otherwise
Credit	in the release notes and advisory, if you want it

What is in scope

Anything that lets a remote party read or change local state or run code; anything that gets a transaction signed or sent without your keypress, past the signer's caps, or reads your wallet key; the signer process, the wallet bridge, the loopback chart server, the prompt firewall, the page fetcher; the release pipeline and the install script.

What is out of scope

The correctness of third-party market data, rug scores or the model's judgement; rate limits by upstream APIs; issues that need a compromised machine or a modified copy of solgent. These are still welcome as normal issues.

Which versions get fixes

Only the latest release. Before 1.0 there is no long-term branch.