Security at Audicite

Encryption

• All traffic uses HTTPS (TLS). Browsers are told to use HTTPS only, for two years (HSTS).
• Live audio streams over encrypted WebSockets.
• Databases and file storage are encrypted at rest by our storage provider (AES-256).
• Secrets we must use later, such as authenticator seeds and webhook signing secrets, are also encrypted by Audicite itself (AES-256-GCM, with a key separate for each purpose).
• Secrets we only need to recognise, such as API keys, invite links and backup codes, are stored as one-way hashes. We cannot read them back.

Signing in

• No passwords: sign in with a single-use email link that expires in five minutes, or with Google. There is no password database to leak.
• Two-step sign-in with any authenticator app, plus single-use backup codes. A code cannot be reused, and repeated wrong codes lock two-step sign-in for 15 minutes.
• See every device you are signed in on and sign any of them out.
• Sign-in attempts are rate limited.

Access control

• Five workspace roles: owner, admin, reviewer, member and viewer. Every request is checked against the role, on the server.
• API keys are members of one workspace with a role of their own, so a key can never do more than its role allows. Revoking a key ends its access at once.
• Sensitive actions (invites, role changes, keys, two-step changes, exports, deletions, retention changes) are written to an append-only audit log.
• Webhooks are signed (timestamped HMAC-SHA256) so receivers can reject forgeries.

Provenance you can verify

Every rating cites the exact sentence it relies on. We archive that source when we cite it, fingerprint the copy, and chain the fingerprints in an append-only evidence ledger, so anyone can check that a cited source has not been altered since. Deleting data removes its content from the ledger while the fingerprints stay, so the chain still verifies.

Application security

• A strict content security policy: scripts load only from Audicite, no plugins, and the app cannot be framed by other sites.
• Archived web pages are cleaned of scripts and shown on a separate origin, so a hostile page cannot reach your account.
• Our fetcher refuses internal and private network addresses (protection against server side request forgery), and respects robots.txt and paywalls.
• Content fetched from the web is treated as evidence, never as instructions to our AI models, and the models that rate claims are given no tools.
• Every input is validated on the server; logs never contain transcript text.

Your data, your rules

• Workspace owners set how long sessions are kept; older ones are deleted automatically.
• Anyone can download all their data, or close their account, from Account.
• Deleting a session removes its audio, transcript, claims and ratings. Deletion is finished by a background check if anything interrupts it.
• Our speech provider is told not to use your audio to improve its models, and our AI provider does not train on data sent through its commercial API. Customers can ask for the list of providers that touch their data at privacy@audicite.com.

Infrastructure

Audicite runs on managed cloud providers in the United States. Production secrets live only in the hosts' encrypted settings, never in our code. Every change to the code is type-checked, linted and tested automatically.

Certifications

We have not yet completed a SOC 2 or ISO 27001 audit. Our hosting and storage providers hold their own certifications. Enterprise customers can ask us for a security questionnaire response.

Report a vulnerability

Email security@audicite.com with the details and how to reproduce it. We will reply within three working days and keep you updated until it is fixed. Please do not access other people's data, disrupt the service, or make the issue public before we have fixed it. We will not take legal action against research done in good faith under these rules. Our security.txt has the same details.