# How Rationale protects what your team decides · Rationale

> What Rationale encrypts, what never leaves your machines, how people and agents sign in, what our staff can and cannot see, how long we keep data, what happens in an incident, what we are and are not certified for, and how to report a vulnerability.

Source: https://rationalehq.com/security
Language: en

Security

# How Rationale protects what your team decides

Rationale holds the reasons behind your team's code, so it is built for code you cannot leak. This page says, plainly, what we do with your data, what we never do, and what is not there yet. Every statement describes the service as it runs today; the privacy policy carries the legal detail.

Updated October 6, 2026

In short

-   Decision content is encrypted at rest with keys kept apart from the database. The server queries only identifiers, states and anchors, and our admin runs with a key provider that cannot decrypt.
-   Transcripts and repositories never leave your machines; secret values are refused when written and redacted from quotes.
-   No passwords anywhere: email links that work once, devices and MCP clients with their own revocable tokens, Jira and GitHub by OAuth under each member's own account.
-   Every read and every confirmation is audited, including each time our own staff looks. There is no sign-in-as.
-   An EU company under the GDPR; servers in the United States under the Data Privacy Framework and Standard Contractual Clauses; no trackers, no third-party analytics, no training on your content.
-   Said plainly: no SOC 2 report and no SSO or SCIM yet. The last section lists what is missing.

On this page

1.  [Two kinds of data, kept apart](#model)
2.  [What stays on your machines](#machines)
3.  [In transit](#transit)
4.  [Signing in](#auth)
5.  [Who can see what](#access)
6.  [What our staff can and cannot see](#staff)
7.  [Every read is on the record](#audit)
8.  [The client](#client)
9.  [Where the service runs](#hosting)
10.  [How long we keep data](#retention)
11.  [If something goes wrong](#incidents)
12.  [Compliance and certifications](#compliance)
13.  [Not there yet](#missing)
14.  [Report a vulnerability](#report)

## Two kinds of data, kept apart

Rationale separates what it needs to run the service from what your team writes. The first kind (identifiers, states, anchors, timestamps, repository, branch and file names, task handles) is readable by the server, because routing, warnings and audit need it. The second kind is encrypted in the database with keys kept in the deployment's environment, never in the database or the repository: the text of decisions (question, choice, criteria, rejected options, assumptions, revisit conditions and quotes), notes, tasks, handoffs, summaries, digests and session titles; pull request titles, bodies and review threads; connector tokens; and the names, usernames, email addresses and photos Jira and GitHub give for people.

Content of the second kind never moves into columns, logs, events or error messages of the first. Request logs filter decision text and credentials, and audit events carry ids, numbers and states only. Decision content is append-only: an edit adds a version and overwrites nothing.

## What stays on your machines

-   **Transcripts.** The client extracts decisions on the person's machine with the agent they already use. We receive the decisions, short quotes of the person's own words and metadata (session id, turn numbers, repository, branch, commit, time, equivalent cost). The transcript itself goes nowhere but to the agent's own provider, as it always did.
-   **Repositories.** We never clone them and store no files. A decision is anchored to paths; when a decision names a class, a table or a ticket key, the match against a file's content happens on the machine, on at most 512 KB of text, and that content never leaves it.
-   **File paths.** When your agent reads or edits a file, the hook matches its path against a local index of anchored decisions and asks the server only on a match. A path no decision is anchored to never leaves the machine.
-   **Secrets.** A secret's value never enters a decision, a note or a handoff: it is refused in what people and agents write, and redacted from captured text and quotes. The scan looks for private keys, cloud and API keys, GitHub, GitLab, Slack and Stripe tokens, JWTs, passwords inside URLs and values written after words such as password or token; the server records only the kind of secret it refused, never the value. Hosts, URLs and where a secret lives (a vault path, an environment variable name) are welcome.

## In transit

-   Every connection to Rationale uses HTTPS, with certificates from Let's Encrypt and HTTP Strict Transport Security including subdomains; plain HTTP is redirected.
-   The client verifies TLS with your platform's certificate store, so a corporate proxy with its own root certificate works without weakening anything.
-   Webhook deliveries from GitHub and Jira are accepted only with a valid signature from the provider.
-   The emails we send leave over an encrypted connection to our email provider.
-   This website sets no cookies, loads no third-party script and ships a Content-Security-Policy that allows only its own, hashed scripts. The app sets only the signed cookie that keeps you signed in; neither carries trackers.

## Signing in

-   **No passwords.** Rationale stores none. People sign in with a link sent to their email that works once, for 15 minutes; the token travels after the `#` in the address, which browsers never send to a server, so it never reaches our logs or anyone's proxy. A browser session lasts 30 days.
-   **Devices.** `rationale init` signs a machine in with a device code: the client shows an eight-letter code, you enter it in the app while signed in, pick the workspace and allow or deny. Codes expire after 10 minutes and are stored as digests. The device's token is delivered once, stored as a SHA-256 digest, scoped to one workspace, stops working after 90 days without use, and can be revoked at any time from the Devices page; removing a member revokes theirs.
-   **MCP clients.** Claude, ChatGPT, Cursor and any MCP client connect with OAuth 2.1: dynamic client registration, public clients only, PKCE with S256 required, redirect addresses on HTTPS or loopback. Authorization codes last 5 minutes and are single use, access tokens last an hour, refresh tokens rotate on every use and last 90 days. On the consent page you choose which workspaces the client may reach; your membership is re-checked on every request, and the connection is revoked from the same Devices page.
-   **No API keys for people.** There is no personal key to paste into a config file or leak in a repository. The only credentials are a device's token and an MCP connection's tokens, each revocable on its own.
-   **Connectors.** Jira and GitHub are connected by OAuth with each member's own account, never a shared token or a password. The round trip uses a random state that is single use, lasts 10 minutes and is bound to the browser session that started it.
-   **Rate limits.** Sign-in links, device codes, the OAuth and MCP endpoints and the install script are rate limited per address or token.

## Who can see what

-   **Workspaces.** Every record belongs to a workspace and is reached only through it: a workspace you do not belong to is indistinguishable from one that does not exist. Owners manage membership, connectors and the audit log.
-   **Your own view of Jira and GitHub.** Connectors use OAuth with each member's own account, never a shared token, so each person sees in Rationale only the tickets, projects, repositories and pull requests their own account can see.
-   **Private records.** A decision, a handoff, a task created in Rationale or a whole session can be private: visible to its person and their own agents, never to the team, owners included. The person decides, with a click or in their own words through their agent; an agent never changes visibility on its own.
-   **Agents act as themselves.** An agent works through a member's device or MCP connection, labeled as the agent, on that member's behalf. It never sees more than the person it works for.

## What our staff can and cannot see

Rationale staff run an admin on its own host, opened by a staff-only email link into an 8-hour session behind a host-only cookie; a member session never opens it. It shows every customer's machinery by numbers: captures, failures, devices, jobs, metrics.

-   **It cannot decrypt.** Each admin request runs with a key provider that has no keys, so reading any encrypted attribute raises an error instead of rendering. A test walks every admin page with sentinel content and fails if that content appears, in clear or as ciphertext.
-   **Every look is in your log.** Each admin page that shows a workspace's data writes a `staff.viewed` event into that workspace's audit log, where owners read it under the Staff filter.
-   **No sign-in-as.** Staff have no way to open your workspace as you. No page, API or MCP tool can grant the staff flag: it changes only from the audited production console.
-   **Consoles are recorded.** A production console can read content, so opening one writes an `ops.console_opened` event with the operator before it accepts input; if the event cannot be written, the console does not open. We open one only for support you asked for, a privacy request or an incident.
-   **Privacy tools are audited too.** Exporting or erasing a person, exporting or deleting a workspace run from audited tools and write their own events, without content; a workspace export is sent only to one of its owners.

## Every read is on the record

Every create, read and confirmation of a decision writes an audit event: a decision opened, a list or a search rendered, context handed to an agent, a warning shown. Events carry ids, numbers and states, never content, and are append-only. Owners read their workspace's log in Settings, with the activity of members, agents and staff, the channel (web, client, MCP) and the IP address, filtered by changes, reads or staff access.

Provenance is explicit on every record: observed, derived, inferred by an agent, or confirmed by a person. A record becomes confirmed only through a human action: a click in the app, the person's own words in a session (the client checks them against the transcript before sending and drops anything an agent wrote about a person confirming), or the merge on GitHub of the pull request that carried the decision on its branch. An agent saying someone confirmed is not a confirmation.

## The client

-   One binary, no runtime. It installs in your home directory without sudo and never edits your shell files. The first install trusts TLS to the file host, like every `curl | sh`; every later update is verified by the client itself against a signed manifest.
-   Every release is signed with minisign. Two public keys are compiled into every binary: the release key that signs every manifest, and an offline backup key used only to rotate the first; the secret keys never go into a repository or onto a server. An update that neither key signed, a replayed manifest or a downgrade is refused; each file's size and SHA-256 are checked; a new binary that fails its self-test is rolled back, and `rationale update --rollback` puts the previous version back on request.
-   Its configuration is readable only by your user (mode 600). Hooks never block your agent: each makes at most one short request, two seconds at most, and one that fails exits silently.
-   `rationale uninstall` removes the hooks and the watcher; revoking the device in the app invalidates its token.

## Where the service runs

Provider

What for

Where

DigitalOcean, LLC

Servers, managed PostgreSQL database and its backups

United States (New York area)

Resend (Plus Five Five, Inc.)

Sign-in, invitation, access and summary emails; receiving email sent to our addresses

United States and the European Union

GitHub, Inc.

Hosts the client's downloads and updates

United States

Atlassian; GitHub

Only when a workspace connects Jira or GitHub, under each member's own account

Their regions

One server and a managed PostgreSQL database at DigitalOcean, reached over the private network, with daily backups and seven days of point-in-time recovery. The firewall allows only SSH, HTTP and HTTPS; SSH is by key only; security upgrades install unattended. Secrets reach the server as environment variables at deploy time, readable only by root, never in the repository or the database. Every change passes the tests, Brakeman, bundler-audit and importmap audit in CI before it is merged. Our provider accounts use two-factor authentication.

We are established in Portugal, so transfers to the United States are made under the GDPR: DigitalOcean's certification under the EU-U.S. Data Privacy Framework (with its UK and Swiss extensions) and the Standard Contractual Clauses in its data processing agreement; the Standard Contractual Clauses and the Data Privacy Framework for Resend. Each provider is under a written data processing agreement. The [privacy policy](https://rationalehq.com/privacy#recipients) keeps the authoritative list.

## How long we keep data

Workspace content (decisions, tasks, notes, handoffs) stays as long as the workspace exists and is deleted within 30 days of an owner's request or 90 days after the service ends; backups roll off in seven days. Personal data has published periods, enforced by a daily job:

Data

Kept

Browser sessions

30 days after sign-in

Device codes

1 day after they expire

Devices and MCP connections

Until revoked; 90 days without use stops them working

Invitations nobody accepted

30 days after they expired or were canceled

IP addresses (audit events, devices, MCP connections and clients)

12 months

A workspace's audit events

The life of the workspace, append-only; the IP address is cleared at 12 months

Sign-in, staff and operations events outside any workspace

24 months

People seen in Jira or GitHub who are not members

90 days after a source last showed them

Access requests

Pending ones expire after 90 days; a decided one loses its address 30 days after the decision

Failed background jobs

30 days

The [privacy policy](https://rationalehq.com/privacy#data) is the authoritative list. Owners can ask for an export of the whole workspace (decrypted, sent only to an owner) or for its deletion; a person can ask for their own export or erasure at privacy@rationalehq.com.

## If something goes wrong

We keep a written incident response plan, owned by the company's manager. It covers a leaked secret or token, a stolen laptop or provider account, unauthorized access, data sent to the wrong person, data lost or corrupted, and a vulnerability being exploited. When in doubt we treat an event as an incident and write it in the register.

1.  Contain, in the first hour: rotate what leaked, revoke devices and connections, turn a connector off, block an address, take a server offline if needed; copy the logs before they rotate.
2.  Write it in the breach register, with times in UTC, facts only, kept for at least five years.
3.  Assess what data, whose, and whether it was encrypted: decision content is encrypted with keys outside the database, so a copy of the database without the keys exposes identifiers and states only.
4.  Notify: the owners of each affected workspace within 48 hours, by email, with what happened, which data, what we did and what they should do; the Portuguese data protection authority within 72 hours where the GDPR requires it, and affected people without undue delay when the risk to them is high; Atlassian within 48 hours when the Jira connector is involved; US residents as their state law requires.
5.  Recover from backups (seven days of point-in-time recovery), redeploy, verify.
6.  Learn: root cause, fix, update the plan and the records of processing.

The register has no entries as of this page's date. The plan calls for a drill at least once a year, recorded in the register.

## Compliance and certifications

Rationale is a service of a Portuguese company and operates under the GDPR for everyone, wherever they are. The privacy policy names every provider, every purpose and every retention period. The terms include Data Processing Terms, with notification of a security incident affecting personal data without undue delay and within 48 hours, and US State Privacy Terms. We do not sell personal data, show no advertising, use no third-party analytics, and do not train AI models on your content.

**Certifications: none yet.** We are not SOC 2 or ISO 27001 certified, and no audit is under way. SOC 2 is planned once Rationale has the traction to justify it; this page will say when an audit starts and when a report is available. Until then this page, the privacy policy and the terms are the evidence, and we answer security questionnaires on request at security@rationalehq.com.

## Not there yet

Said plainly, so you do not have to ask:

-   **SOC 2 and ISO 27001.** No report and no audit under way. Planned with traction.
-   **SSO with SAML, and SCIM provisioning.** Not built. They belong to the Business plan, which is not for sale until they exist. Today every member signs in with an email link, and owners add and remove members by hand.
-   **Audit log export.** Owners read the log in Settings; there is no download yet. Planned for the Business plan.
-   **A second factor of our own.** Sign-in is by email link, so your mailbox's protection is your account's; Rationale adds no second factor of its own.
-   **Apple notarization of the macOS binary.** Releases are signed with minisign and verified by the client itself, not notarized by Apple yet, so install with the command or Homebrew rather than a browser download.
-   **Windows.** The client runs on macOS and Linux; on Windows the installer says so and stops.
-   **Hosting outside the United States.** Data lives in the United States under the transfer mechanisms above; there is no EU region yet.

## Report a vulnerability

Write to security@rationalehq.com. We acknowledge within a working day, keep you informed while we fix it, and take no action against good-faith research that respects other customers' data. Our [security.txt](https://rationalehq.com/.well-known/security.txt) says the same, machine-readably.

-   Include the host, the steps to reproduce and what you observed.
-   Do not access, change or keep data that is not yours; stop as soon as the issue is demonstrated.
-   Give us reasonable time to fix it before making it public.

Anything else: [support@rationalehq.com](mailto:support@rationalehq.com)