Security

Version in effect on October 13, 2026.

1. Architecture

Pilotiko is a web application (Python) with a PostgreSQL database, behind a front server (Caddy) that handles HTTPS. Hosting: [À COMPLÉTER: qui héberge les serveurs de production (ex. vos propres machines, ou le nom de l'hébergeur)], [À COMPLÉTER: ville ou région et pays des serveurs de production et des sauvegardes (ex. Montréal, Québec, Canada)]. Uploaded files are stored: [À COMPLÉTER: où sont gardés les fichiers téléversés (disque local du serveur, ou nom du service S3 et sa région)]. The public website and the application use no third-party script, no external content delivery network and no tracker.

2. Encryption in transit

• Traffic to Pilotiko goes over HTTPS; certificates (Let's Encrypt) are obtained and renewed automatically by the front server.
• Session cookies carry the HttpOnly, SameSite=Lax and, in production, Secure attributes.
• Calls to our providers (email sending, AI, telephony, payment, OAuth connections) use HTTPS.

3. Encryption at rest

• Encrypted by the application (AES-256-GCM): access and refresh tokens of connected tools, API keys entrusted to us (telephony, DNS, booking), two-factor secrets. The encryption key is supplied to the server through an environment variable or a protected file, never through the code repository.
• Never stored in plain text: passwords (salted scrypt hash), session tokens, verification and reset links, backup codes (SHA-256 hashes).
• Off-machine backup copies: encrypted (AES-256-GCM) with a key separate from the application's; an unencrypted copy to an external destination is refused.
• Server disk encryption: [À COMPLÉTER: les disques des serveurs de production et de sauvegarde sont-ils chiffrés (ex. « oui, LUKS sur les deux machines ») ? Phrase publiée telle quelle].

4. Authentication and access control

• Passwords of at least 14 characters; common passwords, or passwords containing your email or name, are refused.
• Two-factor authentication with an authenticator app (TOTP), with backup codes. Mandatory for owners and managers after a 7-day grace period, recommended for everyone. Turning it off requires the password.
• The email address must be verified before accessing a business. A password reset closes all open sessions. The sign-in and forgot-password screens do not reveal whether an account exists.
• Rate limits on sign-in, registration, forgot password, two-factor codes, public forms and writes per business; counters keep only a hash of the IP address or email.
• Roles (owner, manager, employee) checked by the server on every request, never only by the interface.
• Our team's access: operations pages are reserved for a named list of operators; direct access to the production database is limited to infrastructure administrators.

5. Isolation between businesses

• Every business record carries its business's identifier. The application runs with a non-privileged database role, subject to forced row-level security: a query sees only the rows of the current transaction's business.
• Composite foreign keys prevent a business from referencing another's rows.
• The address of a business you do not belong to answers "not found": the existence of others does not leak.
• These guarantees are verified by automated tests that forge cross-business requests.

6. AI agents

• Any risky action prepared by an agent (external send, booking, cancellation, payment) waits for an authorised person's approval; the database refuses such an execution without the identity of the approver. An expired proposal executes nothing.
• Secrets are removed from requests before anything is sent to the model. A business can choose strict privacy: no request is then sent to an outside AI provider.
• AI usage is capped per business; when exceeded or in case of an outage, the assistant falls back to its rules.

7. Audit logs

Important actions (connecting a tool, approvals, settings changes, agent actions) are written to an append-only audit log: the application role can write to it, not change or delete it. The technical request log contains no IP address or browser, and sensitive values (tokens, passwords) are masked in logs.

8. Backups and recovery

• Daily database backup, verified by restoring it into a throwaway database; the last 7 are kept.
• Off-machine copy: [À COMPLÉTER: où va la copie chiffrée hors machine des sauvegardes (OQEL_BACKUP_TARGET), ou « aucune pour l'instant »]. Off-machine copies are always encrypted.
• A documented restore procedure exists and can be exercised.

9. Secrets and code management

• No secrets in the code repository: keys are supplied to the server by the environment. Platform secrets can be kept in an encrypted vault.
• Software dependencies are pinned by a lock file, and every change goes through an automated test suite.
• Security headers: content security policy (no external scripts), framing forbidden, X-Content-Type-Options: nosniff, restrictive referrer policy. The pages of this Trust Center add Strict-Transport-Security and Permissions-Policy.
• Cross-site request protection (origin check) on every action that changes data.

10. Monitoring and incidents

The application continuously measures error rates and response times and alerts the operator to any serious anomaly (for example, a page failing massively). In a security incident involving personal information, we follow the procedure described in the Privacy Policy: contain the damage, assess the risk of injury, notify the Commission d'accès à l'information and the people concerned if the risk is serious, and notify affected customer businesses without delay.

11. What is not yet in place

For transparency, here are planned improvements we do not claim to have:

• the Strict-Transport-Security header on every application page (today: only on the pages of this Trust Center);
• encryption of local backups kept on the server (only off-machine copies are encrypted);
• automatic deletion of expired sessions and of some old logs;
• automatic revocation, at the provider, of OAuth authorisations on disconnection (today: tokens are erased on our side; revocation at the provider is done from your account);
• a penetration test by an external firm.

12. Report a vulnerability

We thank people who report vulnerabilities to us responsibly.

• Where: [À COMPLÉTER: courriel de signalement de vulnérabilités, ex. [email protected]] (see also security.txt). Describe the problem, the steps to reproduce it and the possible impact.
• Our commitment: acknowledge receipt within 5 business days, keep you informed of the fix and, if you wish, thank you publicly.
• Rules: access only data from accounts you own; do not modify or delete data; no denial-of-service attacks, social engineering or physical testing; give us reasonable time before any public disclosure.
• We will not take legal action against anyone who follows these rules in good faith. We do not offer financial rewards at this time.

← Back to the Trust Center