Enterprise security
Built for teams with a security review.
This page describes the controls that exist in the platform today, and separately the ones we are working toward. We do not claim certifications we do not hold.
Access and identity
Authorisation is decided on the server, every time.
The security model assumes the client is hostile: nothing is protected by hiding a button.
Server-side role-based access control
Every request is authorised on the server against the caller's role and project membership. The interface hides what you cannot use; the server refuses it regardless.
Logical separation per client and project
Client accounts can read only their own projects and deliverables. Contributors can read only their own assignments, submissions and earnings — never another contributor's.
No public file buckets
No audio file, transcript or deliverable is reachable from a public URL. Files are served through short-lived signed URLs issued only after an authorization check on the requesting account.
Credential and session handling
Passwords are hashed with argon2id. Sessions are stored server-side with hashed tokens and carried in secure, HttpOnly, SameSite cookies, so a stolen cookie value alone is not a usable database record.
Platform controls
Boundaries, limits and a record of what happened.
Upload validation and size limits
Uploads are validated for type, structure and size before they are stored. Oversized or malformed files are rejected at the boundary rather than processed downstream.
Rate limiting
Authentication, application and submission endpoints are rate limited to blunt credential stuffing, scripted enumeration and accidental floods.
Append-only audit logs
Privileged actions — approvals, rejections, exports, payment marks, score overrides, role changes — are written to an append-only log with actor, target, timestamp and context.
Environment-based secrets
API keys, database credentials and signing secrets live in server-side environment configuration. They are never bundled into the frontend or exposed to the browser.
Data protection
What leaves the platform, and what never does.
Clients receive the data they contracted for. Contributor identity is not part of that unless you contracted for it and the contributor consented to it.
Anonymised dataset delivery
Deliverables carry pseudonymous contributor identifiers such as DZ-000428. Personal data is stripped from datasets unless a specific contractual and consented requirement says otherwise.
Consent ledger
Terms of service, privacy policy, data-processing consent, voice-recording consent and per-project NDAs are recorded with the document version and the timestamp of acceptance.
Account deletion workflow
Contributors can request account deletion. The request is tracked to completion, and the outcome distinguishes what is deleted from what must be retained for legal, tax or contractual reasons.
Purpose-bound processing
Contributor data is used to run the work, pay for it and evidence its quality. It is not sold, and it is not repurposed into an unrelated dataset.
Consent ledger — recorded per contributor
- Terms of serviceversion + timestamp
- Privacy policyversion + timestamp
- Data-processing consentversion + timestamp
- Voice-recording consentversion + timestamp
- Per-project NDAversion + timestamp
Each acceptance stores which version of the document was shown and exactly when it was agreed, so consent can be evidenced rather than assumed.
Roadmap
Planned — not yet achieved.
Everything in this section is work in progress. None of it should be read as a certification, an attestation or a control that is live today.
SOC 2 controls
Formalising control documentation, evidence collection and monitoring ahead of a readiness assessment.
PlannedISO 27001 processes
Building out the information security management system: risk register, asset inventory, supplier review and review cadence.
PlannedEnterprise SSO
SAML and OIDC single sign-on with directory-driven provisioning for client organisations.
PlannedMulti-tenant isolation hardening
Deeper isolation at the storage and query layer beyond the application-level separation enforced today.
PlannedGeolocation checks
Optional location signals to corroborate regional quotas on projects that require verified geographic coverage.
PlannedSpeaker verification
Automated voice matching to confirm that a submission comes from the enrolled contributor.
PlannedLAHJA AI does not currently hold SOC 2, ISO 27001 or any equivalent certification. If a control matters to your procurement process, ask us where it stands and we will answer with the current state rather than an intention.
Send us your security questionnaire.
We will complete it honestly, mark what is planned as planned, and tell you where our answer is “not yet”.