Security overview

1. Identity & authentication

• Microsoft Entra ID single sign-on (OIDC + PKCE). No application-managed passwords; we never see or store user credentials.
• ID-token signatures are validated against the JWKS published by the customer’s Microsoft tenant, with strict issuer, audience, nonce, and expiry checks.
• Session cookies use the secure, HttpOnly and SameSite attributes; the session identifier rotates on every privilege change.
• The public agents API authenticates with Bearer tokens stored server-side only as cryptographic hashes — the raw token is shown once at mint and never retrievable afterwards.

2. Tenant isolation

The load-bearing security property of the platform.

• Every record that touches customer content is bound to the tenant that owns it. When a tenant is removed, every record that belongs to it is removed with it.
• Every query that returns content filters on the session’s tenant identifier, taken from the server-side session and never from a value supplied in the request body or URL.
• Cross-tenant access attempts return a not-found response rather than a forbidden response, so the existence of another customer’s data cannot be probed by identifier-guessing.
• The retrieval pipeline re-asserts tenant scope on every database join — in addition to the project-level access checks — so a bug in any single layer cannot leak data between tenants.

3. Data in transit

• TLS 1.2 or higher for all customer-facing traffic. Plaintext HTTP is redirected to HTTPS at the edge.
• Outbound calls to LLM and embedding sub-processors are made server-side only; customer browsers never see provider API endpoints or our credentials to them.
• Standard hardening headers are set on every response (HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and a content-security-policy that restricts third-party loading).

4. Data at rest

• The application database is hosted on infrastructure operated by Scaleway SAS, on a server located in France (Paris, PAR1). Disk encryption at rest is provided by the underlying host (AES-256 or equivalent).
• Uploaded files are stored outside the web-served document root so they cannot be retrieved directly by URL; the original is kept so re-embedding or re-extraction can be replayed at any time.
• Document text is chunked at ingest and persisted alongside a numeric vector representation produced by the configured embeddings provider; chunks carry the citation metadata needed to link an answer back to its source (page, sheet, row).
• The per-call audit log stores the call’s technical metadata (agent identifier, user or key identifier, status, token counts, latency). Storage of the raw prompt and output is opt-in per tenant and limited to Business / Enterprise plans; by default it is off.

5. API keys & rate limiting

Every API key minted by a workspace admin can carry the following controls:

• Per-minute request rate limit.
• Monthly token budget.
• IPv4 / IPv6 allowlist (CIDR ranges).
• Origin lock (for browser-side use).
• Expiry date.
• Instant revocation — disables the key immediately without affecting other keys for the same agent.

Blocked requests return a clearly-labelled error and are written to the audit log so admins can spot a compromised or misconfigured key.

6. Audit log

• Every agent call (success, error, or blocked) writes a row to the agent-call audit log with tenant identifier, agent identifier, user or key identifier, status, token counts, and latency. On Business and Enterprise plans, the input and output text are also retained when the tenant has opted in.
• Workspace admins can view the per-agent and per-key rollup in the Agents → Usage tab. Business and Enterprise customers can export the log as CSV.
• Privileged platform actions (operator-level access to a tenant, plan changes, sub-processor changes) are written to a separate operator-only log retained for 24 months.

7. Hosting & backups

• Application server, MariaDB primary, and ingestion cron workers run on infrastructure operated by Scaleway SAS on a server located in France (Paris, PAR1). See Sub-processors §1 for the host’s details.
• Daily database backups, encrypted at rest, retained for 30 days on infrastructure in the same region.
• Backup-restore drill at least annually; the last drill date is available on request from security@olyteck.com.
• Static assets used by the application (including the icons referenced by the Office add-in manifests) are served from the same infrastructure as the app — no third-party CDN sees customer documents or queries.

8. Sub-processors & AI training

The full version-dated list with regions, transfer bases and "no-training" references is at /legal/sub-processors.php. The short story:

• olyteck does not train any AI model on customer content.
• All four LLM sub-processors (Mistral, OpenAI, Anthropic, Google Gemini) publish a "no training on API customer data" stance for the endpoints we call. Verify each independently from the linked provider page.
• 30-day advance notice on any sub-processor addition; customers have a contractual right to object.

9. Incident response

• Documented runbook covering detection, scoping, containment, notification, recovery, and post-mortem.
• Customer-notification target for any confirmed personal-data breach: 72 hours from awareness, per GDPR Art. 33. Notifications go to every workspace admin email on file.
• Acknowledgement target for any inbound report at security@olyteck.com: 24 hours business-day.

10. Vulnerability disclosure

We welcome responsible disclosure from security researchers. Please:

• Email security@olyteck.com with a description of the issue, reproducible steps, and the affected component.
• Do not test against another customer's workspace, do not access data that is not yours, and do not run automated scans that materially affect availability.
• Give us a reasonable window to investigate and remediate before public disclosure (we aim for 90 days but will agree a different timeline where the finding warrants it).
• We do not currently run a public bug-bounty programme, but we will publicly credit you (with your permission) once the issue is resolved.

11. Security roadmap

The items below describe controls we are working toward. They are not contractual commitments unless reflected in a signed Order Form; we publish them so procurement teams can see the direction of travel.

• Independent security attestation. We are working toward a recognised third-party attestation (SOC 2 Type 1 or equivalent). Status is available on request to security@olyteck.com.
• Custom SSO claim mapping — available on Enterprise on request.
• PII redaction at ingest — planned. When enabled, configurable PII categories will be redacted before the chunk is persisted; the raw text remains available to workspace admins.
• Per-tenant audit-log retention & export — Enterprise (live), Pro (planned).

12. Contact

Security issues: security@olyteck.com.
Privacy / DPA: privacy@olyteck.com.
General support: support@olyteck.com.