Security and data
Where your text goes, who can read it, how long it stays and what we have not done yet.
Where your text goes
Every model call in OtterSR goes to OpenAI’s API over TLS, with storage turned off. Under OpenAI’s API terms, what we send is not used to train its models and may be kept for a limited time to detect abuse. The search index is built there too: OpenAI turns passages of your documents into search vectors (embeddings). We keep the prompt and the response ourselves, in your account, so you can audit any answer.
To be precise about what this is: it is a statement about how the service is configured and about the terms OpenAI and AWS offer. It is not a control we can enforce on their behalf.
Where your text is processed
Since 5 November 2026 the application, the database and your uploaded files are in the United States, in AWS us-east-2 (Ohio); before that they were in Canada. Model inference is in the United States too: every engine tier runs on OpenAI’s API, so the title, abstract, any PDF text and the passages a writing command uses are processed there. The search index is built there too, from passages of your documents. If that matters to your ethics approval, do not use AI features for that review. Your content is stored in the United States either way.
One inference path, and no model of our own
There is exactly one place in the codebase that can call a model, and it meters every call. That is checked by an architectural rule in the build, not by convention: no other module is allowed to import a provider SDK. It means there is no such thing as an unmetered call, and no second, quieter route your text could take.
Where it is hosted
Amazon Web Services, in the United States (us-east-2, Ohio). The application, the database (which holds the search index), the object storage and outgoing email all run in the same account under the same controls. Model calls and the embeddings for the search index do not: they go to OpenAI’s API in the United States, and every engine tier (Otter-Nano, Otter-Mini, Otter-Pro and Otter-Max) is called with storage turned off. There is no data-residency option today; if your institution needs one, tell us.
Encryption
TLS for every connection, including between the application and the database. Stored documents are encrypted at rest with server-side encryption, and the database and its snapshots are encrypted too. The object store blocks all public access and refuses non-TLS requests outright.
Isolation between accounts
Tenant isolation is enforced by PostgreSQL row-level security. The application connects as a role that is not the table owner and cannot bypass those policies, so a query scoped to the wrong account returns nothing rather than someone else's rows. A cross-tenant test suite runs in CI and has to stay green.
Uploaded PDFs
Documents are processed only on your instruction and stored under a key prefix belonging to your account, with a server-generated name — your filename never becomes part of a path. There is deliberately no shared cache of PDFs across accounts, by DOI or otherwise: it would be cheaper for us and a licensing problem for you. You warrant that you have the right to upload each document; we delete them on request and destroy them when the account closes.
No protected health information
OtterSR is for published and preprint literature. Protected health information and individual patient records are forbidden by the Terms, and there is no business associate agreement available. We will be exact: we do not scan or classify your uploads, so nothing here detects or blocks such content. It is a rule, not a filter.
Deletion actually deletes
A deleted review is recoverable for 30 days and is then destroyed by a scheduled job — the database rows and the stored documents both. Closing an account destroys its content 60 days later, and you can cancel within that window. What survives is the financial record: usage events, charges and the audit log, kept because accounting law requires it. It contains no titles, no abstracts, no PDFs and no answers. Database snapshots are kept for 14 days and superseded document versions expire after 30, so a purge takes that long to work through the backups.
Card data never reaches us
Card details go directly from your browser to Stripe's hosted payment element. We store Stripe's identifiers plus the brand, last four digits and expiry — enough to show you which card is on file. That keeps the service in the narrowest PCI scope there is.
Sign-in and sessions
You sign in with your email address and a password. Amazon Cognito holds the password as a salted hash that we cannot read, and proves your address by emailing you a code when you sign up yourself or reset a forgotten password. Only our servers talk to Cognito; your browser never does. Where Google or Microsoft sign-in is offered, it uses OpenID Connect and asks only for your name and email. A session is an opaque server-side record referenced by an httpOnly cookie, expiring after 14 days of inactivity and 30 days absolutely, and revocable one at a time or all at once. Changing or resetting your password ends every other session. No credential is ever placed in local storage or in a URL, and every state-changing request carries a cross-site request forgery token.
Who else touches it
Amazon Web Services hosts the application, the database and your files; OpenAI runs every model call, with storage turned off, and builds the search index; Stripe takes payments; Amazon SES sends email; Microsoft 365 holds what you write to support@ottersr.com. That is the whole list, and each entry says what it receives. There is no analytics platform, no advertising, no session recording and no support-chat widget — not for privacy points, but because we did not add any.
What we have not done
No SOC 2, no ISO 27001 and no independent penetration test. OtterSR is built by a very small team and there is no budget for a paid audit before there is revenue; pretending otherwise would be the least trustworthy thing on this page. What we do instead: an automated cross-tenant test suite, an OWASP baseline scan, least-privilege cloud roles, and this page kept honest. When an institutional customer needs a formal audit, that is a conversation we want to have.
Something look wrong?
If you believe you have found a security problem, write to us before writing anywhere else. We will confirm receipt quickly and keep you informed. We have no bug bounty to offer, only credit and gratitude.
support@ottersr.comSee also the Terms of Service, the Privacy Policy, the Data Processing Addendum and the sub-processor list.