Security
Built so you can prove what happened.
Written for whoever reads this before a pilot. Below is how Brikt is actually built — the mechanisms, and the property each one buys you — rather than a page of adjectives.
In plain terms
The short version, before the detail.
If you are forwarding this page to somebody who has to sign off on it, these are the five things it says. Everything below is how each one is actually done.
Your company's data is kept apart from every other company's by the database itself, not by our code remembering to ask.
Claude can read and draft. It cannot change your schedule. Only a person can, and the change is recorded against their name.
Every change carries who made it, when, and through which door — the interface, the API, or a proposal somebody applied.
Someone you invite works from the schedule and never sees your costs, your internal notes or your baseline comparisons.
A share link you revoke stops working, and a link that misses tells whoever holds it nothing at all.
How it is built
Eight things worth checking.
Each of these is a property of the system rather than a policy about it — the kind of thing you can put a question to in a demo and watch the answer.
Tenant isolation in the database
Every table carries Postgres row-level security. Isolation is enforced by the database on every query, not by application code remembering to add a filter — so a missing clause in a new feature cannot leak another company's project.
Per-field concurrency control
Two people can work the same activity. Brikt versions each field: an edit made against a value someone else has already changed is caught and shown to you, rather than silently winning. Recomputes run inside a project-level lock, so the window where two writers could both pass the check is closed.
AI that cannot act alone
Claude reads and drafts. It cannot commit a change. Every AI-authored change goes through a human review surface and is applied by a person, logged and attributed to them. The MCP connector exposes no apply at all — not disabled, absent.
A wrong link tells you nothing
A share link that misses returns the same 404 whether the token was revoked, expired, malformed, or never existed — one response for every case, down to the byte. Nothing about your projects can be learned by guessing at addresses, and no error message is more useful to an attacker than to you.
Deny by default on every read
A field an account may not see is absent from the response, not blanked in the browser. Redaction happens where the data is served, so what reaches a collaborator's device is only what they are entitled to.
Authentication through WorkOS
Sign-in is handled by WorkOS. Sessions are encrypted and revocable, and Brikt never stores a password.
An audit trail that answers questions
Who changed what, when, and through which door — the interface, the API, or an applied proposal. A change Claude drafted is attributed to the person who applied it, never to the software.
Deletes you can walk back
Deleting an activity removes it from the schedule without destroying it, and it can be restored. A bad afternoon is recoverable rather than final.
People outside your company
Everyone on the job, without giving the job away.
Subcontractors, owners and architects join as first-class accounts with their own sign-in — never a shared password and never a spreadsheet emailed around.
Invited collaborators work from the real schedule — dates, float, the critical path — while your costs, internal notes, and baseline comparisons stay yours.
What they cannot see is withheld at the server, not hidden in the page — so it is not sitting in the browser of someone you invited, waiting to be found.
Bring your reviewer to the demo.
Questions about tenancy, access or the audit trail are the ones we most like being asked.