Trust
Trust and security.
We hold public data to a public standard. Here is where we stand today, not where we hope to be.
What the code does today
Each statement below describes something built into One(GLG) and checked in its code. Where we have not done something yet, we say so instead.
Row-level security on every table
Every organization’s records sit in one database, and row-level security decides which rows a signed-in person can read or change. Every table in our schema has it switched on.
A build check reads the schema and fails if any table does not.
A test that tries to cross between organizations
A separate test builds the whole database from nothing, creates two organizations, signs in as a person in the first, and proves the second organization’s rows cannot be read or written.
It runs on every change proposed to our main branch.
A sandbox that sends nothing out
A sandbox organization cannot reach the outside world. Every action that sends mail, takes a payment, publishes a page, or calls an outside service is marked, and the platform refuses it in a sandbox before it runs. Database triggers refuse the same ways out.
A test reads every action and fails if a new one that reaches outside is not marked.
Sealed account credentials
When you connect a Google or Microsoft account, its tokens are sealed with AES-256-GCM before they are stored. They are never kept in plain text, and disconnecting the account deletes them.
A person sends, not the software
OneBox can draft a reply in your voice, but mail leaves your mailbox only when a person clicks Send.
An append-only record of what happened
Meaningful actions are written to one event record: who acted, what they did, and when. People in your organization can read it. Nobody signed in can change or delete it.
A receipt for every AI call
Every AI call goes through one gateway and leaves a receipt: the feature, the model, the tokens, the cost, and the outcome. The receipt keeps a fingerprint of the inputs, not the inputs. Your organization can read and export its receipts on the AI Use page.
A spending cap on AI, per organization
Each organization has a monthly AI cap, set on its AI Use page. The gateway checks it before every call and refuses the next call once the cap is reached. A cap of zero turns AI off, and an organization with no cap set gets no AI calls at all.
Who else handles data
These are the outside services our code can send customer data to. Several only run when they are switched on, and the table says which.
| Service | What for | Where |
|---|---|---|
| Supabase | Database, sign-in, and file storage | United States (us-west-1) |
| Vercel | Hosting for the workspace and this site | United States; the workspace runs in Vercel’s pdx1 region (Portland, Oregon) |
| Stripe | Payments, for organizations that subscribe | [TO CONFIRM: region] |
| Anthropic | AI model calls through our gateway, when AI is on | [TO CONFIRM: region and data terms] |
| Sentry | Error reports, when error reporting is switched on | [TO CONFIRM: whether it is on in production, and region] |
| Resend | The email that tells us someone asked for a demo on this site | [TO CONFIRM: whether it is on in production, and region] |
| Google, Microsoft | Your own mail and calendar, only if you connect that account | Set by your account with them |
[TO CONFIRM: whether any other model provider the gateway supports, such as an OpenAI-compatible service or Azure, is switched on in production]
What we do not claim
This page claims no security certification and no compliance audit. If your purchasing process needs a document we do not list here, ask us what we can provide.
Backups and their recovery window: [TO CONFIRM: whether point-in-time recovery is on, and the result of a restore test]
Report a problem
To report a security concern, email hello@goodlocalgov.com. [TO CONFIRM: a dedicated security address and a security.txt file]
For how we handle personal information, read the draft privacy policy. For the services above in their legal setting, read the draft data processing agreement.