Security statement

Security statement

This page is written for the people who have to sign off on SUPERWISE Chat: your IT, security, and compliance teams. It explains how we protect your data, how access is controlled and recorded, who else touches your data, and where we stand on the certifications and regulations you care about. We’ve written it to be accurate rather than impressive — where something is a current control we say so, and where something is a roadmap commitment we say that too.

The short version

Your data is encrypted in transit and at rest. Every person and every request is authenticated and authorized before it can do anything. Each organization’s data is isolated from every other organization’s. Administrative and policy actions are recorded in tamper-resistant audit trails. And every message is reviewed for safety on the way in and on the way out — by design, and on the record.

How to use this page

If you’re running a vendor security review, you can read this top to bottom — it follows the order most questionnaires use: encryption, access control, isolation, audit, subprocessors, and compliance posture. If you need a formal Security Statement document, a completed security questionnaire, or a signed Data Processing Addendum for your procurement file, contact your SUPERWISE representative; this page is the public summary, not a substitute for those documents.

Encryption

We protect your data both while it moves and while it sits.

• In transit. All traffic between your users’ browsers, the Chat service, and the services Chat depends on travels over TLS. Real-time messaging uses an encrypted WebSocket connection. There are no plaintext network paths to your data.
• At rest. Conversation content, knowledge documents, memory, account records, and audit logs are stored in encrypted storage. Database backups are encrypted as well.
• Secrets. Credentials such as identity-provider keys and service tokens are never stored in conversation data or in application logs. They’re held as managed secrets, separate from your content.

Access control

Nobody — and nothing — acts in Chat without first proving who they are and then being checked against what they’re allowed to do.

Authentication

Chat does not run its own password database. It authenticates every user through your identity provider using standard, signed sign-in tokens (OIDC). We validate each token’s signature, issuer, and audience on every request, so a token minted for another service can’t be replayed against Chat. Sessions are short-lived and expire automatically. For details on connecting your provider and enforcing single sign-on, see Identity and SSO.

Authorization (role-based access control)

Once a user is authenticated, every protected action is checked against their role before it runs. If a user’s role doesn’t carry the required permission, the request is refused — there’s no “soft” path around it.

Roles are arranged in a hierarchy, so a more powerful role inherits the permissions of the roles beneath it, and oversight-only roles exist specifically for compliance and security reviewers — people who need to see what happened without being able to change anything. A few safeguards keep this honest:

• You can’t grant yourself more power. A user can only assign roles below their own level, and only administrators can change top-level role assignments.
• Role definitions can’t be tampered with at runtime. The permission map is fixed in code and frozen when the service starts; it can’t be quietly altered while the service is running.
• Cross-organization access is the rare, controlled exception. The only way a platform operator can act in the context of a specific customer is through a deliberate, time-boxed session that expires automatically (within hours), is recorded, and can be revoked early. It can’t be assigned as a standing permission.

For the full list of roles and what each one can do, see Users and roles.

Tenant isolation

Each customer organization is a separate tenant, and one tenant can never see another tenant’s conversations, documents, memory, or settings. Every read, every write, every cached value, and every audit query is scoped to the tenant making the request, and that scoping is verified by an automated isolation test suite that runs as part of our development process. The single, controlled exception — the time-boxed, audited cross-tenant operator session described above — never relaxes the data boundary on its own; it only changes which tenant an authorized operator is acting within.

We are also rolling out database-enforced isolation as a second, independent layer underneath the application — so that isolation holds even in the unlikely event of an application-level mistake. That layer is built and tested but not yet the live control; turning it on is a planned, reversible operational step. We mention it here for completeness, and we’re deliberate about not overstating it: today, isolation is enforced in the application, and that control is real and verified. For a fuller explanation, see Tenant isolation.

Audit and oversight

Security only matters if you can prove what happened. Chat keeps several independent, hard-to-erase records:

Record	What it captures	Integrity
Access-control changes	Every role assignment, removal, and access change — who did it, to whom, when	The application has no ability to update or delete these rows; removal is a database-administrator action only
Settings changes	Every change to workspace and governance settings	Strictly append-only — entries can be added but never modified or deleted, even by an administrator
Safety reviews	The outcome of each safety check applied to a message (passed, skipped, did not pass, or errored)	Recorded per message for governance review
Consent changes	Each time a user grants or withdraws consent for an optional data use	Per-user, kept as a history trail

These records are visible to oversight and administrator roles through the governance and audit views in the product. Administrators cannot delete audit entries — that’s the point. See Audit and usage for how to read and export them.

Safety review on every message

Chat reviews messages for safety at multiple points: as a message comes in, across the evidence gathered to answer it, on the assembled request before the AI sees it, and on the response before it reaches the user. The two later checks — on the assembled request and on the outgoing response — are designed to stop and refuse rather than risk an ungoverned answer if the safety service is ever unavailable. This isn’t optional or hidden: the use of AI safety evaluation is disclosed to users as an essential processing activity, and users see a brief notice when a message has been reviewed. The governance side of this is covered in Governance and policy.

Data retention

You control how long your conversations live, and some operational data is purged automatically:

• Conversations are retained as long as you keep them and can be deleted on request; tenant administrators can set inactivity-based deletion windows.
• Operational logs and execution records are purged automatically on a rolling window (on the order of 90 days) so they don’t accumulate indefinitely.
• Session tokens expire automatically within hours.
• Audit trails are retained to support compliance review. Settings-change history is permanent and append-only; access-control and safety-review history follow a retention policy that today is supported by administrator-driven archival rather than an automatic purge job — we’re candid that the automated enforcement of those specific retention windows is still being completed.

For data-subject deletion requests and how a user’s data is removed, see DSAR and deletion. For a closer look at what is logged and why, see Data flow and logging.

Subprocessors

To deliver the service, Chat relies on a small set of third parties:

• Your identity provider, to authenticate users (we validate the tokens it issues; we don’t store your users’ passwords).
• A managed database and cache, where your encrypted content and operational state are stored.
• A large-language-model provider, which generates AI responses to your messages.
• The SUPERWISE safety platform, which evaluates messages against the safety policies you’ve configured.

We maintain a current subprocessor list and provide it as part of vendor review, along with the safeguards governing each relationship. Request the up-to-date list from your SUPERWISE representative.

Compliance posture

We aim to give you an honest read of where we are, not a checklist of aspirations dressed up as facts.

GDPR

Chat is built with GDPR principles in mind. Processing activities are disclosed to users with a stated legal basis for each, and users can grant or withdraw consent for optional uses (such as memory extraction and document indexing) while essential activities required to provide the service (such as processing your message to answer it, and the safety evaluation) cannot be switched off without ending use of the service. Deletion and data-export support are described in DSAR and deletion. For EU customers we offer a Data Processing Addendum in which you are the data controller and SUPERWISE is the processor — see Data processing and the DPA.

SOC 2

If your review requires our current SOC 2 status, audit reports, or attestation letters, request them from your SUPERWISE representative under NDA. We don’t publish certification status on this public page.

Sector and regional regulations (CCPA/CPRA, HIPAA, AI regulation)

• CCPA/CPRA. The data-subject rights tooling (access, deletion) that supports GDPR also supports California privacy requirements.
• HIPAA. Chat is not positioned as a HIPAA-compliant service today, and protected health information should not be entered into it. If a HIPAA path is relevant to you, raise it with your SUPERWISE representative.
• AI-specific regulation (e.g. the EU AI Act). Chat already provides the building blocks these frameworks emphasize — transparency to users about AI use, human oversight roles, and a recorded safety-review trail. We track emerging requirements and will tell customers as obligations firm up.

What we won’t claim

We won’t tell you a control is live when it isn’t. Where a stronger protection is built but not yet the active control (the database-enforced isolation layer) or a retention window is policy-defined but not yet auto-enforced, we’ve said so on this page. If a security review needs the precise current state of any control, ask — we’ll give you the accurate answer in writing.

Reporting a security concern

If you believe you’ve found a security issue, or you need to report a suspected incident, contact your SUPERWISE representative or your organization’s designated security contact immediately. For breach-notification terms and timelines, see the Data Processing Addendum.

Related pages

• Tenant isolation — how one organization’s data stays separate from every other’s.
• Data flow and logging — what is recorded as your data moves through Chat.
• DSAR and deletion — handling access and deletion requests.
• Data processing and the DPA — controller/processor terms for EU and enterprise customers.
• Identity and SSO — connecting your identity provider and enforcing single sign-on.
• Governance and policy — the safety and oversight controls you configure.