# Security at Lutril

> What Lutril collects, field by field. How long it is kept, how it is encrypted, who else processes it, and what happens during an incident.

Source: https://www.lutril.com/security
Last updated: October 7, 2026

---

## At a glance

| Question | Answer |
| --- | --- |
| Where is the data hosted? | France, on OVHcloud, which is ISO 27001 and SOC 2 Type II certified. |
| Does anything leave the EU? | No. No workspace data is transferred, replicated or backed up outside the European Union. |
| Which AI providers process our data? | None. Lutril uses no language model provider and no third-party classification service. |
| Who tests the platform? | An independent third party every quarter, plus automated dynamic scanning every week against the live application. |

## What we never store

The categories of data that never reach Lutril at all.

- The contents of your documents and files. The file exposure module opens a file to classify it and keeps only the verdict; the bounds are in [content analysis](#content-analysis).
- The body of your emails. Email discovery asks Gmail for three headers and Microsoft Graph for three fields. No call we make can return a message body.
- The text of prompts your employees type into AI tools. The browser extension analyses it on the device and sends a count of what it found, never the text.
- The sensitive values our detectors match. A card number, an IBAN or an API key is recognised, counted by category, and discarded.
- Your source code. Agent discovery records a file path, a line range and hashes, never the lines themselves.
- Private key material. For cloud service accounts we read key identifiers, ages and validity windows, never the keys.
- The URLs your employees visit. The browser extension reports the registrable domain of catalogued SaaS products, never a full URL, a path or a query string.
- Passwords of your end users in the systems you connect.

## Data we collect

Lutril stores identity and entitlement metadata, not the content of your work.

| Category | What we collect | Source |
| --- | --- | --- |
| Lutril accounts and sessions | Name, work email, role, authentication settings, password hash, failed-login counters, session identifiers and expiry. | Created in Lutril |
| Directory and identity | Email, display name, status, role, admin and external flags, multi-factor state, organizational unit, manager, last sign-in, and the profile photo as raw bytes. The full directory record is also held, encrypted: from Google that is the complete Admin SDK user, including phone numbers, addresses, recovery contacts and custom schemas; from Microsoft it is ten fields only. | Your identity provider |
| HR data | Employee identifier, work email, personal email, job title, department, manager, hire date, contract end date. | Your HR system, when connected |
| Application rosters | Per application and per account: identifier, login, email, display name, role, admin, bot and guest flags, two-factor state, last activity, profile URL, and the vendor's raw record where a connector needs fields our schema has no column for. Where a vendor refuses to disclose an address, the candidate addresses we derived are kept as reviewer evidence. | The applications you connect |
| Access requests and approvals | Requester and approver identities, the application and level requested, the free-text business justification, the approval chain, decisions, timestamps, time to live and expiry. | Lutril, Slack, Teams |
| Access reviews | Campaign scope, reviewer, decisions and reasons. A decision is stored against a per-workspace salted digest of the identity, not the address. The audit snapshot of a completed run holds identities in clear, inside an encrypted blob. | Created in Lutril |
| Provisioning and offboarding | Task state, owner, assignee, notes, checklists, and the source and recipient of a data transfer. Temporary credentials created during provisioning are encrypted and erased once handed over. | Created in Lutril |
| Catalogue and policies | Applications, owners, categories, approval rules, sensitivity levels, launch and documentation URLs. | Configured by you |
| Shadow IT: OAuth grants | Third-party applications authorised against your tenant: client identifier, display name, requested scopes and scope changes, and which employees granted them. | Google Workspace, Microsoft Entra ID |
| Shadow IT: browser extension | Per employee and per catalogued SaaS domain: the registrable domain, a visit count, first and last seen timestamps, and whether a signed-in session was detected. | The extension, installed by your MDM |
| Shadow IT: email discovery | The registrable domain and display name of a vendor that sent a signup email, and the employee it reached. Off by default. | Gmail or Microsoft Graph, on opt-in |
| File exposure and classification | Per file shared by link: file name, type, owner, share scope and role, the share link, and the verdict as a sensitivity level plus a count per detected category. | Google Drive, SharePoint, OneDrive |
| AI prompt protection | Per prompt that contained sensitive data: the AI tool's hostname, a count per detected category, and whether the user was warned or the value masked. | The extension, on the device |
| Non-human identities | Service accounts and workload identities: address, display name, project, roles, privilege tier, key metadata such as identifiers, ages and validity windows, last authentication, and the human principals able to impersonate them. | GCP, AWS, connected vendors |
| AI agents found in code | Repository, branch, commit, file path, line range and hashes, plus sanitised facts: framework, model, tools, triggers. Never the source lines. | GitHub, GitLab, when connected |
| MCP gateway | Per tool call: caller, client, tool name, integration, status, duration and the true byte size of the exchange. Arguments and vendor responses are not kept, with one exception: the Redmine connector records an issue subject on success and the full arguments on error. | The MCP gateway |
| Activity and technical logs | Actor, action, target, IP address, user agent, timestamp and a per-action detail object, plus operational traces and anti-abuse signals. | The platform itself |
| Integration secrets | OAuth access and refresh tokens, API keys and connector credentials you entrust to us. See [encryption and secrets](#secrets). | Entrusted by you |

## Retention and deletion

Durations are sized to your audit cycle. Governance evidence is kept for the contract term; operational logs are bounded.

| What | How long | Why |
| --- | --- | --- |
| Your workspace data: identity, directory, HR, application rosters, catalogue, discoveries | Contract term, replaced at each sync | They reflect the current state of your estate. |
| Governance audit trail: requests, approvals, review decisions and snapshots, task history, agent state changes | Contract term | Evidence for your ISO 27001 and SOC 2 audits. |
| Activity logs, including IP address and user agent | Contract term | Audit evidence: who acted, from where, when. |
| Browser extension domain events | 180 days | Rolling, swept four times a day. |
| Browser extension prompt events | 90 days | Rolling, swept four times a day. |
| MCP tool call logs | 13 months | Covers a full SOC 2 Type II observation period and its reporting lag. |
| Access graph snapshots, working copies | 50 per workspace, 90 days | Pruned in the same transaction that writes a new one. The review evidence itself is kept for the contract term. |
| Directory profile photos | Removed when the person leaves your directory | Orphaned key, swept on the same schedule. |
| File exposure findings | Until the finding is resolved, then pruned at the next scan | A file that is no longer shared drops out of the list. |
| Integration secrets | Destroyed when the integration is disconnected | Immediately and irreversibly. |
| Edge access logs: IP, URL, user agent | Never exported, destroyed at each deployment | Written inside the web server container, with no volume attached. |

- You can delete an integration, a user or a set of findings from the application at any time.
- Disconnecting an integration destroys its stored secret immediately and irreversibly.
- At the end of a contract you choose export or deletion. Deletion in the application completes within 30 days of your request.
- Deletion in the application completes within 30 days. A backup cannot have one person removed from it, so backups expire on their own 90-day cycle and are never restored into production without re-applying the deletions requested since they were taken.
- Only records we are legally required to keep, such as invoicing, are retained beyond that. No governance data is.

## Encryption and secrets

How tokens, keys and passwords are encrypted, and what bounds their use.

| Layer | How |
| --- | --- |
| In transit | TLS 1.2 and 1.3 only, with HSTS. Earlier versions are refused and session tickets are disabled. Internal services talk over a private network with no published port. |
| Integration secrets | Every token is encrypted with AES-256-GCM before it is written, into a column separate from the readable configuration. GCM is authenticated encryption: a random 96-bit initialisation vector per record and a 128-bit tag, so tampering with stored ciphertext fails at decryption instead of being silently accepted. |
| Master key | Held in HashiCorp Vault under a Shamir seal and loaded into memory when the service starts. It is not in the source, the configuration, the container images or the logs. |
| At rest | Database encrypted at rest on OVHcloud. Daily backups, encrypted on the server before they leave it, then held in encrypted object storage spread across three availability zones in a French region separate from the production site, with versioning enabled. Restores are verified from that storage rather than assumed. |
| Directory records | The full directory record synced from your identity provider is encrypted with the same scheme before it is stored. |
| Lutril account passwords | Argon2id with 64 MiB of memory and 3 iterations, plus a server-side pepper held outside the database. Not reversible. |

- Tokens never come back out. No API response, no log, no export and no screen shows one, not truncated, not even to an administrator of your own workspace.
- Least scope. We ask for read-only identity scopes first. A write scope is requested only where a feature you switched on requires it, such as creating or revoking an account.
- Revocation works from either end. Disconnect the integration in Lutril and the secret is destroyed, or revoke the authorisation in the vendor's console and we lose access without needing to act.
- Outbound calls are validated before they are made. A URL you supply is checked against an allowlist of globally routable addresses, and the resolved address is pinned for the life of the connection, so a DNS answer cannot change between the check and the call. Credentials are stripped on a cross-origin redirect.

## Hosting and subprocessors

Three subprocessors. The current list is maintained on the [subprocessors page](/subprocessors).

| Subprocessor | Role | Location | Data concerned |
| --- | --- | --- | --- |
| OVHcloud (OVH SAS) | Hosting: compute, database, storage, backups. ISO 27001 and SOC 2 Type II certified. | France (EU) | All platform data, at rest and in processing |
| Cloudflare, Inc. | DNS resolution for our domain, and nothing else. | United States | DNS queries. No application data, no storage, no decryption of traffic. |
| PostHog, Inc. | Audience measurement on the lutril.com marketing site, after consent. | EU cloud | Public site visits. No workspace data. |

- No AI provider. Lutril uses no language model provider as a subprocessor. No workspace data is sent to one, and no platform process calls one.
- TLS is terminated by our own reverse proxy on OVHcloud infrastructure, with certificates we manage. No third party decrypts your traffic.
- No workspace data leaves the European Union. Nothing is transferred, replicated or backed up outside it.
- The applications you connect are not Lutril subprocessors. Google Workspace, Microsoft Entra ID, Slack, your HR system and your SaaS tools process your data under your own agreements with those vendors, within the scopes your administrator approves.
- Before adding or replacing a subprocessor we notify you in advance, with a right to object.

## Tenant isolation

Each workspace is isolated by the database itself, not by application code.

- Isolation is enforced by PostgreSQL at row level, on every table holding customer data.
- The account the application runs as cannot bypass it.
- A mis-scoped query returns no rows, never another customer's.

## Content analysis: files and email

Two optional modules read content rather than metadata.

- What triggers a file scan. The file exposure module runs only if you granted the Drive or SharePoint scopes. It then runs nightly, and on demand from the application.
- What is read. We download the file and parse it in memory: Office documents, PDFs and plain text, capped at 512 KB of extracted text and 8 MB per document. We open the file; we do not keep it.
- What is written. A sensitivity level and a count per detected category, and nothing else. Never the matched value, never an excerpt. A file we could not read is recorded as unreadable rather than clean, so an unopened document is never reported as safe.
- Who classifies. Self-hosted deterministic detectors: Luhn with an issuer table for card numbers, mod-97 for IBAN and French social security numbers, and a vendored gitleaks ruleset for credentials. No third-party classification API and no language model. Your file content is read by code running on a machine in France and is sent nowhere.
- Keyword triage. An administrator can search up to 30 keywords across at most 200 files. Matches are returned to that administrator's browser and are never stored.
- Email discovery is off by default. It is enabled per workspace, and it additionally requires mailbox access to be granted out of band in your own admin console, so it cannot be switched on by accident from our side.
- What email discovery reads. Three headers from Gmail, three fields from Microsoft Graph, narrowed to signup-shaped subjects. No call we make can return a body. The subject line is classified in memory and discarded, and only the vendor's domain is kept.
- For prompt protection the extension reports the AI tool's hostname even when that host is absent from our SaaS catalogue, because the catalogue gate would otherwise drop the event. The content script runs only on the three AI origins declared in its manifest.

## Security testing

Automated static and dynamic analysis on a continuous cycle, independent penetration testing every quarter.

| Programme | Status |
| --- | --- |
| Dynamic analysis (DAST) | Run weekly by a third-party platform against app.lutril.com in real attack conditions, with no prior knowledge of the application. Most recent run 5 October 2026. |
| Static analysis (SAST) | Security review of the application code with repository access. Most recent campaign 6 October 2026. |
| Independent penetration testing | Quarterly, blackbox and whitebox. Reports available under NDA on request to security@lutril.com. |
| Dependencies | Application dependencies and container images are scanned continuously. |
| Remediation targets | Critical 48 hours, high 7 days, medium 30 days, low 90 days, from the moment a finding is qualified. |
| Responsible disclosure | Contact published at [security.txt](/.well-known/security.txt). We acknowledge quickly and keep the reporter informed until the fix ships. |

- Changes are peer-reviewed and deployed through controlled, traced procedures.
- Containers run as an unprivileged user, and no service other than the reverse proxy publishes a port.
- Security headers are set on every response including errors: content security policy, HSTS, frame protection, MIME-sniffing protection and a referrer policy.
- Rate limiting applies at the edge on the authentication and authorisation endpoints, and inside the application everywhere else.
- The application's content security policy still allows inline and evaluated scripts, required by the current frontend bundle. Tightening it is tracked.

## Incident response

As controller you have 72 hours to notify your supervisory authority. Lutril commits to 48.

| Step | Commitment |
| --- | --- |
| Initial notification | Without undue delay, and within 48 hours of qualifying a confirmed security incident affecting your data. |
| Channel | Email to the security contact you designate in the data processing agreement, plus a phone call for a critical incident. |
| Content | Nature of the incident, categories and approximate volume of data and people concerned, likely consequences, containment and remediation measures taken or proposed, and a named contact. |
| Follow-up | Further information as the investigation progresses, without waiting for a complete picture. |
| Post-incident report | Root cause analysis and corrective plan within 7 working days of closure. |
| Assistance | Support for your own notification to the supervisory authority and, where required, to the people concerned. |

- The internal procedure is written and the roles are assigned in advance: detection, severity qualification, containment, eradication, notification, then a documented review.

## Lutril staff access

Least privilege, mandatory multi-factor authentication, logged administrative access.

- Least privilege across the team, with role-based access control.
- Multi-factor authentication is mandatory on every privileged Lutril account.
- Administrative and support access is granted only when operationally necessary, and it is logged.
- No human reads your data outside your express agreement, a demonstrated security need or a legal obligation.
- We run Lutril on Lutril. Our own access reviews, leaver process and agent governance go through the product first.

## Compliance, reversibility and documents

Frameworks we run against, export of your data at any time, and the documents available under NDA.

- Lutril runs its security programme against the SOC 2 Type II trust services criteria and the ISO 27001 controls. Not certified against either to date. OVHcloud, the hosting provider, is certified against both.
- Reversibility: export your data as CSV or PDF from the application at any time.
- A data processing agreement under article 28 of the GDPR is signed before any real data enters the platform.
- Available under NDA: the penetration test reports, the full data processing agreement with its technical and organisational annex, the architecture and data flow description, and the incident response procedure.
- Security questions go to [security@lutril.com](mailto:security@lutril.com), data protection questions to [privacy@lutril.com](mailto:privacy@lutril.com).

## Common questions

### Do you sign a data processing agreement?

Yes, and we sign it before any real data enters the platform. It covers every requirement of article 28 of the GDPR, including subprocessor notification with a right to object, assistance with data subject requests, and deletion or return at the end of the contract.

### Can we see your penetration test report?

Yes, under NDA. Write to security@lutril.com and we send the latest blackbox report, the whitebox code review and the full data processing agreement. We can sign a mutual NDA the same week.

### Do you use AI to process our data?

No. Lutril has no language model provider as a subprocessor, no workspace data is sent to one, and the sensitive-data detectors are deterministic rules running on our own servers in France. If that ever changes you are notified in advance, with a right to object.

### Can we run a proof of concept without real data?

Yes. A proof of concept works on a reduced scope: one read-only directory integration, a subset of organizational units, and no write action until you decide otherwise. Several customers start that way before signing the data processing agreement.

### How quickly would you tell us about a breach?

Within 48 hours of qualifying a confirmed incident affecting your data, by email to the security contact you designate, plus a phone call if it is critical. Your own regulator allows you 72 hours.

### What happens to our data when we leave?

You choose export or deletion. Deletion in the application completes within 30 days of your request, and no backup is ever restored into production without re-applying the deletions requested since it was taken.