DocPilot platform security

Authentication

Access to the API and the applications relies on token-based authentication, not on a traditional server session.

• Password hashed with Argon2id; never stored in plain text. Minimum policy: 10 characters, with an uppercase letter, a lowercase letter and a digit.
• Short-lived JWT access token (15 minutes), carried in the authorisation header.
• Opaque refresh token, stored hashed server-side, sent in an httpOnly cookie (and secure in production). Rotated on every refresh, with reuse detection.
• E-mail address verification required before the first sign-in.
• Password reset via a single-use link (valid for one hour).
• Team invitations and activation links to join an organisation.
• Rate limiting on sign-in, sign-up and password reset requests (application threshold and reverse-proxy protection).
• Sign-out from the current session or from all sessions (current tokens invalidated).

Permissions

Access rights are managed by an RBAC model (roles and permissions) enforced server-side.

• Predefined system roles: organisation administrator, manager, approver, user, viewer.
• Granular permissions (documents, contracts, workflows, members, audit, etc.) checked by guards on every endpoint.
• Additional scopes: department, domain and document grants — a member only sees what their rights and scope allow.
• Separate platform administration console, with its own permissions and guards.

Organisation and workspace

DocPilot is multi-tenant: each organisation has an isolated workspace.

• The active organisation is carried by the authentication token. A client “organisation” header is not used to select the tenant.
• Database queries scoped to the organisation, reinforced by PostgreSQL RLS policies when the application role is in place.
• Objects stored under a dedicated prefix per organisation (`tenants/{id}/…`).
• A suspended organisation can no longer authenticate.
• Automated isolation tests on documents, search, audit and cross-organisation access.

Storage

Files are kept in S3-compatible object storage, separate from the application database.

• Private bucket: no public anonymous access.
• Server-side encryption requested on write (SSE-S3, AES-256).
• File access via time-limited signed URLs (upload, download, preview).
• Immutable versions: a new version is added; the original is never silently overwritten.
• File type check (magic bytes) when an upload is finalised.
• Antivirus scan (ClamAV) on the e-mail intake path, before OCR and routing.

Transmission

Communications between clients and the API are protected at transport and application level.

• HTTPS between the applications (web, mobile) and the API.
• HTTP security headers (Helmet): CSP policy, frame deny, HSTS in production, nosniff.
• CORS restricted to configured origins, with authentication cookies allowed only for those origins.
• CSRF check on mutations when the authentication cookie is present (Origin / Referer verification).
• API responses marked no-store (except health checks and technical documentation).
• Rate limiting at the reverse proxy (API, auth, front end).

Audit

Sensitive actions are logged for business traceability and support.

• Per-organisation audit log, write-only (append-only): no API to modify or delete entries.
• Actions covered: authentication, documents, workflows, permissions, members and other sensitive events in the product catalogue.
• Enriched metadata (user, date, IP address, user agent, request identifier); secrets removed before recording.
• Additional document activity log for following a file.
• Separate audit log for platform console operations.

Confidentiality

Data confidentiality relies on technical isolation and on the commitments described in the privacy policy.

• Service hosted on cloud infrastructure in the European Union.
• Application logs with sensitive paths redacted (passwords, tokens, authorisation headers).
• Soft deletion of accounts, memberships and documents in line with the product flows.
• Incoming webhooks verified (signature) before processing (e-mail intake, billing).
• OCR / AI providers chosen per organisation; DocPilot does not claim to train models on your documents.
• Details of processing, retention periods and data-subject rights: privacy policy. Summary of practices: GDPR page.

Read the privacy policy

What DocPilot does not claim

This page describes measures actually in place in the product. It does not constitute a certificate of compliance.

• No ISO, SOC 2 or HDS certification is claimed.
• No generic regulatory guarantee is displayed on this website.
• Multi-factor authentication (MFA) and SSO (SAML / OIDC) are not offered at this stage.

See the GDPR page

Contact

For a security question or a vendor questionnaire: social@docpilot-app.com.