Security

Euler holds two things that are unusually sensitive: what your customers told you, and what you decided to do about it. This page describes how we protect them, what we can prove today, and what we are still building. We would rather you find a gap here than in a questionnaire.

Our compliance posture, stated plainly

Euler is not SOC 2 certified today, and we do not claim to be. A SOC 2 Type II report requires a multi-month observation window, and we would rather tell you where we are than imply a certification we do not hold. Our SOC 2 program timeline is available on request, and we will share the auditor engagement letter once signed.

What you can evaluate today is the architecture, because most of it is enforced by the database and by deterministic code rather than by convention — the kind of control that either exists or does not, and that we can demonstrate rather than assert. If your procurement process requires a completed audit report, talk to us about the dedicated-deployment option below, which removes most of the question.

Our Data Processing Addendum is published, and we are happy to complete a security questionnaire (including CAIQ-Lite) and answer specific questions from your security team directly.

Tenant isolation

Euler is multi-tenant, and we enforce isolation in the application and in the database.

In the application, workspace routes check that you are a member of the workspace before they do anything, and tenant queries go through scoped managers and view mixins that filter by organization and stamp it on create.

In the database, every table that holds tenant data carries a PostgreSQL Row-Level Security policy, declared to apply even to the table owner, and a test fails if a new tenant table is added without one. The application connects through a database role that is subject to those policies rather than one that bypasses them. A request to a workspace runs with that workspace set as the database context once you've signed in and your membership is confirmed. Until then, and for anyone who isn't a member, the context matches no rows at all. Background jobs, integration syncs and our MCP server set the same context. So a query that forgets to scope itself still returns only that workspace's rows, and the context is cleared when each request ends so it can't carry over to the next one. Requests that aren't about one workspace, such as signing in or listing the workspaces you belong to, are scoped in the application.

Encryption

Data is encrypted in transit with TLS. Our database is reachable only on a private network with no public IP address, and our cache connections require TLS with a pinned certificate authority.

Data at rest is encrypted by our cloud provider. On top of that, every third-party credential you give us — OAuth access and refresh tokens, API keys, webhook secrets, service-account credentials — is encrypted in the application layer before it reaches the database.

Application secrets are held in a managed secret store and mounted read-only into the services that need them.

Authentication and access

Web sessions use short-lived HttpOnly access tokens (15 minutes) with refresh tokens that are rotated and invalidated on every use, so a stolen refresh token works at most once and its reuse is detectable. Single sign-on (SSO and SAML), including per-organization connections and domain verification, is available on Business and Enterprise plans. People on a verified domain can sign in through your identity provider the first time without an invite. With directory sync (SCIM) turned on, someone your directory suspends or removes loses access to the workspace: their membership, team assignments and digest subscriptions are removed, the API tokens they created are revoked and their sessions are ended. Their past work stays attributed to them.

Machine credentials for our API and MCP server are stored only as a hash — the token is shown once and cannot be recovered from our database. Each carries a recognizable prefix so a leaked secret is easy to find in logs or code, a scope ceiling that limits it to reading, writing, or pushing, and optional binding to a single project.

How we handle AI, and what leaves your workspace

For an AI product this is the question that matters most, so here is a specific answer rather than a reassuring one.

Your content is not used to train models. Anthropic doesn't train on API data and deletes inputs and outputs within 30 days. Voyage AI is configured for zero-day retention, so it neither stores nor trains on what we send. Our Data Processing Addendum carries the same commitment.

You can have personal details removed before analysis. Redaction is offered when you set up a workspace and is off by default. With it on, names, email addresses, phone numbers and card, bank and ID numbers in feedback are replaced with placeholders before the text is analyzed or sent to a model. It runs on our own servers and applies to feedback that arrives after you turn it on. The tradeoff is that quotes in answers show placeholders too. Three things stay as they arrived: uploaded files, source details such as a Slack author or meeting attendees, and meeting commitments, which are read from the original Granola notes.

Every action Euler can take outward passes through three layers. Deterministic guardrails run first, in plain code with no model involved: they can require a human in the loop, block on keywords, enforce a minimum severity, cap batch size, respect a per-customer blocklist, and screen for personal identifiers before anything leaves. PII screening runs locally, so checking your text for identifiers does not send it anywhere. Then the model does its analysis. Then a person decides.

Autonomous action is off by default and stays off until you turn it on within limits you set. The deterministic guardrail invariants are verified in our continuous integration pipeline and block a deploy if they regress, so what we promise the system will never do is enforced by a test that can fail the build rather than by a policy document.

Subprocessors

These are always involved in providing the service:

Subprocessor	Purpose
Anthropic	Claude models for analysis, drafting, and synthesis
Voyage AI	Embeddings and reranking for semantic search
Google Cloud	Hosting, database, storage, and secret management
WorkOS	Authentication, single sign-on and directory sync (SCIM)
Stripe	Billing — we never store full payment card numbers

These are involved only if you connect them, are authorized per workspace, and can be disconnected at any time: Linear, Jira, Notion, Slack, GitHub, PostHog, Amplitude, HubSpot, Granola, Intercom, Gong, and Google BigQuery.

Enterprise customers can supply their own model-provider key, so inference runs under their own contract with the provider.

Auditability

Administrative and AI actions are written to an audit log that is append-only: existing entries cannot be edited, and the code raises rather than permitting an in-place change. You can read and export your organization's log as CSV.

Separately, a unified decision trace ties every model call and decision back to the request that caused it through a correlation ID, so you can reconstruct not just what happened but why. Trace retention is configurable per workspace, defaulting to 365 days, with the option to retain indefinitely.

Retention and deletion

Deleting a workspace starts a 30-day grace window during which support can restore it. After that, the data is hard-deleted. What survives is an anonymized record holding a month and a plan name for accounting purposes and no customer content. Deletion on termination is a commitment in our Data Processing Addendum, not only a feature.

Deployment options

Most customers use our multi-tenant service with the isolation described above.

For organizations whose requirements a shared service cannot meet, Euler can be deployed as a dedicated single-tenant instance in your own cloud project. The entire stack is defined as infrastructure-as-code, so this is a configuration exercise rather than a rewrite: your data stays inside your cloud project, under your IAM, your network controls, your audit logging, and your data-residency choice. Combined with your own model-provider key, the only data leaving your environment is inference traffic under your own contract. Contact us to scope it.

Reporting a vulnerability

If you believe you have found a security vulnerability, please report it to [security email]. We will acknowledge your report, keep you updated, and work with you to resolve it. We will not pursue researchers acting in good faith under responsible disclosure.