Security

Every connection to Fred runs over HTTPS, so the data moving between your device and Fred is encrypted in transit. We tell browsers to use a secure connection only, through a strict transport-security policy, so traffic can't quietly drop back to an unencrypted link.

Passwords are stored only as one-way cryptographic hashes, so nobody - including us - can read them. Your team can also sign in with passkeys (Face ID, Touch ID, a fingerprint), where the secret never leaves the device. Sessions are random tokens we store only as hashes, they expire after 30 days, and sign-in attempts are rate-limited.

Yes, in the database itself. Fred is multi-tenant, and every firm's rows carry the firm's identity, enforced with row-level security: a request outside your firm's scope gets nothing back, by construction rather than by convention.

Card and bank details never reach Fred's servers. When a payment is taken, it runs through the payment provider's own hosted flow:

• Card payments are handled by Stripe.
• Direct Debit is handled by GoCardless.

They hold the card or bank details, not us. The connection tokens Fred does store - a sending mailbox, a payment account - are encrypted before they're written to the database, and payment webhooks are verified by cryptographic signature.

Fred sends a set of security headers on every response, so the protections don't depend on anyone remembering to switch them on:

• Pages can't be framed by another site, which blocks a common clickjacking trick.
• Browsers are told not to second-guess file types, which closes a MIME-sniffing route.
• We limit what address information is passed on when you follow a link away from Fred.

Fred runs on managed cloud infrastructure, in London: the website and app on Vercel, and both the database and the file storage holding your photos and floor plans on Supabase. Storage is encrypted at rest by the provider, and photos live in a private bucket readable only through short-lived signed links. Where a provider processes data outside the UK, we rely on the safeguards UK data protection law requires - the Data processing addendum lists each one.

Only when you ask it to. When an engineer uses Fred's capture, the spoken transcript and photos are sent to Anthropic, a US-based AI provider, whose model turns them into draft asset records for the engineer to check. The same happens when you import a register document. That's the one job the AI does: nothing is sent to it in the background, a draft only becomes a real record once a person has reviewed it, and our agreement with Anthropic doesn't permit your data to be used to train their models.

Yes. Every change to a record is logged - who made it, what changed, when. The trail is append-only: corrections are added as new entries and the original stays, exactly as a paper ledger should.

No. The live demo runs on made-up example data, so there's no real firm's records in it for anyone to reach. The protections described here apply to every real firm's workspace.

Security isn't only about keeping data out of the wrong hands. For a fire-protection firm, a record that's wrong carries its own risk. Fred's certificate standards and service intervals are built against confirmed British Standards and covered by automated tests, so the dates and standards on a certificate stay right as the product changes.

Not yet. Recognised information-security certification is on Fred's roadmap, starting with Cyber Essentials, the UK's baseline mark for managing information security well. We'll update this page when that changes.

If you're weighing up Fred for your firm and need more detail for your own checks, email hello@fredfireops.co.uk and we'll talk it through.