One customer can't see another
The database itself keeps each organization's data apart, on every query.
hoping every query remembered its filterPlatform · Security and audit
Your data, walled offby the database itself.
Each organization is kept apart below the application, not by code that has to remember a filter. Tore opens proposed fixes on its own branches for a person to approve, never merges or pushes to your main branch, and its access is revocable, your code never trains a model, and everything that matters is recorded.
Tore opens soon. Join the waitlist and we'll email you the day you can start.
app.tore.ai/beacon-data/security
Example data Example: a query runs as Beacon Data. The database returns only Beacon Data's conversations; Acme Corp's and Northwind's rows are walled off and never returned. Beside it, the audit log records Alex turning on required two-factor sign-in, Tore reading the beacon app repository and opening a fix pull request on its own branch, a secret fetched from Beacon's own vault for one run and released, and a proposed change to the sign-in code held for a person because authentication is a locked risk class, with Take over and Request changes buttons.
Built so you don'thave to take our word for it.
Every protection here is a mechanism in the product, not a paragraph in a policy.
Access you can take back
Tore reads your code and proposes fixes through a GitHub app that never merges, and you can remove it in one click.
a personal token with the keys to everythingYour code stays yours
Your code is never used to train a model, and Tore never holds shell or cloud access.
reading AI terms of service to find outAnswer "who changed this?"
The audit log records who did what and when, people and AI alike.
piecing it together from chat historyHow it's built,in plain words.
Isolation
Kept apart below the application.
Every query runs as one organization, and the database checks every row against it. Application code can't forget a filter, because the filter isn't in the application code. Agencies running many clients get the same wall between each one.
- Data isolated per organization by the database itself
- Checked on every query, not only the ones someone remembered
- The same wall between every client in an agency account
database · tenant check
Illustration-- every request starts like this
set local tenant = 'beacon-data';
select id, subject from tickets;
beacon-dataExport stops at 1,000 rowsreturned
beacon-dataDark mode resets after reloadreturned
northwind••••••••••••••••filtered by the database
acme-corp••••••••••••••••filtered by the database
Your code and credentials
Proposes, never merges. Never trained on.
Tore reads the repositories you pick through a GitHub app and opens proposed fixes as pull requests on its own branches, for a person to approve. It never merges or pushes to your main branch, and you can remove it in one click. It never holds shell or cloud-console access. When a test run needs a secret, Tore fetches it from your own vault for that run only.
- GitHub app: on the repositories you choose, fixes proposed on its own branches
- Never merges or pushes to your main branch
- Your code is never used to train a model
- No shell or cloud-console access, so nothing to lock down
- Secrets stay in your vault and are fetched only when needed
- Auth, billing, migrations, personal data, tenant isolation and secrets always go to a person
settings · repository access
Example dataCode and historybeacon/app, beacon/api
readMerge or push to mainfixes arrive as pull requests on its own branches
neverTraining on your codeany model, any provider
neverShell and cloud consoleservers, databases, deploys
neverLocked risk classesauth, billing, migrations, personal data, tenancy, secrets
a person decidesSecrets: read from your vault per run, never stored by Tore
Remove Tore's access to every repositoryRevoke
Audit and sign-in
A record of who did what.
The audit log captures every consequential action, by a person or by Tore, with when it happened. Require two-factor sign-in for your team, or hand sign-in to your identity provider with SAML single sign-on.
- Audit log of who did what, and when
- Tore's own actions are in it, next to your team's
- Two-factor sign-in, and SAML single sign-on
settings · audit log
Example dataEveryonePeopleToreSettingsLast 7 days
Sarah changed routing for beacon-appTore proposed a fix for
TCK-482
Alex approved PR #482
Dan created API key Help center sync
Lena invited tomas@beacondata.ioTwo-factor sign-inRequired for all
Single sign-onSAML · connected
Your data, your rules
Export it all. Delete it for real.
Download everything you have in Tore whenever you like, so you are never locked in. Set how long each kind of data is kept, and when something is deleted, it is actually deleted.
- Full data export, any time
- Retention rules you set per kind of data
- Deletion that actually deletes, with no manual cleanup
settings · data
Example dataConversationsemail, widget, Slack
24 months Bug capturesscreenshots, recordings, console
90 days Closed ticketswith their investigation
36 months Deletion request for maya@northwind.io · her conversations, captures and contact record removed. Logged in the audit trail.
beacon-data-export.zipready to download
Tune it
Locked risk classes 6, plus your ownAutonomy per repositoryRepositories Tore can read you pick
6risk classes locked to a person
1click to revoke repository access
0shell or cloud-console access held by Tore
0models trained on your code
Keep exploring.
Connect a repository.Keep the keys.
Install the GitHub app on the repositories you choose. It proposes fixes as pull requests and never merges them. Remove it whenever you like.