Security & data architecture
Your AI workforce operates inside your boundaries.
You're handing a platform your pipeline, your candidates and your systems of record — it should be obvious why that's safe.
Defense in depth
Enterprise-grade architecture. Built for teams that don't have an enterprise budget.
Designed and built by an operator with 30 years in enterprise IT.
- The same discipline enterprises pay consultancies for
- Applied to a platform a small or mid-size company can actually afford
- Run without needing an internal IT team
- dedicated domain
- dedicated database · db-acme
- own keys · own secrets
- region us-east
- dedicated domain
- dedicated database · db-harbor
- own keys · own secrets
- region us-west
- dedicated domain
- dedicated database · db-your-co
- own keys · own secrets
- region eu-west
What the platform cannot do
The guarantees worth writing down are the ones about what can't happen.
The control plane cannot query your records. It holds configuration, policy and keys — not messages, contacts or candidates.
An employee in one tenant cannot reach another tenant's database. There is no shared connection to misuse; the route does not exist.
Your data is not used to train a shared model. Employees are prompted with your context at run time through controlled platform interfaces; nothing is fine-tuned on it and nothing is learned across customers.
A gated action cannot execute without an approval event in the ledger. The gate is a state transition, not a UI checkbox.
An adapter cannot exceed the scopes you granted; credentials are encrypted per tenant. Revoking one adapter does not touch the others.
For multi-entity customers, one company's pipeline, spend and permissions cannot leak into another's — entity is a boundary in the data model, not a filter in the UI.
Tenancy
One customer, one environment.
Each customer is provisioned a dedicated domain, a dedicated database with its own credentials, and its own secrets. The platform's control plane provisions and configures tenants; it does not store or process tenant records. This is isolation at the infrastructure boundary, not a customer-id column.
Data handling
Encrypted in transit and at rest. Scoped at every hop.
TLS everywhere; encryption at rest on the tenant database and storage; secrets in a managed key store, per tenant. Workers read the minimum a work object needs, at run time, through adapters with least-privilege scopes — the platform is not a warehouse of your CRM.
Models
Prompted with your context. Never trained on it.
Model calls carry the context needed for one work object and nothing more. No customer data is used to train or fine-tune any model — ours or a provider's. Corrections you make in the approval queue are stored as patterns inside your tenant and applied by your workers only.
Approvals & audit
Policy is enforced in the state machine.
Approval policy compiles to gates on work-object transitions. A gated object cannot move to executing without a recorded approval by an authorised person. Every read, write, decision and approval is a ledger event with a timestamp, actor and work-object id — queryable in the product and exportable for your auditors.
Access
Roles you define. Identity you already run.
Role-based access for operators and approvers, per tenant. Single sign-on plugs into whatever already manages your domain — Microsoft 365 / Entra ID, Google Workspace, or Okta — with SCIM provisioning available for enterprise deployments. Approver roles are the same roles referenced in policy, so 'who can approve pricing' is one answer, not two.
Compliance
Built for the review, before the badge.
The architecture is designed around the questions security questionnaires actually ask — tenancy, data residency, model data use, access control, audit. It's built the way an enterprise reviewer expects, before there's a badge on the wall to prove it.
See it running on your systems.
Thirty minutes, your data, one workflow end to end. Any question about how it's built, we'll answer on the call.