LSAS Platform Docs
Private deployment and shared responsibility.
Define the deployment boundary, the operating owners and the evidence needed to put LSAS to work in your environment.
For privately deployed environments, customers provide the agreed infrastructure and storage environment. LSAS supplies the supported application, with deployment-package contents and delivery agreed and qualified for the engagement. Patch management, backup, recovery and support responsibilities are defined in the applicable agreement.
Choose the right path
Hosted Developer Evaluation
Use an evaluation key to call LSAS-hosted evaluation services with synthetic or non-sensitive test data. Exercise supported released, blocked, transformed and held outcomes, then inspect policy explanations and evidence. The existing activation rules, quotas and scenario limits apply. Evaluation access does not authorize production use, unrestricted agent execution or real model-provider invocation.
Compare evaluation and deployment optionsDiscovery Scanner
LSAS coordinates restricted distribution of the Windows and macOS scanner packages. The public Discovery offering evaluates approved local files without automatic result uploads to LSAS; customers control report sharing. SQL Server sources require separate connection setup, least-privilege access and qualification. Source connections can use approved customer network paths.
Configure the supported services and destinations before execution. The local assessment also has an operator-configured compatibility mode for recording derived results through a local gateway. That mode does not make the offline buyer offering a hosted upload service or qualify every SQL configuration.
Review Discovery scopeEnterprise private deployment
Scope the LSAS gateway, web application, required worker services and PostgreSQL within the agreed customer-controlled VPC or on-premises topology. The delivery package, supported versions, installation process and acceptance criteria are agreed with LSAS before delivery. Private deployment is a coordinated engagement, with qualification for the actual environment.
Agree delivery and prerequisites
The deployment statement of work should identify:
- The application release, package contents, artifact identifiers or checksums, delivery channel and supported dependency versions.
- Qualified compute and operating environment, PostgreSQL version and capacity, storage, DNS, TLS, network boundaries and service identities.
- Environment configuration, secret provisioning, identity integration, database migration ownership and validation steps.
- License entitlement and validation method, any required validation endpoint or outbound connection, and agreed behavior during a validation outage.
- Installation, rollback and acceptance procedures, supported integrations, exclusions and named customer IT and LSAS contacts.
Infrastructure sizing and costs depend on the agreed workload, retention needs and availability design. Confirm them through architecture review rather than treating a reference topology as a qualified deployment.
Make data and network boundaries explicit
Plan customer workload telemetry and evidence storage within the agreed deployment boundary. Document where each enabled service processes or stores data, including backups, diagnostics and reports shared for support.
Configured model providers, connectors, email and other external services can transmit permitted payloads outside that boundary. Review destinations, credentials, allowed data, network controls and retention before enabling an integration. A private deployment does not by itself mean that every data flow stays inside the customer environment.
License-validation dependencies must also be established in the deployment agreement. Do not assume disconnected or air-gapped operation: any such requirement needs an explicitly supported and qualified configuration.
Shared responsibility
This baseline separates application responsibilities from customer-operated infrastructure. The executed agreement records any changes and names the accountable owners.
| Responsibility | Primary owner |
|---|---|
| LSAS application code and product defects | LSAS |
| Supported releases and software patches | LSAS |
| Infrastructure provisioning, VPC networking and security groups | Customer |
| PostgreSQL operations and storage | Customer, unless otherwise contracted |
| Infrastructure backup and disaster recovery | Customer, unless otherwise contracted |
| LSAS application configuration | Shared, as scoped |
| Scheduling and applying private-environment updates | Shared, as scoped |
| Policy ownership and risk acceptance | Customer |
| Policy implementation and technical configuration | LSAS / Customer, as scoped |
| Application-generated telemetry and evidence functionality | LSAS |
| Evidence retention settings and regulatory retention decisions | Customer |
| License entitlement validation | LSAS, subject to the deployment agreement |
| Operational monitoring and incident response | Defined in the service agreement |
Operate and maintain the deployment
LSAS provides supported application releases and software patches. Customer IT and LSAS agree who tests, schedules and applies each private-environment update, including migration prerequisites, maintenance windows, rollback and confirmation of the installed version. Operating systems, infrastructure and database maintenance remain with the customer unless contracted otherwise.
Assign PostgreSQL provisioning, access, monitoring, capacity and lifecycle ownership. Record backup scope, encryption, storage locations, restore procedures and recovery objectives; qualify recovery by exercising the agreed procedures. No recovery time or data-loss guarantee follows from the reference architecture.
Customers own evidence-retention decisions, applicable retention requirements and legal holds. Align application settings with database and backup retention, storage capacity and authorized access. LSAS supplies the supported telemetry and evidence functionality; retention settings alone do not establish regulatory compliance.
Document monitoring, incident routing, diagnostic sharing and escalation contacts in the service agreement. Included support hours, coverage windows, acknowledgment targets and availability commitments are separate terms.