Trust center / assurance register
Security posture.Plainly stated.
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. Operational claims, architecture support, and roadmap items are separated below so each statement can be evaluated on its own terms.
Status semantics
Labels describe posture. They do not imply an external attestation or customer authorization.
- In production
- Currently deployed in the named environment.
- Architecture support
- Controls or deployment patterns are designed to support the named requirement; this is not a certification.
- Roadmap
- Planned external validation that L2H does not currently hold.
Compliance posture
A controlled assurance register.
Commercial & enterprise
Operational cloud posture, customer obligations, and external-assurance roadmap.
AWS (Commercial)In production
Customer-hosted AWS deployments — your account, your VPC, your data. Workload-identity-bound cloud access and secret-store integration.
Azure (Commercial)In production
Customer-hosted Azure deployments for Microsoft-aligned customers. Azure AD / Entra ID SSO supported.
SOC 2 Type IIRoadmap
Architecture and controls designed against SOC 2 Trust Service Criteria. A Type II audit is on the roadmap; we are not currently SOC 2 attested.
HIPAAArchitecture support
L2H 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 DSSArchitecture support
L2H 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 / 42001Roadmap
Architecture and ISMS controls mapped to ISO 27001, 27701, and 42001 control families. L2H is not currently ISO certified.
GDPRArchitecture support
Data 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.
Federal & defense
Production posture is distinct from capability framing and customer-held authorization.
FedRAMP High (control baseline)Architecture support
Architecture 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 support
Mapped to NIST 800-53 Rev. 5 High baseline controls.
DoD CC SRG IL4Architecture support
Designed 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 IL5In production
IL5 is in production on customer-hosted GovCloud with private routing. Authorization status is held by the deploying customer / sponsoring agency.
Air-gapped / classified networksArchitecture support
Designed to support deployment in air-gapped, classified, and high-assurance environments using on-prem Kubernetes and self-hosted LLMs. Accreditation is held by the deploying customer or sponsoring agency.
DoD CC SRG IL6+Architecture support
Air-gapped on-prem deployment pattern with self-hosted LLMs and self-hosted IDP, designed to map to IL6+ control expectations.
Air-Gapped DeploymentArchitecture support
On-prem Kubernetes, self-hosted LLMs, and zero external dependencies at runtime form an air-gapped deployment pattern. Accreditation is held by the deploying customer or sponsoring agency.
Shared control core
Security and AI risk-management practices used across both tracks.
NIST AI RMFArchitecture support
Risk-management practices mapped against the NIST AI Risk Management Framework.
NIST CSFArchitecture support
Cybersecurity Framework controls implemented across identify / protect / detect / respond / recover functions.
OWASP ASVSArchitecture support
Application 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 control layers. Shipping today.
01Append-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.
02API 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.
03Signed 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.
04Rate limiting + idempotency
Per-key and per-user token-bucket limits across run dispatch and streaming. Idempotency keys supported on run POSTs.
05Site-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.
06Embedded-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.
07Defense in depth
Hardened, non-root containers, capability stripping, network-policy templates, and read-only filesystems where compatible.
08Secrets 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.
09Web hardening
Strict CSP, hardened response headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy), optional HSTS, and server-side auth tokens.
10Identity 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.
- Production safeguards prevent insecure access-bypass configuration.
- Deployment validation flags unsafe production configuration.
- Audit controls preserve the integrity of governed operations.
- Outbound connections remain governed by explicit security policy.
Identity providers supported
SSO, M2M, mTLS.
- OIDC and SAML 2.0
- Enterprise directory integration
- Local accounts for isolated deployments
- PKI / client certificate (mTLS)
- Scoped API keys for machine access
Standards-based identity carries across the Agentic Command Center and Chat without creating a second access model.
Downloadable artifacts
Evidence for your 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.
Security review
Have a security question?
Send us your security questionnaire, ATO support request, or vulnerability disclosure. We respond within one business day.