Trust

Security you can verify, claims we can back

This page describes controls that are implemented in the product today. Scholar XI does not hold SOC 2, ISO 27001, HIPAA or FedRAMP attestations, and we do not display badges for them.

Implemented controls

  • Tenant isolation

    Available

    Database row-level security, scoped storage paths, scoped caches and per-tenant queue leases.

  • Server-side authorization

    Available

    The client never decides access. Every server function re-checks the caller's role.

  • Server-held credentials

    Available

    Provider and connector credentials never reach the browser.

  • Data classification

    Available

    Workspaces inherit a classification; confidential scopes block external tool calls.

  • Encryption in transit

    Available

    All traffic to Scholar XI and to connected services uses TLS.

  • Audit logging

    Available

    Administrative and approval events are recorded with actor and timestamp.

How isolation works

Every tenant-owned row carries its organization and workspace. Access is enforced by row-level security policies in the database, so a query that escapes an application check still returns nothing. Storage objects live under tenant-scoped paths and are served through short-lived signed URLs.

Semantic caches, background job queues and memory stores are keyed by tenant scope. Entries written under one scope cannot be read under another, and legacy or forged keys are rejected rather than tolerated.

Workspaces carry a data classification that projects and conversations inherit. When a scope is classified confidential, XI is blocked from calling external tools with that content.

Provider and connector credentials are held server-side only. They are never sent to the browser, and internal model infrastructure is not exposed in customer-facing responses.

Running a security review?

Send us your questionnaire and we will answer it against what is actually implemented.