Security posture, in plain detail.
L2H is engineered for regulated, enterprise, and government environments. Architecture and controls map to NIST 800-53 Rev. 5, NIST AI RMF, NIST CSF, SOC 2 Trust Service Criteria, and ISO 27001 control families. Append-only audit log, scoped + expiring API keys, signed webhooks, workload-identity-bound cloud access, secrets-manager integration, and hardened containers — not a hand-wavy “we have RBAC.”
Compliance posture
Architected to the frameworks that matter.
Controls and architecture mapped to enterprise and federal frameworks. Two tracks plus a shared core — pick the one that matches your buying motion.
AWS (Commercial)
In productionCustomer-hosted AWS deployments — your account, your VPC, your data. Workload-identity-bound cloud access and secret-store integration.
Azure (Commercial)
In productionCustomer-hosted Azure deployments for Microsoft-aligned customers. Azure AD / Entra ID SSO supported.
SOC 2 Type II
RoadmapArchitecture and controls designed against SOC 2 Trust Service Criteria. A Type II audit is on the roadmap; we are not currently SOC 2 attested.
HIPAA
Architecture supportL2H provides administrative, technical, and physical safeguards designed to support a covered entity's or business associate's HIPAA obligations. L2H itself does not act as a HIPAA-covered entity.
PCI DSS
Architecture supportL2H is not in scope as a card-data processor and does not hold a PCI DSS attestation. Customers handling cardholder data are responsible for their own assessment.
ISO 27001 / 27701 / 42001
RoadmapArchitecture and ISMS controls mapped to ISO 27001, 27701, and 42001 control families. L2H is not currently ISO certified.
GDPR
Architecture supportData Processing Addendum, Records of Processing Activities, and Standard Contractual Clauses available on request to support customer GDPR obligations. Customers act as the data controller for content processed in their environment.
FedRAMP High (control baseline)
Architecture supportArchitecture and controls designed against the FedRAMP High control baseline (NIST 800-53 Rev. 5 High). L2H does not currently hold a FedRAMP authorization. Use of the FedRAMP name does not imply FedRAMP authorization.
NIST 800-53 (High)
Architecture supportMapped to NIST 800-53 Rev. 5 High baseline controls.
DoD CC SRG IL4
Architecture supportDesigned to support customer deployment in IL4-eligible Azure GovCloud (DoD/DISA) environments. Authorization status is held by the deploying customer / sponsoring agency.
DoD CC SRG IL5
Architecture supportDesigned to support customer deployment in IL5-eligible environments using Azure GovCloud (DoD/DISA) and private routing. Authorization status is held by the deploying customer / sponsoring agency.
JWICS / TS/SCI patterns
Architecture supportDesigned to support deployment in air-gapped TS/SCI environments using on-prem Kubernetes and self-hosted LLMs. Accreditation is held by the sponsoring agency.
DoD CC SRG IL6+
Architecture supportAir-gapped on-prem deployment pattern with self-hosted LLMs and self-hosted IDP, designed to map to IL6+ control expectations.
Air-Gapped Deployment
In productionOn-prem Kubernetes, self-hosted LLMs, zero external dependencies at runtime.
NIST AI RMF
Architecture supportRisk-management practices mapped against the NIST AI Risk Management Framework.
NIST CSF
Architecture supportCybersecurity Framework controls implemented across identify / protect / detect / respond / recover functions.
OWASP ASVS
Architecture supportApplication Security Verification Standard hardening practices applied to the platform.
Status reflects how the L2H architecture is designed against the named control frameworks. L2H does not currently hold SOC 2, ISO, or FedRAMP attestations and is not on the FedRAMP Marketplace. Authorization status of any deployment in DoD or IC environments is held by the deploying customer or sponsoring agency. Trademarks referenced (FedRAMP, NIST, ISO, AWS, Azure, ServiceNow, others) are property of their respective owners; reference does not imply endorsement, sponsorship, or affiliation.
Security architecture
Ten layers, all shipping today.
Append-only audit log
Comprehensive event catalog covering templates, runs, schedules, integrations, LLM connections, plugins, webhooks, teams, API keys, and auth providers. UI with category pills, full-text search, pagination, CSV export. Configurable retention.
API keys with scope + expiry
High-entropy keys hashed at rest. Per-key scopes, expirations, and last-used metadata. Immutable after creation; rotation via deactivate-then-create.
Signed outbound webhooks
Industry-standard HMAC signing with replay-resistant timestamps. SSRF guard blocks loopback, private ranges, link-local, IPv6 ULA, and cloud-metadata addresses. Bounded retry policy. Secret returned only once at creation.
Rate limiting + idempotency
Per-key and per-user token-bucket limits across run dispatch and streaming. Idempotency keys supported on run POSTs.
Site-admin RBAC
Site-admin status synced from your identity provider on every login. Site admins manage plugins, auth providers, global workflows, and embedded-assistant config.
Embedded-assistant contract
Tightly scoped, in-process only. The embedded assistant cannot exceed the triggering user's permissions and is never accepted from outside the cluster.
Defense in depth
Hardened, non-root containers, capability stripping, network-policy templates, and read-only filesystems where compatible.
Secrets management
Secrets pulled from your cloud secret store at process start. Never embedded in container images. LLM and integration credentials are referenced indirectly so catalogs never store raw keys.
Web hardening
Strict CSP, hardened response headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy), optional HSTS, and server-side auth tokens.
Identity contracts
Standards-based authentication for both management and run-time surfaces, with separate guards for each tier. Embedded-assistant access is in-process only.
Production safety guards
Hard refusals, by design.
- The API refuses to start with auth-bypass flags enabled in production.
- Deployment notes warn on production misconfiguration.
- Audit logging is fail-soft — failures cannot roll back real mutations.
- Outbound HTTP paths sanitize header values to prevent header injection.
Identity providers supported
SSO, M2M, mTLS.
- OIDC (Auth0, Azure AD, Okta, Keycloak, Google)
- SAML 2.0
- LDAP / Active Directory
- Local accounts
- PKI / client certificate (mTLS)
- Hashed, scoped API keys
One identity across Orchestrator + Chat. Same Auth0/IDP tenant → SSO “just works.”
Downloadable artifacts
For your security review.
Security Whitepaper
Architectural security overview, threat model, control families addressed.
NIST AI RMF Mapping
How L2H controls map to the NIST AI Risk Management Framework.
NIST 800-53 Control Mapping
Control-by-control mapping to the NIST 800-53 Rev. 5 High baseline.
Data Processing Addendum
Standard L2H DPA template, available on request.
Subprocessors List
Current subprocessors with subscribe-to-updates.
Vulnerability Disclosure Policy
How to responsibly report security issues.
Have a security question?
Send us your security questionnaire, ATO support request, or vulnerability disclosure. We respond within one business day.