Security at every layer.
Customer data is encrypted at rest with AES-256 and in transit over TLS 1.3 with HSTS enforced. Tenants are isolated at the database-schema and object-storage layers, with row-level security enforced at every query and tenant-scoped object-storage prefixes — controls that are tested in CI on every change. Every generation run emits a cryptographically sealed evidence record that an offline verifier can check without ever calling back to our platform.
Four questions. Four straight answers.
The four questions a security reviewer asks first — answered plainly, ahead of the technical grid that backs each one.
Inside your tenant, in the residency region you pick — European Union or United States — encrypted at rest with AES-256 and in transit over TLS 1.3. Separate database schema, separate object-storage prefix, separate API-key scope. No engineer of ours has a path that reads your data without an audited, MFA-gated approval — and no other tenant's code has any path at all.
Every run ships with a cryptographically sealed evidence record. An offline verifier (in the SDK) replays the hash chain without ever calling back to us, and tells you in one line whether the bundle you received is byte-for-byte what the platform produced. No trust in our runtime required — and no trust in our network either.
Every connector credential goes into a write-only vault on POST — literally moved before the database row is committed. After that the secret is resolvable only by the connector worker, only for a specific test / browse / import call, only against the tenant that owns it, audit-logged every time. The raw value is never returned by any API we expose, including to our own engineers.
We are a data processor under GDPR Article 28; the DPA is standard and signed before any processing. Right-to-erasure is a 72-hour SLA on a tenant-scoped deletion workflow that logs every deletion event. Data residency is region-pinned per contract — EU if you need EU, air-gapped on-premise if you need no cloud at all.
Built secure from the ground up.
The detail grid for the buyer whose security team wants the architecture-level answer. Every control listed is implemented and exercised by a gate in CI. Where a control is planned rather than in place, the Trust Center says so.
AES-256 encryption + TLS 1.3
All data at rest is AES-256 encrypted in managed object storage and managed PostgreSQL via envelope encryption. All API and inter-service communication runs over TLS 1.3 with HSTS enforced. Database connections are SSL-pinned.
Multi-tenant isolation
Every tenant operates in a logically isolated environment — separate database schemas, object-storage key prefixes, queues, and API-key scoping. Row-level security is enforced at every query. Cross-tenant access is blocked at both layers and exercised by isolation gates in CI.
Write-only secret vault
Connector credentials, OAuth tokens, and API secrets follow a strict write-only pattern. Once written, a secret can only be rotated or deleted — never read back through any API. In production, all secrets are resolved exclusively from the platform key vault. Missing secret = hard failure, no silent fallback.
Immutable audit logging
Every API call, data access, job submission, and administrative action is logged with actor identity, timestamp, IP address, tenant context, and request ID. Audit logs are append-only, SIEM-ready, and retained per compliance requirements.
Zero-trust network architecture
All API endpoints require authentication. No implicit trust between microservices — each service validates the caller. API keys carry granular scoped permissions. Rate limiting, abuse detection, WAF, and CloudFront DDoS protection on all public surfaces.
Cryptographic evidence chain
Every job produces a sealed evidence bundle. The final Cryptographic Seal binds every artefact, forming a Merkle-style tamper chain. Modifying any artefact breaks the seal. Artefacts include the sealed contract commitment, Determinism Proof, Privacy Report, Utility Metrics, and more.
Deterministic reproducibility
Generation is a pure function of three things: the sealed contract, the seed, and the engine version. Hold all three and the generated data is byte-identical — chunked and streaming generation produce exactly the same bytes as a single pass. The engine version is part of the promise: when a release changes what generation produces, the version string changes with it. The determinism report records the inputs so anyone holding the bundle can re-run and compare hashes. The evidence bundle itself is deliberately not byte-identical between runs — it records that run's own identifiers, timestamps and telemetry.
Sealed specification registry
Every sealed contract specification is cryptographically hashed and saved to the sealed-specification store. Registered seals are stored in managed object storage and indexed for deterministic replay. Submitting the same sealed contract twice returns the existing seal ID — idempotent, tamper-proof, independently auditable.
MFA, SSO, and SCIM provisioning
All accounts support multi-factor authentication. Enterprise tenants get SAML 2.0, OIDC (Okta, Azure AD, Google Workspace), and SCIM 2.0 for automated directory provisioning and deprovisioning. API keys are issued once and never retrievable — rotation creates a new key.
Continuous internal security testing
Security gates run in CI on every change: dependency and vulnerability scanning, tenant-isolation checks, secret-handling checks, and evidence-integrity verification. A third-party penetration test has not yet been performed — the Trust Center carries the canonical status. Security architecture documentation is available under NDA for enterprise evaluations.
API key lifecycle management
API keys are issued once and stored only as a one-way hash — the raw key is never retrievable after creation. Each key carries tenant-scoped permissions. Keys can be rotated (old key instantly invalidated) or deleted via API or dashboard. Automated expiry policies are available on Enterprise plans.
Data retention & right to erasure
Customers configure dataset retention periods (30, 90, 365 days, or custom). Job outputs, evidence bundles, and the sealed contract specifications are deleted on schedule with cryptographic confirmation. Right-to-erasure requests are fulfilled within 72 hours in compliance with GDPR Article 17. Deletion events appear in the immutable audit trail.
What the audit questionnaire actually needs.
Cryptographic evidence
Every generation job produces a cryptographically sealed evidence bundle: Contract K, Run Manifest, Constraint Report, Determinism Proof, Privacy Report, Utility Metrics, Artifact Manifest, Timing Telemetry, and Cryptographic Seal — plus the generated data artifacts themselves.
Full audit trail
Every action — logins, API calls, job submissions, billing events, key rotations — is logged with immutable audit entries. Tenant-isolated, timestamped, and queryable from the admin dashboard.
Privacy by design
Synthetic data generation avoids personal data by design. Every evidence bundle includes a Privacy Report with k-anonymity, l-diversity, t-closeness, and differential-privacy metrics.
GDPR and UK GDPR
Data Processing Agreements available on request. Right-to-erasure fulfilled within 72 hours. Evidence bundles include privacy-risk assessments for every job. No real PII in synthetic output.
Data residency
Two residency regions: United States and European Union. The European plane serves customers operating across Europe and adjacent markets. The United Kingdom is modelled as its own regime rather than as a synonym for the EU, so a UK commitment is never silently satisfied by an EEA location. A request that would be served from the wrong jurisdiction is refused with an explicit error rather than quietly redirected. Self-hosted deployments have no cloud dependency at all.
Disconnected deployment
RadMah can run in customer-controlled infrastructure with no connection back to RadMah: container images delivered as an offline bundle, a licence verified locally with no activation call or telemetry, local object storage, and no external cloud dependency at runtime. Whether that satisfies a particular accreditation regime is the customer's determination, not ours.
Hardened by design.
Cloud provider
Microsoft Azure. Production runs as two independent regional planes — European Union and United States — each with its own network, storage and observability, so a residency commitment is satisfied by location rather than by policy alone.
Secret management
The platform key vault in production — all credentials resolved at runtime, never stored in environment variables. Missing secret = hard failure, no fallback.
Database
Separate managed PostgreSQL instances for the Admin and Client APIs, zone-redundant, with automated backups supporting point-in-time recovery, TLS-enforced connections, and row-level security at every query.
Object storage
Zone-redundant managed object storage with server-side AES-256 encryption, versioning, and tenant-scoped prefix isolation. Every storage location is bound to an approved physical region in the same legal jurisdiction as the residency region promised to the tenant.
Network
Network-isolated services with private subnets for every datastore, no public endpoint on the data plane, and managed workload identities in place of static credentials.
Job queue
Celery workers on a managed broker, with tenant-isolated queues and a separate cache. Worker isolation prevents cross-tenant job contamination.