Security

What we enforce, and what we do not claim

Tore asks you to install an app on your source code and to let it record what your users saw when something broke. That is a lot to ask, so this page is written for the person whose job is to say no. Both halves are here: the controls that exist, and the ones that do not.

Isolation

Postgres RLS

Forced, per transaction

Audit trail

Append only

UPDATE and DELETE revoked

Network bodies

Never captured

Not a setting

Certifications

None yet

Said out loud, on purpose

Enforced today

Six controls, each one you can point at

Not a description of a security program. Each of these is a mechanism that exists in the product right now, with the place it lives named underneath, so you can ask us to show you.

Isolation is in the database, not the code

Separation between customer organizations is enforced by Postgres row-level security. Every tenant-scoped query runs inside a transaction that sets the tenant identity as a transaction-local setting, and the database compares every row against it. Application code cannot forget to add a filter, because the filter is not in the application code.

packages/db/src/client.ts, withTenant

The isolation applies to us too

Row-level security is set to forced on those tables, so it binds the table owner as well as ordinary callers. The application role does not hold the privilege that bypasses it. Separate database roles exist for the application, the audit purge, the audit anchor and erasure, each provisioned with only what its job needs.

packages/db/provisioning/02-grants-post-migrate.sql

The audit trail cannot be rewritten

UPDATE and DELETE on audit events are revoked from the application role at the database level. An application bug, or an attacker holding the application role, can add to the record but cannot edit or erase it. Expiry is handled by a separate role that can delete but cannot insert, so the role that writes history cannot remove it and the role that removes it cannot forge it.

02-grants-post-migrate.sql, REVOKE UPDATE, DELETE

Bug captures are locked down at collection

Every form input, textarea and select is masked in a capture and that is not a setting you can turn off. Password fields, iframes, canvas, video and audio are blocked outright. Network request and response bodies are never recorded, only the request line and its timing. Each capture kind is off until you switch it on, per widget.

apps/api/src/lib/capture-policy.ts

Text artifacts are redacted, and it fails closed

A background worker scans stored console output, network trails and DOM snapshots for API keys, tokens, high-entropy strings, email addresses, phone numbers and national identifiers, and replaces them. Until that pass completes the artifact is not viewable, and if it fails the artifact is quarantined rather than released. We say after storage rather than before because that is what it does. Pixels are a different story, and it is the next section.

apps/api/src/workers/capture-redaction.ts

API keys are scoped, hashed and rotatable

A key carries coarse scopes for support, knowledge and feedback, each read or write, and cannot be issued with more permission than the person issuing it holds. We never store the key: only a keyed HMAC-SHA256 digest, the public prefix and the last four characters. Keys expire, revoke immediately, and rotate with a bounded overlap so you do not need an outage.

apps/api/src/routes/api-keys.ts, api-key-credential.ts

Masked in the browser, scrubbed on our side.

Console, network, DOM

Scrubbed on our side by the redaction worker, then flagged and quarantined if the pass fails.

Screenshots and replays

Every input is masked before anything leaves the reporter’s browser, and that is not a setting anyone can turn off. Password fields, embedded frames, canvas, video and audio are blocked outright, and you can add your own selectors per organization. We do not scan the pixels again afterwards.

Screen recordings

Carry the same browser-side masking, then rest on the reporter’s recorded consent. We do not re-scan the frames server side. Off unless you switch it on.

Most recording tools are quietly in the same position and do not say so. Enable recording deliberately, and use the mask and block selectors on the surfaces where it matters.

Your source code

The part that should worry you most

Tore reads a repository in order to work out why something broke and to propose a fix. That is the highest-consequence access in the product, so it is the most tightly bounded thing in it.

You install it, and you can revoke it

Access is a GitHub App you install on the repositories you pick, and remove from GitHub whenever you want. We do not ask for a personal access token, because a personal access token is a key to everything that person can reach.

Three narrow permission sets, and nothing else

Read-only contents and metadata to investigate. Read-only pull requests and administration to work out who owns what. Write access to contents and pull requests only when publishing a fix you approved.

The fix path cannot touch your settings or your CI

It deliberately holds no permission over repository administration, workflows or checks. It can propose a change to your code. It cannot change the rules that govern your code.

No token exists for anything to leak

Every repository operation mints its own short-lived, narrowly scoped token internally and never hands it back to the calling code. There is no long-lived credential sitting in a variable for an executor to log, print or leak.

What is published is byte for byte what you approved

Before the commit is created, the tree the host computed is compared against the digest of the change your reviewer approved. If they differ, the commit is refused rather than published.

Five risk classes stop the automation cold

A proposed change touching authentication, billing, migrations, secrets or tenant isolation is escalated to a person instead of being proposed automatically. A file path the classifier cannot classify escalates too, rather than being waved through.

Nothing merges on its own

Tore opens a pull request. Your review rules and branch protection apply to it exactly as they would to a human contributor, because to GitHub it is one.

The honest summary: the worst case for the fix path is an unwanted pull request sitting in your queue, which your existing review process is already built to reject.

Leaving

Deletion that is checked, not asserted

Most vendors tell you data was deleted. Deletion in Tore runs a verification pass afterwards and records what it found.

A registry, not a guess

Every table in the database carries a written answer to whether it holds end-customer personal data and whether the correct treatment is deletion, anonymization or nothing. Erasure walks that registry rather than a list somebody remembered to update.

Then it counts what is left

The verification pass counts the rows remaining in each table, enumerates the objects and the non-current object versions left in each of the five blob stores, and records the date the backup window closes.

And it fails loudly

If anything remains, or a bucket cannot prove its old object versions expire within 30 days, the run is recorded as failed rather than complete. We can hand you that record.

The timings are contractual, in the Data Processing Addendum: 30 days for active systems, up to 90 days for encrypted backups, and audit events on a 90-day default clock that your organization can change. We do not hand-edit a backup, because a hand-edited backup is not a backup.

The other half

What we do not claim

Most security pages are a list of everything that sounds reassuring. This is the list of things we could write and will not, because they are not true yet. Tore has not launched and has no customers.

We have no SOC 2 report
Not Type I, not Type II, not in progress with a date we can give you. If your procurement process requires one before signature, we are not there yet, and we would rather you hear that now than in week six of an evaluation.
We have no ISO 27001 or any other certification
No audit against any framework has been completed. The controls on this page are real and you can hold us to them contractually through the DPA. They have not been independently attested.
We have not had a third-party penetration test
Our own reviews, including an adversarial pass on authentication, billing, migrations, tenancy, secrets and the fix executor, are not the same thing as an outside team trying to break in, and we are not going to describe them as if they were.
We do not offer a HIPAA Business Associate Agreement
Tore must not be used for protected health information. That is not a paperwork gap we can close on request; it is a statement about what the product is designed for.
We have not appointed an EU or UK representative
There is no Article 27 representative in either jurisdiction. A reviewer will look for one, so it is on this page and it is in the DPA rather than left as a blank line.
There is no multi-factor authentication or single sign-on yet
Sign-in today is email and password, or Google. Enforced MFA and SAML single sign-on are not built. If either is a requirement for you, ask us where it stands before you start rather than after.
We do not redact screen recordings at all
A recording is stored exactly as captured and rests on the reporter's recorded consent, not on a scrubber. Screenshots and replays carry only the masking applied in the reporter's own browser and are not scanned again on our side. Recording is off unless you turn it on. This is the single most important sentence on the page, so it is here rather than buried in a feature list.
Session replay is not something you can turn on
It exists in the data model as a capture kind and it is inert. We are not going to leave it looking available while its hardening is unfinished, and we are not going to quietly delete the option either.
Our redaction is a deterministic scrubber, not a PII engine
It catches key and token shapes, high-entropy strings, email addresses, phone numbers and national identifiers. It is a pattern matcher. It will not catch every way a person can write personal data into a console log, which is why every input is masked and network bodies are never captured in the first place.

Talk to us

Send the questionnaire

If you have a vendor review questionnaire, send it to security@codaslabs.com and we will answer it as plainly as this page, including the questions where the answer is no.

Found a vulnerability? Same address. Tell us what you found and how you found it. We will confirm we received it, keep you updated while we fix it, and we will not come after you for reporting it in good faith. We do not run a paid bounty program yet, and we are not going to imply that we do.

A suspected incident affecting your data goes to the same place, and our notification commitment is 72 hours from the moment we become aware, with what the notice has to contain written down in the DPA rather than left to us.

For enterprise

Data Processing Addendum

The contractual version of this page, with the Standard Contractual Clauses, the UK Addendum, US state privacy terms, and the itemized measures as Annex II.

Vendors

Subprocessors

Every third party that touches your data, what each one does, what it actually receives, and 30 days of notice before that list changes.

Privacy

What we collect where we are the one deciding, and what you can do about it.

Tore is a product of Codas Labs, LLC, a North Carolina limited liability company. This page describes the product as it is built today, not as it is planned. When one of the items above moves from the second list to the first, this page changes on the same day.