Instub asks first.
You invite it in.
The trust model
Invited channels only
Instub reads a channel only after a human invites it in. No workspace-wide ingestion, ever. Remove it and its access ends with the membership.
Approval before it leaves
Instub asks before it sends, spends, submits, or purchases on your behalf, and the run waits until a person answers. Every action is audited, whether you approved it or policy did.
Per-person permissions
Integrations are scoped to the person who connected them. Instub acts with your Stripe access only on your say-so, and a tool you connect read-only cannot write at all.
How your data is handled
One tenant, one boundary
Each workspace runs in its own isolated environment. Nothing — memory, files, learned formats — crosses between customers.
Yours to delete
Your environment keeps context so Instub can keep working. Delete anything, or all of it, at any time; deletion requests complete within 30 days.
Never trains models
Your messages, files, and connected data are never used to train models, ours or any provider we route to. That's contractual, not a setting.
Your workspace
Slack · Microsoft Teams
Instub runtime
Encrypted, both directions
Integration credentials live in a separate vault with per-tenant keys.
Compliance
SOC 2 Type II: in progress
Our Trust Center holds our security, compliance, governance, and trust documentation, and shows the controls we monitor, live. The report will be available there when the audit completes.
Pen-test summary is available on request. For privacy or processing questions, write team@tryinstub.com.
Report a vulnerabilityThe honest part
Models can be wrong, whichever one the task lands on. Instub cites its sources so you can check them, names the model it used, shows its plan so you can stop it, and asks before anything leaves, so mistakes stay reversible.
If a tool returns an error, it stops and says so — it doesn't retry sensitive actions on its own.