---
title: "Security"
description: "How installs are verified, how updates are signed, and how to report a vulnerability."
url: "https://antiburn.ai/docs/privacy/security/"
---
## No session content leaves the machine

antiburn processes session data on-device and needs no account or backend to work. The hard line the project holds: no code path sends session content, credentials, or anything else about you to a service of ours or to any third party. Returning your own token to the provider that issued it isn't a violation of that line; sending it anywhere else would be.

## Verifying an install

The install scripts (`install.sh` for macOS and Linux, `install.ps1` for Windows) verify what they download before they put anything in place:

- Every release publishes a `SHA256SUMS` file. Both installers download it alongside the requested asset, compute the asset's own SHA-256, and refuse to proceed if the two don't match exactly.
- Setting `ANTIBURN_VERIFY_ATTESTATION=1` in the environment before installing adds a second, optional check: the installer calls `gh release verify-asset` (needs the GitHub CLI) to confirm the asset's build attestation on GitHub.
- On macOS, the installer additionally verifies the application's code signature (`codesign --verify --deep --strict`) and confirms Gatekeeper accepts it (`spctl --assess --type execute`) before moving it into `/Applications`, and checks the bundle identifier matches `ai.antiburn.desktop`.
- On Windows, the installed executable's presence at the expected path is checked after the installer exits successfully. The Windows installer isn't required to carry an Authenticode signature yet, so Windows SmartScreen can warn during installation — that's a known, current limitation, not a bypassed check.

## Automatic updates

When "Install updates automatically" is on, antiburn checks GitHub Releases on a schedule (and can always be checked by hand from Settings → About). An update downloads, verifies the downloaded bundle against a public key built into the app, and only then installs it — antiburn restarts as soon as installation succeeds. Development builds carry no updater at all. On Linux, AppImage releases update in place; Debian packages remain install-only and need the next package installed manually.

## Reporting a vulnerability

Report vulnerabilities **privately** through GitHub's security advisories:

**[Report a vulnerability](https://github.com/antiburn/antiburn/security/advisories/new)**

Do not open a public issue for a security report. The project acknowledges reports promptly, keeps reporters informed of progress, and credits them in the fix's release notes unless they prefer otherwise. Security fixes target the latest release, and corrective releases are published rather than replacing assets under an existing tag.

Reports of particular interest, beyond the hard line above:

- any code path that could cause network egress from the local analysis engine (`antiburn-local`), which is supposed to have none
- discovery escaping its documented provider roots, following a symlink out of an approved root, or writing to a provider-owned store
- a credential read for one purpose — calling its own issuing provider, on your behalf — ending up logged, cached beyond that purpose, or sent anywhere else
- transcript content leaving app-controlled local storage, appearing in logs, or surfacing outside a visibility or analysis feature that actually needs it