Privacy

This page describes how the LSAS runtime is intended to handle data in a typical deployment. It is not a legal agreement. For binding terms, please refer to your commercial contract and the website terms of use.

LSAS is built for environments where privacy is non‑negotiable. The default stance is to minimize what is stored, keep raw model traffic inside your own network, and expose telemetry that is useful for governance without leaking more than is necessary.

What LSAS stores by default

  • Derived telemetry about each request and response, not full raw content.
  • Risk scores, validator findings, and decision outcomes per LSAS domain.
  • Identifiers for tenant, application, environment, and upstream workflow.
  • Policy pack versions, configuration snapshots, and change events.

What LSAS does not store by default

  • Raw prompts and completions, unless you explicitly configure that behavior.
  • End‑user identifiers beyond what you choose to send as metadata.
  • Model weights or provider‑side telemetry; those remain with your chosen LLM vendor.
  • Cross‑tenant data; each tenant/app boundary is explicit in the event model.

Customer boundary & deployment

  • Private deployment by default: private single-tenant, customer-hosted cloud/VPC, or self-hosted/on-prem.
  • Managed sandbox evaluation is available for non-production validation.
  • Database, object storage, and logs live in your accounts, under your IAM.
  • Integration with your identity provider for administrative access.
  • Network boundaries and residency dictated by where you deploy the stack.

Retention, encryption, and access

  • Telemetry retention governed by your database and logging lifecycles, aligned with your policies.
  • Encryption at rest and in transit using your cloud provider primitives.
  • Role‑based access in the console to restrict who can see what.
  • Support for read‑only roles for auditors and oversight functions.
  • Session controls include explicit expiration, centralized issuance, and password-reset invalidation of prior sessions.
  • API key lifecycle controls support one-time reveal, explicit revocation, and version-safe updates under concurrent admin activity.

Demo sandbox behavior

The public demo sandbox is intended for non‑production experimentation. It is not a place to paste real PHI, PCI data, or confidential production content. Treat it like any other internet‑facing demo: useful for exploring behavior, not for handling regulated data.

  • No guarantees that demo data will be retained or recoverable.
  • Traffic may be throttled, reset, or deleted without notice.
  • Do not rely on sandbox behavior for formal validation or audits.

Related documents

Privacy should be read together with security and responsible‑use guidance. The combination describes how LSAS is expected to behave, how you deploy it, and how it should and should not be used.

Next steps

Evaluate LSAS in your environment

Flexible deployment for regulated teams: managed evaluation sandbox, private single-tenant deployment, customer-hosted cloud/VPC deployment, or self-hosted/on-prem rollout.

  • Customer-hosted by default
  • Policy packs per app and tenant
  • Audit-ready telemetry out of the box

Guided evaluations and design partner programs are available for teams operating under SOC 2, ISO 27001, HIPAA, and similar frameworks.