Security & data
A dedicated deployment and database for every customer, exactly one audited write path into your ERP, and no model training on anything you give us.
Your own application deployment and your own managed Postgres database, provisioned for you alone at onboarding. Nothing in the data plane is shared with another customer.
Nothing important lives only with us. That is what makes leaving straightforward, and it is the honest answer to what happens if we are not here.
The only thing we write back is a purchase order a buyer has explicitly approved — previewed, confirmed, and recorded. The AI has no write access at all.
The question everyone asks first
Not yet, and we would rather say so than manage the wording. We are an early-stage vendor. Three things stand in for it today, and you can verify all three.
The architecture removes most of what SOC 2 exists to manage. A great many of those controls address the risks of shared infrastructure — one database holding several customers, one application serving them all. You get your own deployment and your own database, so those risks are designed out rather than monitored.
Every subprocessor underneath us holds SOC 2 Type II. The hosting, the database and the AI model API are all independently audited, and they are listed below by name.
Onboarding is itself an audit. Before go-live your controller reconciles our numbers against your ERP and your own bank statements, line by line. Most vendors ask you to trust a certificate; we ask you to check the output against books you already trust.
Certification is on the roadmap as we scale. If your procurement process requires it before you can sign, tell us early and we will be straight with you about timing rather than let it surface late.
In detail
Your deployment is a dedicated, single-tenant environment — your own application deployment with its own URL and its own environment, and your own managed Postgres database, provisioned for you alone. Your data never sits in a shared table with another customer’s. Authorisation is enforced server-side on every request against your tenant’s own access list, and the emergency fallback path resolves only to your named users, never to another tenant’s. Hosting runs on Vercel for the application and a managed Postgres provider for the database, in North American regions.
You create a connected app in your own Salesforce, Rootstock or QuickBooks environment and grant an integration user least-privilege scopes: read on the objects the analytics need, and create on exactly two — purchase-order headers and lines. You hold the credentials, you set the scopes, and you can revoke access at any time from your own admin console. We never ask for your users’ passwords.
In exactly one place, and never on its own: pushing purchase orders your buyers have explicitly approved. Every push is preceded by an on-screen preview and confirmation, is scoped so one buyer cannot push a colleague’s work, is blocked when the underlying data is critically stale, and writes a full audit trail — who approved, who pushed, when, and the resulting PO number. The AI layer has no write access of any kind. Nothing else in your ERP is ever modified.
No, it is not used for training. Under Anthropic’s commercial API terms, inputs and outputs are not used to train models. The AI answers only from your own tenant’s computed analytics — the same derived figures your dashboards show — and it shows its working: every answer lists the data tools it used, and every explanation carries a deterministic “how this is calculated” section computed directly from your data. It cannot invent a figure without that being visible.
Sign-in is through your own Google Workspace, so your password policy, your MFA and your joiner-and-leaver process apply automatically — we are not a second place where accounts live on after someone leaves. Authorisation is a named allowlist with roles, each role seeing its own workspace, and sensitive actions gated further to named owners. Removing someone is one row, effective immediately.
All traffic is TLS-encrypted in transit. Data at rest is encrypted by the hosting providers, and the database provider maintains automated backups. Credentials and secrets are held as encrypted environment configuration, separately per tenant.
Named operations personnel only, for onboarding and support. No offshore teams and no third-party support vendors. Your ERP credentials are scoped by you and revocable by you at any moment.
No. Demonstrations run on a dedicated environment seeded entirely with synthetic data for a fictional company, and that is enforced by an automated check that fails our build if any real customer identity appears in it. Your data is never used in a demo, in marketing, or in another customer’s deployment. We name you as a reference only with your written approval.
It is yours. On termination we provide a full export of your database on request, then destroy the tenant database, the deployment and the credentials within 30 days, and confirm that in writing. Because your ERP stays the system of record throughout, there is nothing to be locked into: nothing lives here that your ERP does not already hold or that the export does not return.
An independent monitor checks every data source daily on the recency of its content — not merely whether a job ran — and alerts on staleness. An external heartbeat checks the deployment from outside our own infrastructure, so an outage cannot go unnoticed because the thing reporting it is also down. The application itself shows users how fresh what they are looking at is.
Subprocessors
We give notice before adding or changing a subprocessor. The full Security & Data FAQ is the security exhibit to our master agreement — ask and we will send it before you are anywhere near signing anything.
Twenty minutes is usually enough to know whether this is worth going further. We’ll look at your ERP with you — and if the data isn’t ready, we’ll tell you that rather than sell around it.