How your data is held

Separation between customers

Each workspace has its own database. That is a boundary rather than a filter on a shared table: a request that resolved to the wrong workspace would reach a different database entirely, so it cannot read another customer's rows even by accident. There is no query in this product whose correctness depends on remembering to add a tenant condition.

Who can do what

• Roles, and a table generated from the enforced matrix. The roles table is produced from the same permissions the product checks, so it cannot describe access we do not implement.
• A credential can never exceed the person behind it. An API token and an agent connection both hold the intersection of the scopes they were given and the live role of the member who approved them, read at request time. Demote somebody and every credential they created weakens in the same moment.
• Confirming a value is reserved to a person. The one thing no token and no agent can do, whatever scopes it carries, because a confirmation means somebody checked it.
• Tokens are stored as hashes and shown once, at creation.

What is on the record

Every change to your records carries who made it, when, through which surface, and how they came by the value. That is the ledger the product is built around, and it covers writes from the application, the API and an agent equally.

Credentials carry their own account: a token and an agent connection each record who created them, the scopes they hold, and when they were last used, so "who has access and are they using it" is answerable at any time. Membership and role history live in your identity provider, which is where that record belongs. Authentication is exact about all of it.

Deletion, and the part most products miss

Deleting a workspace destroys the records, the history and the search index, including the index's own residue. That last part is worth saying because it is easy to get wrong: a full-text index keeps deleted terms in its storage until it is compacted, so an erased contact's email address can stay readable in the index long after the record is gone. Indraft compacts on deletion for that reason. Deletion and portability has the detail.

Who else touches your data

Three subprocessors, and no others: Cloudflare for hosting and compute, WorkOS for identity, Stripe for billing. No CRM record reaches Stripe. Indraft implements no passwords, no multi-factor, and no session issuance of its own. The list, with what each one processes and why, is on Subprocessors, and the data processing agreement applies automatically rather than on request.

Nothing in your CRM is used to train a model. Your agent is your own, and the connection between it and Indraft is authorized by you and revocable by you at any time, taking effect on that connection's very next request.

Your data leaves as easily as it arrived

The whole workspace exports from your own settings: one spreadsheet per table, the records and their history, and a written explanation of how the files join up. It opens in Excel, Numbers, Sheets and LibreOffice with no conversion. Nothing is held back and nothing is trimmed to fit: above 100 MB in one file the export refuses rather than truncating, and we run it for you in that case. Below that there is no request to raise and no window to wait out.

That is worth exercising on your first day rather than taking on trust. About has the detail.

Questions a review usually asks

If your process needs something specific, write and ask. You will get a straight answer, including when the answer is no, and you will get it before you have spent a week on a pilot rather than after.

Telling us about something

If you find a security problem, write to hello@indraft.io with enough to reproduce it. You will get a human reply within one working day. There is no bounty programme and no legal threat waiting for you either.