Trusting a security tool
starts with seeing the receipts.

Astrari runs on infrastructure in the United Kingdom. Your account data, monitoring data and findings are stored on UK-hosted PostgreSQL with encrypted-at-rest volumes. We use a small number of trusted sub-processors for things we don't do ourselves — Stripe for payment processing (Ireland and the United States) and Resend for transactional email (United States). The full list is in our Privacy Policy.

We don't sell your data. We don't share it for advertising. We don't use it to train models.

• ▸Passwords are stored as salted bcrypt hashes (cost factor 12). We never see your password.
• ▸Two-factor authentication (TOTP) is available on every account, free, on every plan. Compatible with Google Authenticator, 1Password, Authy, Microsoft Authenticator, or any TOTP-compliant app. Enable it under Settings → Two-factor authentication. Backup codes (8 single-use) cover the lost-phone case; lose those too and account recovery requires support-verified identity check.
• ▸TOTP secrets are AES-256-GCM-encrypted at rest under a dedicated key (MFA_KEK), separate from the JWT signing secret, the WordPress-credential key, and every other credential we encrypt — so a database compromise alone yields no usable codes.
• ▸The 2FA challenge can't be bypassed via the refresh-token flow: each session row carries an mfaVerified flag set when the second factor was passed, and we propagate it through token rotation rather than re-prompting per refresh.
• ▸Session refresh tokens are stored only as SHA-256 hashes. We rotate them on every refresh.
• ▸JWT access tokens are short-lived (15 minutes); refresh tokens last 7 days and require an active session.
• ▸Login attempts hit the same constant-time bcrypt comparison whether or not the user exists — no enumeration via timing.
• ▸API keys (iw_live_…) and agent tokens are shown to you once at creation; we only store the SHA-256 hash. You generate new ones if a key is lost.
• ▸WordPress credentials you provide for authenticated scanning are encrypted at rest with AES-256-GCM, using a key separate from our JWT signing secret.

The Astrari agent runs as root on your servers — it has to, to run package scanners and check system configuration. That privilege is the reason we hold ourselves to a strict line on what the agent is allowed to do without your involvement:

• ▸The agent never installs or upgrades OS packages on its own. The install script asks you before touching apt or dnf, and offers a --no-tools mode that installs the agent only.
• ▸Agent self-updates only ever replace the agent binary itself. They never modify other system packages.
• ▸Every agent binary release is cryptographically signed with Ed25519. The agent verifies the signature before applying any update — a tampered binary is rejected.
• ▸All actions that modify your server (package updates, SSH-config changes, .htaccess edits) are explicit dashboard actions, applied only when you click. The agent never decides on its own to change your system.
• ▸All agent-to-API traffic is HTTPS, authenticated by a per-server token that you can rotate or revoke at any time.

• ▸Every connection is TLS — between agents and our API, between dashboards and our API, between us and our sub-processors.
• ▸Database access is restricted by network policy and IAM; no direct internet access to our PostgreSQL instance.
• ▸Production deploys come through a controlled CI pipeline with mandatory review.
• ▸Authentication and audit events are logged and retained for at least 12 months for incident investigation.
• ▸Rate limiting is enforced at the API edge: per-token and per-IP limits prevent brute-force and abuse.
• ▸Body size limits cap request payloads at 1 MB — DoS via giant uploads is structurally impossible.

Every user-facing record carries an orgId column that scopes it to a single organisation. Every API query filters by it. Agency-plan customers can additionally scope assets, contacts, integrations and API keys to specific clients via a clientId sub-tenant boundary, so a client's logged-in user only ever sees their own data — even if they're hosted alongside dozens of others under the same organisation.

• ▸We don't have SOC 2 Type II or ISO 27001 today. We're targeting Cyber Essentials first as the right next step for our UK customer base — when we get to SOC 2 / ISO we'll publish the report rather than just claim a logo.
• ▸We don't publish a standard contractual SLA yet — the platform's operating history isn't long enough to commit to numbers honestly. Agency-plan customers can request a contractual SLA on a per-engagement basis. For everyone else we use commercially reasonable efforts and post incidents transparently on the public status page.
• ▸We don't act as a WAF. We monitor and detect; we don't sit in the request path. If you need active inbound filtering, pair us with Cloudflare or similar.
• ▸We don't do real-time malware blocking. Our scanners run on a schedule (with on-demand scans available at any time). If you need EDR with kernel hooks, we're not that product.
• ▸We don't claim to catch every vulnerability. No security tool does. We're honest about coverage limitations in our Terms.
• ▸We don't do hands-on remediation as part of the Astrari service. If you'd rather have someone fix the things we surface, our parent company below does that.

If you find a security issue in Astrari — the dashboard, the API, or the agent — please email [email protected] with a description and reproduction steps. We'll acknowledge within one business day and work in good faith with you to remediate. No bug-bounty programme yet, but we credit reporters in release notes if they want.

For data-protection or privacy concerns specifically, the full process and your statutory rights are detailed in our Privacy Policy.

Security is shared. The product is the agent + dashboard + checks; the perimeter that includes your security posture is wider than that. Please:

• ▸Use a strong, unique password for your Astrari account, and rotate it if you suspect compromise.
• ▸Limit access to your account — remove leavers promptly, audit users on the Agency plan periodically.
• ▸Keep your own backups. We don't back up your servers and we won't be your last line of defence against data loss.
• ▸Review findings and apply fixes. We surface issues; the call to fix them is yours.
• ▸Only add servers and websites you own or are explicitly authorised to scan. Running scans against systems you don't have permission for is a problem we cannot fix.