Aletura · Trust Center
Security and data processing
What is actually implemented: architecture, encryption, tenant isolation, masking, prompt-injection defense and audit logging — and what is not yet available.
Architecture
Aletura runs as a modular monolith on Java 21 / Spring Boot — a single deployable application, no microservices. The full-text index (Lucene/BM25) is in-process and bounded per request/session. Default inference uses the configured Mistral EU endpoint (https://api.eu.mistral.ai); optional BYOK providers (OpenAI, Azure OpenAI, Azure Claude) are reachable only behind an endpoint allowlist. Hosting is with Scaleway in the EU.
Encryption
- In transit: TLS/HTTPS only.
- At rest: AES-256-GCM for saved analyses (and co-saved original documents where the Save function provides for them), for BYOK and organization credentials, and for company knowledge. Keys live in configuration/secrets outside the repository; key rotation via a previous key is supported.
- Passwords are stored as hashes only.
Tenant isolation and access control
Authorization is based exclusively on the authenticated principal and server-side organization/department memberships — never on client-sent plan or account headers. Organization workspaces have roles (admin/member) with separated permissions; company knowledge and playbooks are separately typed, authorized and evidenced objects and can never become clauses of an uploaded contract. Raw IPs are never logged or stored; the guest quota is keyed by an anonymous device cookie plus a hashed-IP abuse guard.
Masking pipeline
Before indexing and before any model call, detected personal identifiers are replaced deterministically and locally by request-scoped placeholders; an outbound guard checks every prompt, and model responses are validated for schema, canary leaks and disallowed fields. Masking is pseudonymization with detection limits, not absolute protection. Contract content is not persisted by default.
Prompt-injection defense
Uploads, retained evidence, comparison content and follow-up questions are treated as untrusted data. Instruction-like text inside documents is detected and handled as data — it is never executed and cannot trigger tools, URL retrieval, shell access, email or persistence. Prompts are built through a JSON-isolating safe prompt builder; untrusted content is never interpolated into trusted instructions.
Audit logging
Per organization, Aletura keeps an audit log with an HMAC-SHA256 integrity chain (key rotation supported). Retention is configurable per workspace: 30, 90 or 365 days (default 90 days, PUT /api/account/workspaces/{id}/audit/retention), with hourly cleanup. A rate-limited CSV export is available (GET .../audit/export).
Sub-processors
| Sub-processor | Purpose | Location / notes |
|---|---|---|
| Scaleway | Application and database hosting | EU. |
| Mistral AI | AI inference for the analysis | Configured for Mistral EU regional inference (api.eu.mistral.ai); no GDPR-compliance or end-to-end residency beyond that configuration is inferred. With BYOK the key is only sent to the allowlisted endpoint of the selected provider. |
| Simple Analytics | Website analytics | Cookie-less, respects Do Not Track, stores no IP addresses and builds no profiles. |
Data processing agreement (DPA)
A DPA template under Art. 28 GDPR is available for download and must be completed and countersigned by the customer — it is not concluded automatically: DPA template (English, Markdown) · AVV template (German, Markdown).
Retention and deletion options
- Audit logs: 30 / 90 / 365 days, selectable per workspace (default 90 days).
- Saved analyses and original documents: deletable by the user at any time; encrypted backups expire with the deployment's backup retention.
- Account deletion cascades to linked saved results.
- Unsaved contract content, indexes and masking mappings are ephemeral and deleted after the session or via TTL.
- Email-verification and reset links are single-use, stored as hashes, and expire after 24 h resp. 30 minutes.
Single sign-on (SSO) — status: planned, onboarding assisted
SSO via Microsoft Entra ID (OIDC, with PKCE) exists in the codebase but is not self-service yet and is marked PLANNED in the product capability API. Until it is enabled, workspace sign-in remains email + password. Onboarding currently runs sales-assisted through the operator — the former “setup-required” placeholder state is replaced by this checklist:
- Request: contact the operator via the contact form or paulcurcean@protonmail.com, naming the organization.
- Provide the tenant ID: the customer's Microsoft Entra ID tenant ID.
- App registration: the operator creates the Entra app registration and transmits client ID and secret over a secure channel (never plaintext email).
- Activation: the operator configures and enables OIDC for the workspace server-side.
- Test: a test sign-in through the workspace SSO test endpoint (
POST /api/account/workspaces/{id}/sso/test). - Rollout: enablement for the organization's members.
Honest limits
Aletura claims no certification (e.g. ISO/IEC 27001) and no compliance that was not measured. Masking has detection limits; the current validation status of the analysis is published on the methodology page. Aletura is not legal advice — see the Terms and the Privacy policy.
