Layered controls around the operating record.
Security is applied across identity, organisation access, server-side authorisation, session handling, document storage and application responses. These controls reduce risk; they do not eliminate it or replace client-side governance, endpoint security and physical laboratory controls.
Hardened credentials
Passwords are salted and derived with scrypt. Plain-text passwords are not stored.
Role and organisation scope
Platform roles, organisation memberships and project roles constrain authorised actions.
Opaque, revocable tokens
Random session tokens are stored server-side as hashes and can be revoked.
Audit events
Authentication and selected operational events retain actor and action context for review.
Access is checked against the requested workspace.
- Client users receive access through active organisation memberships and assigned roles.
- More privileged platform functions require a corresponding active platform role.
- Document access is authorised against the document's organisation before retrieval.
- Account and organisation status can prevent access even when a user still has credentials.
- Same-origin checks are applied to sensitive authentication and upload requests.
Passwords must meet the platform's length rules and are processed using scrypt with a random per-password salt. Sign-in attempt limiting uses recent failed events associated with the normalised email or hashed network context to slow repeated guessing.
The browser holds the token; storage holds its hash.
Successful sign-in creates a cryptographically random opaque session token. The raw token is sent in a __Host- cookie marked Secure, HttpOnly and SameSite=Lax; the platform stores a hash of the token for subsequent matching. Sessions are time-limited, can be revoked and are rejected when the user is inactive or the session is expired or revoked.
Protected application and API responses are marked private and non-cacheable. Users should sign out on shared devices and immediately report unexpected account activity.
Files are constrained and integrity-checked.
Asset document uploads are limited to configured PDF, JPEG, PNG and CSV types and size limits. The platform compares file extension, declared content type and expected file signature before storing the file. It calculates a SHA-256 checksum and stores the object in R2 with organisation, asset and document metadata.
On retrieval, the platform checks object size, storage identifier, checksum metadata and organisation/asset/document metadata before returning the file. Downloads use attachment disposition, restrictive content security policy and content-type sniffing protection.
Browser-facing security headers reduce common exposure.
The application currently returns headers that include:
- Content Security Policy restrictions for framing, base URLs and form destinations.
- Frame denial through both CSP frame ancestors and X-Frame-Options.
- Strict transport security and content-type sniffing protection.
- Restricted camera, microphone, geolocation and payment permissions.
- Same-origin opener policy and a restrictive referrer policy.
Security headers are one layer, not proof that every browser, dependency, integration or future change is free from vulnerability.
Material actions leave operational context.
The platform records authentication events such as successful and failed sign-ins, session creation and revocation. It also records selected organisation and platform actions, including document upload and viewing. Audit events support investigation and accountability, but they are not represented as a complete security information and event management service or an independent compliance audit.
Clients control the people and devices around the account.
- Assign the least-privileged role suitable for the work.
- Review membership when people move roles or leave the organisation.
- Use unique passwords and protect email accounts used for invitations or recovery.
- Maintain device security, browser updates and trusted file-handling practices.
- Keep regulated or highly sensitive data out of the platform unless the agreed scope explicitly addresses it.
Report suspected security issues responsibly.
Use the enquiry form to flag a suspected vulnerability, inappropriate access or security concern. Do not include passwords, session tokens, personal data or detailed exploit instructions in the initial submission. Do not access, alter or retain another person's information while investigating.
This page is not a bug bounty promise, safe-harbour agreement, certification or warranty. We will assess reported issues according to risk and the available evidence.
Put security requirements into the brief.
Raise access, data handling, procurement or assurance requirements before the operating model is agreed.