LSAS Specification
Layered Safety & Accuracy System (LSAS)
LSAS (Layered Safety & Accuracy System) is an open specification for implementing execution boundaries around GenAI and tool-using systems. It defines how model outputs, tool plans, and API payloads are classified, validated, escalated when required, and recorded as structured artifacts.
What is LSAS?
LSAS (Layered Safety & Accuracy System) is an application-layer firewall and execution boundary architecture for GenAI and tool-using systems.
Operationally, LSAS sits in front of models, tools, and external APIs as an execution boundary, treating all model outputs, tool plans, and API payloads as untrusted until they are classified, grounded where necessary, validated, escalated when needed, and recorded as structured artifacts.
LSAS is designed for organizations that require AI systems to operate within explicit architectural and runtime constraints. It turns implicit assumptions about safety and behavior into versioned, inspectable specifications.
LSAS Stack: Reference Implementation
LSAS Stack is a concrete implementation of the LSAS Specification. It demonstrates how the specification translates into a production-grade execution boundary with real endpoints, validators, and structured artifacts.
What LSAS Stack is
- A Fastify-based gateway and runtime that sits in front of both LLM providers (e.g., OpenAI-compatible APIs) and your existing JSON/REST services.
- A deterministic validator and policy engine that turns every call into a structured decision: ALLOW, REDACTED, BLOCKED, or ESCALATE_HITL, with severity and reasons.
- Configurable policy packs for privacy, security, accessibility, and prompt integrity.
Key interfaces
LSAS Stack exposes simple, developer-friendly endpoints:
- POST /v1/chat/completions — OpenAI-compatible. Applies validators and policy packs, calls the upstream model when allowed, and returns the model response plus LSAS metadata (decisions, findings, redactions).
- POST /v1/payload/sanitize — accepts arbitrary JSON payloads and returns a sanitized data object plus structured lsas findings for use in front of existing APIs.
A Sandbox demo UI shows exactly what would be redacted, blocked, or escalated — and why — making LSAS behavior transparent to engineering, security, and clinical or risk stakeholders.
LSAS Stack Sandbox
Visualizes exactly what LSAS Stack redacts, blocks, or escalates for a given request — and why — so engineering, security, and risk stakeholders can see the boundary in action.
How LSAS Stack fits your environment
LSAS Stack is designed to live inside your VPC, close to your existing systems and controls. Your boundary matters more than any vendor cloud.
Self-hosted gateway
- Containerized, self-hostable deployment, suitable for Kubernetes or your preferred orchestration.
- Sits in front of multiple LLM providers and internal JSON/REST services.
- Acts as a policy enforcement point for both AI and high-risk API traffic.
Deterministic validation
- Validator pipelines for PHI/PII, PCI-like data, secrets, security, prompt injection, and accessibility.
- Each call emits structured decisions, severities, and rule hits instead of opaque scores.
- Policy packs let you express HIPAA, PCI, security, and A11y posture as configuration.
Data boundary first
- Raw prompts and payloads stay inside your boundary; only derived telemetry leaves.
- You control storage, retention, and encryption for logs and Safety Reports.
- Well-suited to regulated and enterprise environments that need auditable, defensible GenAI and API boundaries.
LSAS Stack in front of your APIs and platform
These diagrams show how LSAS Stack sanitizes payloads before they reach internal services and how it fits into a broader VCP-style deployment.
Payload sanitization
POST /v1/payload/sanitize applies LSAS policy to arbitrary JSON payloads before they ever touch downstream services.
VCP deployment
Illustrates LSAS Stack running inside your cloud boundary alongside identity, logging, and observability services.
Executive summary: why LSAS exists
Common failure modes in production GenAI systems
- Data leakage through prompts, logs, and unbounded integrations.
- Prompt injection and jailbreaking that subvert intended behavior.
- Uncontrolled or unsafe tool invocation across internal systems.
- Opaque decision logic with no structured trace of why actions were taken.
- Drift as models, providers, and prompts change underneath applications.
- Fragmented or incomplete audit trails for high-impact workflows.
What LSAS does instead
LSAS turns GenAI output into a validated, evidence-bound, audit-ready pipeline — without requiring you to retrain models.
- Classifies intent and risk before capabilities are unlocked.
- Grounds claims in authoritative knowledge with explicit citations.
- Runs privacy, security, accessibility, and compliance validators.
- Escalates uncertain or high-risk cases to humans or safer modes.
- Produces structured Safety Reports for every interaction.
- Feeds results back into policy packs and regression harnesses.
The 5 layers of LSAS
LSAS defines five layers of control. Each layer addresses a specific failure mode and can be adopted incrementally; together they form a coherent execution boundary around GenAI systems.
1. Intent + Risk Classification
Every interaction is classified by use case, domain, and risk level before it can reach models, tools, or data. Conservative defaults ensure ambiguous traffic is treated as higher risk.
This enables capability gating, different policies per domain (e.g., clinical vs. marketing), and early rejection of clearly unsafe requests.
2. Knowledge Grounding
LSAS defines how high-impact claims are grounded in authoritative sources such as internal policies, knowledge bases, and contracts. Responses carry an evidence contract that maps each claim to citations.
When freshness matters, LSAS can orchestrate live retrieval and caching policies without changing application code.
3. Real-time Validation
Outputs and tool plans are passed through validators that enforce privacy, security, accessibility, and policy rules. Each validator returns PASS, WARN, or FAIL with structured findings and suggested transformations.
Examples include PHI/PII detectors, prompt-injection filters, fairness and harms checks, and accessibility checks for generated UI content.
4. Escalation + HITL
When the system is uncertain, or a validator raises a high-risk finding, LSAS degrades to safer modes: clarifying questions, partial answers, or routed review queues for humans.
The goal is deterministic safe behavior under uncertainty — not pretending the model is more confident than it is.
5. Continuous Learning
Policy packs, validators, and regression harnesses are versioned, testable artifacts. LSAS tracks how policy changes, new models, and new prompts affect safety, quality, and latency over time.
What makes LSAS different
LSAS is not just "guardrails" bolted onto prompts. It is an architecture that separates control plane concerns from data plane execution, so you can change one without destabilizing the other.
- Separation of control plane (policy definitions, approvals, oversight) from data plane (runtime enforcement and traffic).
- Policy packs as versioned, reviewable, and testable artifacts — policy-as-code that can be release-gated.
- Validator pipelines that emit structured findings, not opaque scores, so engineers and compliance can review them together.
- Tool firewall / policy enforcement point (PEP) that controls what agents and tools are allowed to do, with approvals where necessary.
- Safety Reports per interaction: traceable logs of inputs, evidence, validator outcomes, and escalations, ready for audits or incident reviews.
- Designed to be implemented incrementally, in front of existing assistants, workflows, or products — not a rip-and-replace.
Reference architectures
LSAS can sit in front of multiple applications and model providers. The same core architecture supports assistants, workflow automation, search, and clinical documentation use cases.
End-to-end pipeline
From intent classification and grounding, through validation and escalation, to continuous learning and policy updates.
Control plane vs data plane
Policy packs, approvals, and tests live in the control plane; runtime enforcement and Safety Reports happen in the data plane.
Preventing sensitive data leaks: data lifecycle & system boundary
LSAS forces clarity on what data crosses the boundary, where it is stored, and for how long. That includes prompts, retrieved context, logs, embeddings, analytics, and audit artifacts.
Default posture
- Minimum necessary data for each workflow and integration.
- Preference for hashes, metadata, and pointers over raw sensitive fields.
- Configurable retention policies for prompts, logs, and vectors.
- Clear separation between production, sandbox, and research traffic.
System boundary thinking
- Written data-flow diagrams for PHI and high-risk data.
- Documented integration points with core systems of record (EHRs, CRMs, ERPs, data lakes).
- Explicit treatment of logs, metrics, and Safety Reports as part of the record.
- Alignment with your DPA, BAA, and internal data policies.
Adoption model: how enterprises implement LSAS
LSAS is implemented as an execution boundary around existing systems. Adoption typically begins with one workflow and expands as execution standards stabilize.
Phase 1
Assessment & risk mapping
Select high-value workflows, map risk domains, and define success metrics. Align stakeholders on where GenAI can safely help — and where it must not.
- Use-case inventory and risk taxonomy.
- Current-state architecture and data-flow review.
- Target-state LSAS boundary and integration points.
Phase 2
Pilot implementation
Stand up an LSAS gateway/orchestrator in front of one meaningful workflow. Wire evaluation harnesses, audit logging, and go/no-go gates.
- Policy packs and validator pipeline for the pilot.
- Eval suite and regression harness for safety and quality.
- Safety Reports and dashboards for executive visibility.
Phase 3
Production hardening
Extend LSAS across additional workflows, tenants, and regions, with monitoring, incident playbooks, and change control wired into your operating model.
- Multi-tenant, multi-environment controls.
- Incident response, rollback, and red-team playbooks.
- Version governance and formal change-control paths.
Boundary maturity stages
Implementations usually move from a single protected workflow to a broader footprint as execution standards, policy packs, and telemetry stabilize.
MVP boundary
- One priority workflow protected by LSAS.
- Initial policy packs and validators in place.
- Eval harness and Safety Reports wired into your stack.
Production footprint
- Multiple workflows and tenants routed through LSAS.
- Monitors, SLOs, and incident playbooks live.
- Policy/version control and change management formalized.
Execution Metrics
LSAS is designed to produce execution metrics that describe how systems behave under the boundary, and how changes in models or policy affect that behavior.
Evidence coverage
Evidence coverage rate
Share of high-impact outputs with properly grounded citations and traceable evidence contracts.
Safety outcomes
Unsafe output rate
Rate of outputs or tool plans that trigger WARN/FAIL validators, escalations, or safe-mode degradations — tracked over time.
Performance
Latency overhead
The additional latency budget LSAS introduces for validation and logging, tracked per workflow so you know where to optimize.
Security
Security defect rate
Incidents or near-misses tied to generated code, configuration, or insecure tool use — before and after LSAS is in place.
Accessibility
Accessibility defect rate
Measured accessibility issues in generated UI content and copy, particularly for public-facing experiences.
Model & policy drift
Drift indicators
Signals that model, provider, or policy changes are affecting quality or safety — before they show up as incidents.
LSAS Stack as proof of execution
LSAS Stack is more than a reference project. It is a concrete, running implementation that shows how the LSAS specification becomes a production-grade gateway and runtime — with real endpoints, validators, policy packs, and telemetry.
Architecture in code
- Separates the control plane (policy packs, approvals, tests) from the data plane (gateway, validator pipeline, Safety Reports).
- Implements LSAS decisions and Safety Reports as structured, reviewable artifacts instead of ad-hoc logs.
- Exposes OpenAI-compatible and JSON-sanitization endpoints that teams can adopt without redesigning their products.
Implementation proof
- Demonstrates that LSAS is not just a whitepaper — it is an implementable boundary for real GenAI and API workloads.
- Shows how to balance safety, latency, and developer experience in a gateway that production teams can operate.
- Provides a concrete reference for teams adapting the specification to their own execution and control models.
Open specification + enterprise implementation
LSAS is maintained as an open specification with reference implementation guidance for enterprise and research environments.
The repository documents licensing, contribution paths, and reference implementations suitable for internal, academic, and enterprise use.
Implement an execution boundary for GenAI.
Inference Stack works with organizations that need to implement LSAS-aligned execution boundaries inside production environments.
Discussions focus on concrete systems, constraints, and execution standards rather than abstract roadmaps or tooling alone.