Where your data lives
Every customer maps to exactly one deployment model. The two axes that matter: where the data physically lives, and who operates it.
| Model | Data lives | Operated by | Isolation | Status |
|---|---|---|---|---|
| M1 · Shared SaaS | Our cloud | Gentrail | Logical (per-org) | Coming soon |
| M2 · Dedicated SaaS | Our cloud, your region | Gentrail | Physical stack | Coming soon |
| M3 · Bring Your Own Cloud | Your cloud account | You | Your account | Available now |
| M4 · On-Premises | Your data center | You | Your hardware (air-gapped) | Coming soon |
No phone-home - offline license, pulled artifacts
For BYOC (and On-Prem), Gentrail follows the established self-hosted enterprise pattern: we publish signed artifacts; your deployment verifies them offline.
- There is no runtime callback to our cloud - license validity does not depend on us being reachable.
- Your deployment verifies a signed Ed25519 license JWT against an embedded public key, locally.
- All traces, policies, violations, and evidence stay in your environment - the payload never leaves you.
- Your KMS, secrets, and IAM stay yours - we never receive keys or tokens.
- If our cloud is offline, your deployment keeps running. We never disable the data plane for a paying customer mid-incident.
Five layers of defense, every model
The same five pillars apply to every deployment. The strength of each control varies by model; the presence of every pillar does not.
- P1 · Minimize Coming soon - SDK-side redaction, field-level allow-list, tokenization of PAN / SSN / email. We never persist what we don't need.
- P2 · Isolate - Every query carries an org boundary, enforced in code and in the storage schema (org-partitioned keys). The perimeter scales from logical (M1) to your own cloud account (M3).
- P3 · Encrypt - TLS 1.3 in transit; AES-256 at rest. In BYOC, your native KMS holds the root key - we never see key material, and you control rotation. Per-tenant envelope encryption is coming soon.
- P4 · Restrict - Role-based access with org-scoped grants enforced on every API call today. SSO (OIDC / SAML), SCIM, mandatory MFA, custom roles, and step-up auth on sensitive operations are coming soon.
- P5 · Observe - Structured admin-action audit log, customer-readable in the dashboard today. Tamper-evident hash-chaining and SIEM forwarding (webhook / Kafka / S3) are coming soon. Documented breach-response runbook.
What we collect - and what we never see
- In a BYOC deployment, Gentrail (the company) does not receive, host, or access your product data - agent traces, policies, violations, or evidence - in normal operation.
- No AI training on your data. Customer content is never used to train Gentrail models. Optional AI-assisted features (policy rule extraction, tool classification) call third-party model APIs using API credentials you supply, under your own provider accounts; Gentrail holds no provider credentials and never receives the content of those calls.
- On gentrail.ai, the contact forms and the free-license generator process your name, work email, company and, where you provide them, role, company size, cloud provider, industry and a message, plus standard server logs. The site uses privacy-respecting page analytics, a first-party event log keyed to a random visitor id, and a company-identification service that resolves a visitor's IP address to an organisation, never to a person. No advertising trackers. Details and opt-out: Privacy Policy.
PII protection for the Claude plugin
For a connected Claude Team or Enterprise organization, an admin turns on PII protection from the Claude integration page and sets the Gentrail plugin to Required. Off by default. In Mask mode, the plugin's hook returns placeholder text (for example [EMAIL]) in place of raw values read from files or command output. In Tokenize mode, the hook returns reversible token references instead. Edits involving PII or token references are refused; the member makes those changes outside Claude. The hook never writes files before Claude checks its permissions. Per-class policy - block, or allow and record - applies to what a member types, before it reaches the model.
Gentrail holds the organization's KMS-wrapped tokenization keys, not the plugin. Each tool call that needs to tokenize or restore a value asks Gentrail to release the unwrapped key over HTTPS; the plugin's hook keeps it in memory for that one call only and never writes it to disk. Disabling the KMS key, rotating the plugin's API key, or turning the mode off all stop tokenization immediately.
Controls per deployment model
Read across a row to see how a control scales with deployment model; read down a column for the full control envelope of a single model. This is the reference for your security team during procurement.
| Control domain | M1 Shared SaaS | M2 Dedicated SaaS | M3 BYOC · now | M4 On-Prem |
|---|---|---|---|---|
| Data residency | Single region | Customer-chosen region | Customer's cloud account | Customer's data center |
| Tenant isolation | Logical (per-org PK) + IAM | Physical: own VPC, DB, queue, KMS | Customer account = perimeter | Customer hardware = perimeter |
| Encryption at rest | AES-256, provider-managed KMS | AES-256, CMK | AES-256, BYOK (customer KMS / Vault) | AES-256, HYOK (customer HSM) |
| Encryption in transit | TLS 1.3 ext; mTLS int | TLS 1.3 + mTLS; customer cert | TLS 1.3; service-mesh mTLS - coming soon | TLS 1.3 + customer PKI; no ext egress |
| Key control | We hold | Customer CMK; we use via grant | Customer holds; we never see key | Customer HSM; key never exits customer |
| PII redaction | SDK + ingest (default rules) | SDK + ingest + custom policy | SDK + ingest; customer policy - coming soon | SDK + ingest; customer policy |
| LLM data path | Managed API · ZDR | Bedrock / Vertex / Azure OpenAI in-region | Customer-chosen provider; egress allow-list - coming soon | Self-hosted only; no egress |
| Identity / SSO | Password + session; OIDC opt-in | OIDC + SAML + SCIM | Password + session today; +OIDC/SAML/SCIM - coming soon | SAML + customer IdP; air-gap auth |
| Authorization (RBAC) | 4 built-in roles; step-up on sensitive ops | 4 built-in + custom roles | Org-scoped grants today; +custom/resource-scoped - coming soon | Custom roles + separation of duties |
| Staff access to data | Break-glass, audit-logged, time-bound | Break-glass, customer-notified | None at runtime; customer-initiated session | None ever; remote support is screen-share |
| Audit log | Append-only; 12-mo retention | Append-only + customer SIEM forwarding | Customer owns log store | Customer owns log store |
| Breach notice SLA | 72h (GDPR) | 24h contractual | Customer is operator; we notify on artifact CVE | Customer is operator; we notify on artifact CVE |
Compliance posture
Two separate things: the frameworks Gentrail helps you evidence, and Gentrail's own posture.
- Frameworks built in. Pre-built policy packs for SOC 2 Type II, NIST AI RMF 1.0 (and the GenAI profile), ISO/IEC 42001:2023, and ISO/IEC 27001:2022. Per-control evidence is collected over an audit period and exported for auditors as a signed bundle - continuous monitoring, scan snapshots, and attestations, not a one-time screenshot.
- Gentrail's own posture. Our SOC 2 Type II is in progress; we describe it that way until a CPA attestation exists. We self-govern against NIST AI RMF and ISO 42001 by running our own operating policy through Gentrail itself - “Gentrail on Gentrail” - so violations of our own public commitments are detected and triaged like any customer policy violation.
Take this to your security team
Download the full Data Security Overview as a PDF, or talk to us about a BYOC deployment in your own cloud account.