Compliance as architecture, not configuration

Compliance as Architecture

Security and compliance are not features you enable after deployment — they are the material the platform is made from. Basalt treats every control-plane decision as an opportunity to enforce the regulated operating model by default.

That means cryptography choices, audit events, identity, tenant isolation, and authorization are not separate add-ons. They are part of the same static infrastructure architecture described in the Basalt platform architecture.

FIPS 140-3 Cryptography

Basalt uses aws-lc-rs and rustls throughout the platform. There is no OpenSSL dependency in the cryptographic path, reducing a common source of operational and validation complexity.

The crypto layer is based on a FIPS-validated cryptographic module, with AlmaLinux 10 providing the host OS path for FIPS deployments. The goal is end-to-end FIPS without OpenSSL, from service communication through the regulated host environment.

Comprehensive Audit Trail

Basalt records every login, configuration change, and resource mutation. Events capture actor, timestamp, IP address, user agent, resource details, and the operational context needed to reconstruct who did what and when.

The audit model includes more than 50 event types and is always on. It is not a compliance add-on that has to be purchased, installed, or remembered during an incident. See platform security for the broader control model.

Database-Enforced Isolation

Basalt uses Postgres row-level security to make tenant isolation a database property. Cross-tenant data leaks are eliminated at the database engine instead of relying on application code to remember every filter.

In regulated environments, that turns isolation from a coding convention into an enforceable boundary. The same RLS policies protect business tables and support the platform’s broader fail-closed security posture.

Zero-Trust Agent Identity

Basalt agents use ECDSA P-384 keypairs and bootstrap token enrollment. Once enrolled, agents perform periodic reauthorization with nonce rotation so trust is refreshed instead of assumed indefinitely.

Service tokens use HMAC-SHA256 JWTs with a JTI deny list, giving operators a revocation path when credentials or operational state need to be invalidated.

Resource Activation Leases

Dangerous operations require short-lived resource activation leases. Those grants are deliberately time-bound and protected by row-level security, giving the control plane a second layer of authorization around sensitive transitions.

This design helps defend against split-brain and stale authority. A lease must be active, scoped, and current before the platform proceeds with the operation.

Fail-Closed Authorization

Basalt authorization uses approximately 200 permissions in resource.action form. Access is explicit: if a role does not grant the action at the correct scope, the request does not proceed.

There is no implicit access path for convenience. That fail-closed model is essential for regulated operators who need permission behavior to be explainable during audits and predictable during incident response.

Pentest Harness

Basalt’s security posture is designed to be exercised, not merely documented. The platform includes a pentest harness approach for validating authorization, tenancy boundaries, and dangerous-operation controls against the architecture that will run in production.

Regulated infrastructure FAQ

Is FIPS support dependent on OpenSSL?

No. Basalt uses aws-lc-rs and rustls for end-to-end FIPS without OpenSSL, with AlmaLinux 10 as the FIPS host OS path.

How does Basalt reduce cross-tenant data leakage risk?

Postgres row-level security enforces tenant boundaries at the database engine, so application-layer mistakes do not become cross-tenant reads.