Security & Trust

AlphaTill is an offline-first desktop application, not a cloud service with a thin client. The application, its database and the built-in local AI path run on your own computer. You may optionally connect a cloud AI provider.

This is the most important fact about our security posture: we do not hold your business data, so we cannot lose it, leak it, or be compelled to hand it over. Your sales, inventory, customers, suppliers, employees, and financial records stay in a local database file on your machine.

A consequence worth stating plainly: if our website or servers go down, your point of sale keeps working. You can keep trading through an internet outage, because selling, printing and inventory run against the database on your own machine.

AlphaTill itself takes no custody of your business database. Third-party services — your own cloud folder, a cloud AI provider, WhatsApp — receive data only when you switch them on.

There are three distinct categories, and they have different answers.

Full detail, including your access, portability, and erasure rights, is in our Privacy Policy.

In transit

• Traffic to alphatill.com, the customer portal, and the licence API is served over HTTPS/TLS.
• On a single-machine install, the app talks to its own embedded backend over the local loopback interface, bound to 127.0.0.1 by default. This traffic never touches a network.
• Licence tokens are signed server-side with Ed25519 and verified locally against the public key embedded in the desktop app. Older desktop builds also receive a legacy HMAC-SHA256 signature during the transition; it is not the root of trust. Stored licence data is encrypted with AES-256 and bound to a specific machine.
• Multi-station LAN mode: when you deliberately enable LAN mode so several tills share one database, traffic between stations is currently plain HTTP over your local network. LAN mode is intended for a trusted, firewalled shop network only. Do not expose the backend port to the internet.

At rest

• Account passwords are hashed with bcrypt — never stored or transmitted in a recoverable form.
• Designated sensitive fields are encrypted at the application layer with AES-256, with a per-installation key.
• Stored integration credentials and API keys are encrypted, and API keys are held as hashes.
• The local business database file itself is not encrypted by AlphaTill. We rely on operating-system full-disk encryption — BitLocker on Windows, FileVault on macOS, LUKS on Linux — as the control for the device-theft and local-access threats. We consider this the right layer for the threat: it protects every file on the machine, and it does not create a scenario where a forgotten passphrase permanently destroys a business's accounting records. We strongly recommend enabling full-disk encryption on any machine running AlphaTill.
• Backup files are copies of that database and carry the same characteristics. Store them somewhere you control and treat them as sensitive.

• Every API route requires authentication by default; public routes are explicitly allowlisted.
• Role-based access control with granular permissions, so a cashier cannot reach payroll, financial reports, or system settings.
• Two-factor authentication with recovery codes is available for accounts.
• New passwords are checked against known-breached password datasets and rejected if compromised.
• Repeated failed sign-ins trigger account lockout.
• Signing out invalidates the session token server-side — it does not merely forget it client-side. Active sessions can be listed and revoked.
• Each installation generates its own cryptographic signing secret at first run. There is no shared secret across customers and no secret baked into the installer.
• Sensitive financial operations enforce separation of duties, and high-impact actions require elevated roles.
• AI assistant actions run through a tiered permission model. The assistant cannot perform destructive operations without explicit confirmation, and eligible actions are reversible for a short window.

AlphaTill records an audit trail of sensitive activity — including authentication events, permission and role changes, financial operations, and inventory movements — with the acting user and a timestamp. Inventory changes are written atomically with their history record, so stock levels and their explanation cannot drift apart.

Administrators can review the audit log and crash diagnostics from within Settings. Log retention is configurable, with an automated cleanup job.

Current limitation: the audit log is stored in your local database. A user with direct administrative access to that database file could alter it. Cryptographic tamper-evidence for the audit trail is on our roadmap and is not yet implemented.

• Automated local backups run on a schedule, with configurable retention.
• A database integrity check runs at application startup, and routine maintenance keeps the database healthy.
• A backup is taken automatically before any schema migration, so an upgrade can be rolled back.
• You can export a full, consistent snapshot of your database at any time, plus spreadsheet exports for inventory and customers.
• Backups are restorable through the application. Restore is restricted to administrator roles.
• Optional integration with your own cloud-storage account for off-site copies — the destination is yours, not ours.

Because your data lives on your machine, you own the backup strategy. We strongly recommend keeping at least one off-site or off-device copy, and testing a restore before you rely on it.

• Dependency vulnerability scanning runs in our continuous integration pipeline for the desktop app, website, and mobile app.
• Automated test suites — unit, integration, and end-to-end, including accessibility checks — gate changes, alongside strict type checking.
• Security headers and a content-security policy are applied to web surfaces; the desktop app blocks untrusted navigation and external content injection.
• Input validation on API requests, with unknown fields stripped.
• Rate limiting on authentication and other sensitive endpoints, and abuse monitoring on licence activation.
• Staged releases: builds go out as a pre-release channel before being promoted to all users, and a release can be rolled back by re-pointing the update channel.
• Database schema changes run through reviewed migrations. Automatic schema modification is disabled in production builds.
• Secrets are supplied through environment configuration. No credentials are stored in our source repository.

Current limitation — installer signing: our installers are not yet code-signed, so Windows may show a SmartScreen warning on first run. We are in the process of obtaining a code-signing certificate. Until then, download AlphaTill only from alphatill.com/download and treat any copy from another source as untrusted.

We maintain a written incident response plan covering severity classification, escalation, and customer communication. It includes our obligation to notify affected individuals and the relevant supervisory authority within statutory deadlines — 72 hours under GDPR — where a personal-data breach occurs.

Because AlphaTill is offline-first, the blast radius of an incident on our side is limited: an outage of our website or licence service does not stop you trading, and a compromise of our infrastructure would not expose your business records, because we do not hold them.

Service status is published at alphatill.com/status. After any significant incident we conduct a blameless post-mortem and record the corrective actions.

Enterprise buyers and prospective customers conducting a vendor review may request a copy of the incident response plan from security@alphatill.com.

We would rather be precise here than impressive. AlphaTill holds no security certifications at this time. Below is what applies to us and what does not, and why.

We keep third-party dependencies deliberately minimal. Providers that may process limited account or licence data on our behalf:

• Stripe — payment processing, subscriptions, and invoicing
• Our email delivery provider — transactional email such as verification, receipts, and security notices
• Our hosting and CDN provider — serving the website, portal, and licence API
• GitHub — source control and distribution of release artifacts

None of these providers receive your business data, because we do not have it. For a current named list with jurisdictions, or a data processing agreement, contact privacy@moneyvaultgames.com.

If you believe you have found a security vulnerability in AlphaTill, please report it privately to security@alphatill.com rather than disclosing it publicly.

We acknowledge reports within 3 business days and aim to complete triage within 10 business days. We offer safe harbour for good-faith research: we will not pursue legal action against researchers who follow our disclosure policy.

We do not currently run a paid bug bounty, and we say so rather than imply a reward that does not exist. We do offer public credit, with your permission.

Machine-readable contact details: security.txt (RFC 9116). Our full disclosure policy — including scope, out-of-scope items, and safe-harbour terms — is available on request from the address above.