Security
Your workspace, and only yours.
Each brand's workspace is separated by rules the database enforces, not only by what the interface shows. This page describes those controls in plain terms.
Principles
Four things we hold to.
Fingerprinted decisions
An append-only record
Least access
Controls
What is in place.
Workspace isolation
Every table has row-level security. Access is checked against your workspace membership on every request, by the database itself.
Roles enforced in the database
What an owner, approver, manager or analyst can do is checked in the database, so a request sent outside the interface is refused too.
Exact-version approvals
An approval stores a SHA-256 fingerprint of the version's copy, claims and assets, computed in the database. An edit creates a new version and clears the approval.
No self-escalation
Members cannot change their own role; role changes go through an audited function, and a workspace always keeps at least one owner.
Private files
Assets live in a private storage bucket. Files are served through signed links that expire within minutes.
Encrypted credentials
Platform tokens, when integrations are approved, are stored encrypted (AES-256-GCM) in a table no client can read.
Signed webhooks
Incoming lead webhooks must carry an HMAC-SHA256 signature and a fresh timestamp; replays are refused.
Less personal data
Marketplace order IDs are hashed before storage. Lead contact details are hidden from analysts and approvers.
Reporting a concern
Found something?
If you believe you have found a security issue, please report it privately and do not access data that is not yours. For security reports, contact your IBITS account contact, named in your service agreement.
Your decisions, on the record.
Access is by invitation. Sign in with the email address your workspace owner invited.