Built for customer data that deserves careful handling.
Quantesic works with support history, account risk, sentiment, renewals, and customer context — one tenant at a time. The posture below is written for the person doing the review: least-privilege access, strict tenant isolation, sealed secrets, and AI that is masked before it reads and reviewed before it acts.
- Identity-first
- Strictly per-tenant
- AES‑256‑GCM secrets
- DLP before model
- Human-reviewed AI
Where customer data lives, and where it doesn’t go.
Signals flow in, assemble into one per-tenant account spine, and reach integrations only through authorized connections. Nothing crosses the tenant boundary — and text is masked before any model reads it.
The control model, line by line.
A documentation-grade summary a security team can scan. No badges we don’t hold, no blueprint we shouldn’t publish — just what is true about how the platform handles your data.
Identity-first access
Access starts from a verified identity, never a shared key.
Every server call carries a verified ID token. Anonymous access is refused.
The application checks tenant-scoped workspace membership before returning a record.
Direct browser-side writes are denied. Mutations run only through reviewed server workflows.
Tenant isolation
Customer data is strictly per-tenant — one workspace never reads another’s.
Accounts, tickets, notes, AI usage, and integration state are scoped to the workspace that owns them.
Role-aware permission checks gate every protected action.
Sensitive configuration is Org-Admin-gated and kept out of ordinary workflow access.
Enterprise identity
Supported for enterprise rollouts and enabled per tenant — never on by default.
Supported. Enabled per enterprise rollout.
Supported. Enabled per enterprise rollout.
Directory provisioning and deprovisioning supported. Enabled per enterprise rollout.
Secrets & encryption
Credentials are treated as sensitive configuration, never ordinary data.
Sealed with AES-256-GCM before storage.
Held in a managed secret store. Never returned to the browser after setup.
Customer data is encrypted in transit across the service.
AI posture privacy
Customer data should not become someone else’s shortcut.
Sensitive fields are masked before any text reaches a model.
AI account tools respect the same permissions as the person using them.
Model output is inspectable and editable before it affects a customer, escalation, or renewal narrative.
Customer data is not used to train cross-tenant models or foundation models.
Integration resilience
Connected systems fail without taking the workspace down with them.
A failing provider is isolated so one outage can’t cascade.
Retries use bounded exponential backoff.
Configured, connected, and active states are surfaced — never assumed.
Operational trust
Administrative access is scoped, purposeful, and visible to you.
Support and trust surfaces show intervention history inside the app.
Operator access is reserved for support, implementation, tenant management, and reliability work.
Product changes ship through source control and production build validation.
What a security review can cover.
Bring your questionnaire and your architecture questions. Here’s what we walk through, and what we can share under a customer agreement.
Architecture
Workspace boundaries, data flow, the integration model, administrative access, and where AI processing happens.
Access & roles
Supported sign-in patterns, administrator responsibilities, user roles, support access, and offboarding.
Data handling
Customer data categories, retention, deletion and export handling, integration scopes, and privacy obligations.
AI governance
The human-review model, provider routing, tenant-level usage visibility, customer key options, and per-customer AI restrictions.
Contractual
Security exhibits, confidentiality, data-processing terms, sub-processor review, and incident-notification terms.
Implementation
Source systems, rollout scope, admin setup, least-privilege configuration, and agreed support procedures.
Security questionnaires and the detailed Trust Pack — sub-processors, DPA, data flow, and incident-notification terms — are handled under a customer agreement.
Clear answers, no blueprint.
High-signal public answers. Evidence and customer-specific control mapping happen in a controlled review.
Can Quantesic complete a security questionnaire?
Yes. We complete customer security questionnaires with supporting explanation, scoped to the review stage and its confidentiality terms.
How is customer data separated between customers?
Data is scoped per tenant and governed by authenticated access, role-aware permissions, and application controls that keep standard users inside their own workspace.
Do you support SSO and SCIM?
Yes — SAML SSO, OIDC, and SCIM 2.0 provisioning are supported and enabled per enterprise rollout, not on by default.
Does Quantesic train shared models on customer data?
No. Customer data is not used to train cross-tenant models or foundation models.
Can customers request export or deletion?
Yes. Export, deletion, and retention are handled through the customer agreement and the implementation process.
How should we review integrations?
Per connected system: the requested authorization scope, its readiness state, and the customer responsibility — each reviewed before rollout.
Do you publish detailed infrastructure diagrams publicly?
No. We share the right level of architecture detail under a controlled review rather than posting sensitive implementation detail on a public page.
Bring the hard questions before rollout.
Walk through access, tenant isolation, integrations, AI handling, and data retention with us — and request the detailed Trust Pack. The context is ready. The judgment is yours.