Security & governance
Structural controls, stated gaps
Security is the shape of the data model, not a settings page.
Nobody joins by signing up
Nobody joins your workspace by signing up. An account inside it exists because a workspace admin or platform staff invited it, or because it was the first-run bootstrap — public signup creates its own separate free workspace and can never reach yours.
Credentials
The email address is the credential; passwords are argon2-hashed. Sessions are opaque server-side tokens delivered as HttpOnly cookies and re-validated on every request.
Two authority axes
Workspace roles (owner, admin, member) are separate from vendor platform staff. In-workspace powers never key off a vendor flag.
Identity & access
How people get in, and what they can reach
Nobody joins by signing up
Nobody joins your workspace by signing up. An account inside it exists because a workspace admin or platform staff invited it, or because it was the first-run bootstrap — public signup creates its own separate free workspace and can never reach yours.
Credentials
The email address is the credential; passwords are argon2-hashed. Sessions are opaque server-side tokens delivered as HttpOnly cookies and re-validated on every request.
Two authority axes
Workspace roles (owner, admin, member) are separate from vendor platform staff. In-workspace powers never key off a vendor flag.
Tenancy as a data property
Every domain row carries its workspace. A record from another tenant is not found — the code path that would return it does not exist.
Session lifecycle
Disabling an account kills live sessions. A self-service password change ends every other session and device.
API tokens
Bearer and refresh pairs, one row per device, opaque and hashed at rest. Replaying a consumed refresh token revokes the device.
Audit
The records that cannot be rewritten
- Stage transitions are append-only — the table has no update path and no delete path
- Outcomes (won, lost) are derived from stage and close action, never a writable field
- Validated pages are saved against a content hash so concurrent edits cannot silently overwrite
- Every AI call writes one row to an append-only per-workspace usage ledger
- Deletion runs through one shared gate rather than per-route checks, and child rows inherit their parent's rule
- Request identifiers are attached to every response and log line
AI governance
Every model call is attributable
All model traffic goes through one gateway. There is no second place in the codebase that can quietly open a connection to a provider.
Each call writes a ledger row attributed to the workspace that caused it, which is what makes usage reviewable, chargeable and — when a policy question arises — answerable.
- One gateway, one ledger row per call
- Assistant actions limited to a fixed whitelist and executed as the approving user
- Model output treated as a draft everywhere: validation, review gates, proposals
- Endpoint and model are configuration, so a local model keeps data inside your network
What did we agree on Alborz's working capital adjustment?
The normalised working capital peg was set at 364.9 B T, based on the twelve-month average and excluding the related-party receivable of 41.2 B T.
Data handling
Where your data is, and what touches it
- Uploads, rendered pages, outputs and audio live in one storage root on the deployment you chose
- Secrets live only in the environment file — never in configuration checked into a repository
- Cookies are marked Secure when the deployment is behind HTTPS; cookie scope is explicit
- Credential endpoints are rate-limited, and failures are uniform so they cannot be used to enumerate accounts
- Invitation tokens are opaque, hashed at rest, single-use and expiring; the raw value appears once, in the issuing response
- No analytics, advertising or third-party tracking scripts ship in the product interface
What we have not done yet
We do not hold SOC 2, ISO 27001 or any equivalent certification. We will not imply otherwise in a sales process. What we can do is describe every control in detail, walk your team through the architecture, and answer a security questionnaire honestly — including the questions where the answer is "not yet".
Single sign-on, SCIM provisioning, customer-managed encryption keys and automated tenant export are not built. Field-level encryption at rest is not implemented; disk-level encryption is a deployment concern we recommend you handle with your standard tooling.
If you find a vulnerability, write to us at the security address on the contact page. We will acknowledge it, keep you informed while we fix it, and credit you if you would like us to.
Security questions
Is our data used to train models?
No. Content is sent to the model endpoint you configured for inference only, and we do not retain or reuse customer content for training. On-premises with a local model, nothing leaves your network at all.Can a vendor employee see our data?
Platform staff can operate a workspace when support requires it — that is how a vendor fixes things. On-premises, there is no vendor access at all unless you grant it. We are explicit about this rather than pretending a support engineer can fix a database they cannot read.How are backups protected?
On cloud, backups are taken nightly and retained on our managed infrastructure. On-premises, backups are yours: a database dump and one directory, protected by your existing policy.
Talk to us about your deployment
Bring your security questionnaire, your network constraints and your timetable. We would rather answer the hard questions before a pilot than after one.