Security and data protection

This page describes the security measures Odexy has today. It describes only what is built and running; where something is not in place, we say so. If anything here is wrong, tell us at support@odexy.app with “Security” in the subject.

1. Signing in

• Passwords are stored only as salted scrypt hashes. The minimum length is 8 characters. Where enabled, new passwords are checked against known breaches using a method that never sends the password itself.
• Two-factor authentication by authenticator app (TOTP), backup codes or email codes.
• Passkeys (WebAuthn) for passwordless sign-in.
• Sign in with Google, Microsoft, Apple, GitHub, LinkedIn, Facebook or Discord, where enabled.
• Single sign-on by OpenID Connect, set up with us, on plans that include it. SAML and LDAP / Active Directory are not available yet.
• Rate limits on sign-in, sign-up and password reset, and optional bot checks.

2. Sessions

• Session cookies are HttpOnly, Secure and SameSite=Lax.
• Sessions last 30 days and renew while in use.
• Users can see their sign-in history and sign out other sessions; administrators can sign a user out everywhere. Revoking sessions takes effect within about a minute.
• Users are alerted when their account is used from a new device.

3. Permissions

• Every operation in Odexy — whether performed in the app, by the API, by an integration or by the AI assistant — goes through the same permission check.
• Permissions are grouped into roles (Owner, Admin, Manager, Employee, Client and any custom roles an organization creates), and many can be limited to a person’s own or their team’s records.
• Every database query is scoped to the workspace making it, so one organization cannot reach another’s data through the application.
• Our staff can access a workspace only to provide support or keep the Service secure. That access requires a stated reason, expires automatically, and is recorded in the workspace’s audit trail.

4. The AI assistant

• The assistant acts only through the operations described above and only within the permissions of the person using it. It cannot access the database directly, the file system, or the network outside those operations.
• Operations classified as dangerous — those that are destructive or irreversible, or that send something outside the workspace — are not available to the assistant at all; a person must perform them. They are also never available through our MCP server.
• Everything the assistant does, including what it reads, is recorded in the audit trail, attributed to the person it acted for.
• We do not use your data to train AI models, and the model providers we use do not train on it under their commercial API terms.
• Its instructions are part of our code, not stored data. Everything it reads — records, emails, documents, form answers — is marked as untrusted content before the model sees it, to resist instructions hidden in that content.

5. Encryption

• In transit: TLS 1.2 or 1.3 on every connection, including real-time connections, with HTTP Strict Transport Security.
• Credentials at rest: tokens for connected accounts (such as mailboxes), and email, AI and payment provider keys, are encrypted in the database with AES-256-GCM. So are performance-review narratives.
• Payment cards are handled by our payment processors; we never receive or store full card numbers or security codes.

We do not currently encrypt the rest of the database, or file storage, at the application level; access to them is restricted as described in sections 3 and 7.

6. Audit trail

The Service records every change made in a workspace, every failed attempt, and everything the AI assistant or an integration does. Each record shows who acted (a person, the assistant on a person’s behalf, or the system), what they did, the details of the action and its result, and when. Workspace administrators can review it.

Audit history is kept for at least the period included in the workspace’s plan:

7. Hosting and operations

• The Service is hosted on servers we operate in the European Union, provided by Contabo GmbH. See our sub-processors page.
• The database, file storage, email delivery, voice and video calls and document editing run on software we operate ourselves, so this data is not handed to a further provider.
• Production secrets are kept on the servers with access limited to administrators, and are never stored in our code repository.
• The database is backed up before every deployment, and backups are kept for 30 days.
• Service status and incidents are published on our status page.

8. Reporting a vulnerability

If you believe you have found a security vulnerability, email support@odexy.app with “Security” in the subject, including:

1. a description of the issue and its impact;
2. the steps to reproduce it;
3. how you would like to be credited, if at all.

We will acknowledge your report within 3 business days and keep you informed as we investigate. Please give us reasonable time to fix the issue before disclosing it, do not access or change other people’s data, and do not run tests that degrade the Service for others. We will not take legal action against research that follows these guidelines in good faith. We do not currently run a paid bounty program.

9. Incidents

If a security incident affects your data, we will notify affected customers without undue delay, and within 72 hours of becoming aware of a personal data breach, as set out in our Data Processing Agreement.

10. Certifications

We have not completed a SOC 2 or ISO 27001 audit and do not hold those certifications. See Compliance for where we stand.