Trust Center

Security is the product, not a checkbox.

How NOCTRA_OS protects your data, who we rely on, and exactly where we stand on compliance — stated plainly, including what is still in progress.

2-layer
Tenant data isolation
Enforced
Multi-factor authentication
AES-256
Encryption at rest
In progress
SOC 2 Type II
Checking status…
We publish our uptime publicly — good weeks and bad ones. If something breaks we say so, fix it, and write down what changed so it doesn't happen twice.
Full status & history →

Your data is yours

Customer data belongs to the customer. We process it only to run the service you pay for, and you can request export or deletion.

AI does not train on you

Content sent to AI providers serves your request only — it is not used to train third-party models. Consequential AI actions are staged for a human to approve.

Least data, least access

Services and roles hold only the access they need. The application runs under a restricted database role that cannot cross tenant boundaries.

Transparent uptime

Availability is published publicly, not hidden behind a login, and the platform is monitored continuously.

How we protect your data

The controls that are live in production today

We run the money, records and communications of the businesses we serve, so security is engineered in rather than bolted on. Every control below is live in production today.

Tenant data isolation

The biggest risk in any shared platform is one customer seeing another's data. We defend it at two independent layers, so a failure in either one cannot expose data on its own. At the application layer every request is bound to the signed-in user's own account — a request cannot ask for another company's data. At the database layer, PostgreSQL row-level security enforces the same boundary across 92 tables, under a restricted database role that is not permitted to bypass it. Cross-tenant reads and writes are rejected by the database itself, and we verify that with adversarial tests.

Identity and access

Sign-in runs through a dedicated identity provider using single sign-on, with multi-factor authentication required on every account. Permissions are deny-by-default: an account gets access only where it has been explicitly granted, and the application's own database role holds the minimum privileges it needs to operate.

Encryption

Traffic is encrypted in transit with TLS 1.2 or better on every endpoint. Data at rest is encrypted with AES-256 on managed database storage. Credentials you entrust to us for integrations — mailbox passwords and similar — are encrypted a second time at the application layer, never stored in readable form.

Change management

All platform code is version controlled with a protected main branch and mandatory review before any change is merged. Nothing reaches production by editing a live server directly and hoping.

Monitoring and incident response

Availability is monitored continuously and published openly on our status page — software that stays up is the first honest answer to "is this real?". We maintain a documented incident-response plan with defined severity levels, containment steps and a commitment to notify affected customers without undue delay, targeting 72 hours, if their data is ever involved.

Risk management and testing

We keep a scored risk register that is formally reviewed every quarter, and re-assessed whenever something material changes. Before launch, NOCTRA_OS was put through a structured adversarial security assessment — a deliberate attempt to break it, from a hacker's perspective — covering authentication, tenant isolation, the AI action layer, integrations and data handling. Findings were prioritised and remediated.

Sub-processors

Who we rely on, and what they handle

These are the third-party services NOCTRA_OS relies on to deliver the platform, and what each may handle. We keep this list current and tell customers when it materially changes.

  • Supabase — managed PostgreSQL database (customer and business data) · Canada
  • Keycloak, self-hosted — identity provider and single sign-on (account identity)
  • Stripe — payment processing (billing and payment data) · USA
  • Twilio — SMS and voice telephony (contact details and message content) · USA
  • SendGrid — transactional email (contact details and message content) · USA
  • OpenAI / OpenRouter — AI assistant and automation (prompt content; not used to train third-party models) · USA
  • ElevenLabs — voice synthesis (voice content) · USA
  • LiveKit, self-hosted — real-time voice sessions (voice and session data)
  • Cloudflare — DNS and edge network (network metadata) · Global

Compliance status

Are you SOC 2 certified?
Not yet, and we will not claim otherwise. Our controls are implemented and operating in production today, and we are running the formal observation period a SOC 2 Type II report requires, after which an independent CPA firm performs the examination. This is a matter of elapsed time and independent verification rather than of building the controls, which already exist. We will share the report under NDA once the examination is complete.
Has the platform been security tested?
Yes. Before launch NOCTRA_OS went through a structured adversarial security assessment covering authentication, tenant isolation, the AI action layer, third-party integrations and data handling. Findings were prioritised and remediated, and we can share a summary on request.
Where is my data stored, and is it backed up?
In a managed PostgreSQL database hosted in Canada, encrypted at rest, with automated daily backups by the database provider plus our own independent encrypted backups taken every two hours and kept on separate machines. Recovery has been tested end to end, and is covered by a documented business-continuity and disaster-recovery plan.
Can one customer ever see another customer's data?
Isolation is enforced at two independent layers — the application binds every request to the signed-in user's own account, and the database enforces the same boundary through row-level security under a role that cannot bypass it. Cross-tenant reads and writes are rejected by the database, which we verify with adversarial tests.
What happens if there is a security incident?
We maintain a documented incident-response plan with defined severity levels, containment steps, and post-incident review. If customer data is ever involved we commit to notifying affected customers without undue delay, targeting 72 hours from confirmation, with what happened and what to do about it.
Is the public demo connected to real customer data?
No. The demo runs as a separate instance under its own restricted database role scoped to demo data only, and cannot reach customer tenants.

Security questions, or need the details?

We are glad to walk security teams through our controls, share the assessment summary, or provide the SOC 2 report under NDA once the examination completes.