Compliance and Attestation
The platform's compliance posture, the controls a reviewer looks for and where each is enforced, and the per-app CAIQ attestation filled from cited evidence on every deploy.
The platform holds a SOC 2 Type II report, runs a HIPAA program with Business Associate Agreements in place with its infrastructure and model providers, monitors its controls continuously, and gives every app built on it an attestation of its own: a CAIQ filled from the platform's cited facts and the app's own analysis. This chapter covers the posture, the controls a reviewer will look for, and the attestation product.
#Posture
| Program | State |
|---|---|
| SOC 2 Type II | Report available under NDA |
| HIPAA | Program in place: BAAs signed with AWS, Cloudflare, Google Cloud, Sentry and Anthropic; HIPAA-scoped controls monitored alongside SOC 2 |
| Continuous monitoring | Vanta, connected to AWS, GitHub, identity and endpoint systems, with every infrastructure resource tagged for ownership and data classification |
| Trust page | Subprocessor list rendered from the counterparty registry |
The registry records, per counterparty, the agreements in force and whether a surface is BAA-covered. That single fact feeds the model picker, the subprocessor list, and the attestation. The HIPAA-configured Anthropic organization is an example: models served through it carry BAA coverage as a declared fact, and features the agreement excludes are stripped from requests rather than attempted.
#Controls a Reviewer Will Look For
Each of these is described in its own chapter; this is the index.
| Control | Where it lives | Chapter |
|---|---|---|
| Encryption at rest | Customer-managed KMS keys on the database, the secrets envelope, the registry and the backup vaults; server-side encryption on object storage | Secrets, Platform Database |
| Encryption in transit | TLS at the edge, TLS 1.3 with a FIPS policy at the load balancer, TLS enforced at the database cluster, HTTPS-only bucket policies | The Trust Boundary |
| Tenant isolation | A microVM per app, a database file per app, an origin per app, a hook token per execution | Execution Islands, App Databases |
| Network isolation | Two VPCs, two clusters, a peering that admits three ports one way, sandbox egress to the internet only | The Trust Boundary |
| Identity and access | Cognito with SRP, MFA and federation; SSO; least-privilege workload identity | Identity and Auth |
| Secrets management | KMS-encrypted app secrets, Parameter Store for operator credentials, Secrets Manager for workspace keys, one code path to obtain any of them | Secrets |
| Audit logging | Every control-plane action and every human method invocation, WORM-stored for a year, OCSF export | Audit Log |
| Vendor management | Every third party declared with data classes, retention, training policy, exposure and agreements | Counterparties and Egress |
| Malware and PII detection | Every stored file scanned by ClamAV and Presidio | Content Inspection |
| Backup and recovery | Continuous backups, cross-region copies, weekly automated restore tests | Platform Database |
| Data residency | Four regions, data at rest pinned to the workspace's choice | Data Residency |
| Threat detection | GuardDuty with EKS runtime monitoring, CloudTrail with log-file validation, VPC flow logs, database audit logging, storage access logs | Observability |
| Change management | Atomic promotion, migration on a clone, isolated builds, rollback by revert or re-promote | Build and Deploy |
| Web application security | Security headers, cookie flags, origin separation, embedding allowlists | Served-App Security |
#Attestation for Apps
A customer building on Remy faces the same questions about their app that the platform faces about itself, and the platform already answers most of them.
The assessment report. After every deploy, a static analysis of the release produces a structured report: the app's auth methods, its roles, its data handling, which models it calls and what it sends them, its external connections, and a data-flow diagram. A commit classifier decides whether a release changed enough to warrant regeneration, so an unchanged release reuses its prior report.
The CAIQ attestation. The Cloud Security Alliance's Consensus Assessments Initiative Questionnaire, the instrument enterprise buyers already use, is filled for the app from three layers:
- Platform facts, authored once in code and cited to a control, a code path, or an agreement. These are the same for every app: how sessions are handled, where data is encrypted, what the serving layer enforces.
- The app's own analysis, projected from the assessment report per release: which auth methods it enables, what data it stores, which models it uses.
- The builder's own controls, their governance, their people, their policies, left for the builder to complete, with guidance.
The rule that makes this trustworthy is that nothing is asserted without a citation, and nothing is guessed. A model maps and phrases known facts into the instrument's shape; it never decides whether a control is met. The result is served through the app's management API as the full control set with provenance on every answer, and the workspace's dashboard renders it as the questionnaire a reviewer expects, with inapplicable controls justified rather than omitted.