Appearance
Security & compliance
Every Nomain deployment is built so that your data stays in your perimeter. This page describes the security posture that is common to the BYOC and on-premise models. For the cloud-specific resource lists and controls, see BYOC on Azure and BYOC on AWS.
The data boundary
A BYOC deployment rests on three properties:
- Your data never leaves your account. Databases, object storage, and foundation-model inference all stay inside the region and account you choose. On Azure, model inference runs on Azure OpenAI in your subscription; on AWS, on Amazon Bedrock reached over a private interface VPC endpoint, so inference never touches the public internet.
- No Nomain operator has runtime access. The initial deploy uses a principal you own. Nomain support engineers receive logs or traces only when you ask, through a controlled diagnostics export.
- No static credentials. Every cross-service call uses short-lived, automatically rotated identity tokens: Azure Workload Identity and Entra ID on Azure; per-service IAM roles and 15-minute IAM Database Authentication tokens on AWS.
What leaves the perimeter
The only outbound calls to Nomain infrastructure are a small set of signals over the Customers API, authenticated with a machine-to-machine credential issued at onboarding:
- License validation, a liveness heartbeat, and a seat count on every deployment, all carrying license, tenant, health, or aggregate-metric metadata only. The heartbeat also carries an aggregate, content-free chat-health summary (counts, percentiles, and each tier's effective model/region; no chat content or PII).
- Feedback when a user submits it (opt-out per tenant). On Azure this also includes aggregated telemetry (job counts, latencies, error-rate buckets); on AWS, detailed per-event telemetry stays in CloudWatch inside your account and only the aggregate chat-health summary above crosses to the control plane.
No customer code, AST, embeddings, or chat content is ever sent to Nomain.
What Nomain cannot access
- No standing operator credentials into your subscription or account.
- No runtime read or write access to your data plane (databases, object storage, secret stores).
- No telemetry of your source code, AST, embeddings, or chat content.
Defense in depth
The same layered controls apply across clouds, using each provider's native primitives:
| Layer | Azure | AWS |
|---|---|---|
| Network isolation | Every PaaS resource reached only over Private Endpoints; App Services run with public network access disabled; egress through a single NAT Gateway. | ECS tasks in private subnets with no public IPs; RDS, Bedrock, ECR, Secrets Manager, and CloudWatch reached over VPC endpoints; only the ALB is public, fronted by AWS WAF. |
| Encryption in transit | TLS 1.2+ on every ingress and outbound call; PostgreSQL with sslmode=require. | TLS 1.2+ at the ALB; RDS with sslmode=require; AWS-service traffic on the AWS backbone. |
| Encryption at rest | Azure-managed encryption on every service; geo-redundant backups. | Customer-managed KMS keys across RDS, S3, EBS, Secrets Manager, and SQS. |
| Identity | One user-assigned managed identity per service, scoped to exactly what it may touch. | One least-privilege IAM task role per service, scoped to specific model, bucket, and secret ARNs. |
| Secret management | Key Vault is the single source of truth; services read secrets by reference. | AWS Secrets Manager is the single source of truth; task definitions reference secret ARNs. |
| End-user authentication | WorkOS AuthKit (OIDC), with WorkOS Connect bridging your IdP; JWTs validated locally. | Same. |
| Audit logging | Tenant-lifecycle, admin, authentication, and data-deletion events retained 12 months in audit-category Log Analytics tables (separate from the 90-day default). | The same events retained 12 months in a dedicated CloudWatch log group (separate from the 30-day default). |
| Vulnerability management | Container images scanned for CVEs at build time; Microsoft Defender for Cloud supported. | Images scanned at build time; Amazon ECR enhanced scanning with Inspector supported. |
Tenant data inside a single deployment is scoped through per-service PostgreSQL roles and row-level filters on tenant ID; cross-tenant queries are forbidden at the data layer. For full physical isolation, deploy one stamp per tenant.
Compliance alignment
| Area | Position |
|---|---|
| Data residency | Every byte (databases, storage, model inference) stays in the single region you pick at deploy time. |
| DORA / ICT third-party risk | Nomain is not a critical ICT service provider for the data plane; it runs in your account. The only Nomain runtime dependency to model is the metadata-only Customers API calls. |
| GDPR / privacy | Authentication is delegated to your IdP. Nomain stores no end-user PII; only tenant-level metadata flows back over the machine-to-machine channel. |
| ISO 27001 / SOC 2 | A 12-month audit trail lives in your own account, with customer SIEM ingestion supported through diagnostic-settings export (Azure) or a Kinesis Firehose subscription (AWS). |
AWS Foundational Technical Review
The AWS Marketplace listing is backed by a Foundational Technical Review (FTR) self-assessment covering the full set of AWS technical controls (architecture, security and data, cost and sizing, operations and resilience). Ask your Nomain representative for the current evidence package if your procurement or security team needs it.
Related
- BYOC on Azure and BYOC on AWS: the per-cloud resource lists and controls.
- Single sign-on: connecting your identity provider.
- Deployment options: the four ways to run Nomain.