> Source: https://builder.ema.ai/v2/administration/security-compliance > Title: Security & Compliance # Security & Compliance This page describes the security posture of the Ema platform that matters when you administer a tenant: how data is encrypted, how your tenant is isolated from every other tenant, how personally identifiable information (PII) is detected and masked, how every action is recorded, and how data is retained and deleted. It is a reference for the controls Ema operates on your behalf — most of them are platform guarantees you cannot turn off, and a few are tenant settings you configure on the admin surfaces described below. > [INFO] > **Cloud-hosted.** Ema runs as a managed, multi-tenant cloud service. There is no self-hosted deployment to harden, no infrastructure to patch, and no key material for you to operate. The controls on this page are enforced by the platform across all tenants. ## Encryption at rest All tenant data is stored on encrypted infrastructure: managed PostgreSQL, object storage, and Redis all sit behind disk-level encryption operated by the platform. On top of that baseline, Ema applies two additional layers of application-level encryption to the most sensitive material. ### Envelope encryption for secrets Long-lived secrets — the RSA private keys that sign your tenant's JSON Web Tokens (JWTs), and your single sign-on (SSO) configuration — are encrypted with envelope encryption before they are written to the database: 1. Ema generates a random 256-bit data encryption key (DEK). 2. The secret is encrypted with AES-256-GCM using the DEK. 3. The DEK itself is encrypted by a key management service (KMS)-managed key encryption key (KEK). 4. Only the ciphertext and the encrypted DEK are stored. The plaintext DEK is never persisted. Recovering a secret requires a live KMS decrypt call, so a leak of database credentials alone is not enough to read it. SSO configuration is stored as AES-256-GCM-encrypted JSONB for the same reason. ### Field-level encryption for PII columns (where enabled) For deployments with stricter compliance requirements, Ema can transparently encrypt named columns in the identity store (for example a user's email, name, and attributes) at rest. The set of encrypted columns is a deployment configuration, not something a tenant admin toggles. When it is on, the column ciphertext is written and read inside the database using AES-256 primitives, and equality lookups that the platform depends on (such as login by email) keep working. This layer is an additional barrier on top of disk-level encryption; it does not change how data appears to you in the product. ## Tenant isolation Every record in Ema carries a `tenant_id`, and a tenant is the hard boundary for all data access. Several mechanisms enforce this together: - **Authentication is tenant-scoped.** Every request is authenticated by a JWT or an API key that resolves to a specific tenant. Identity is keyed globally by email, but a user can only act in a tenant where they hold an active membership; the role on that membership determines what they can do. See [Governance and permissions](/builder/v2/administration/governance-and-permissions). - **Queries are tenant-correlated at the database layer.** Every query that joins across tables includes `tenant_id` in the join condition itself, not only in a filter. This prevents a cross-tenant leak even if a stray identifier ever pointed at another tenant's row. - **Cross-tenant sharing is explicit and one-directional.** The only ways data crosses a tenant boundary are the deliberate sharing flows: a parent tenant can grant a workflow template to a descendant tenant (see [AI Employee export and import](/builder/v2/administration/ai-employee-export-import)), and cross-tenant resource shares flow downward only — never to a sibling or a parent. A clone or any other copy operation refuses outright if the source and destination tenants differ. - **Existence is never disclosed across tenants.** When you reference a resource that lives in another tenant, the platform returns "not found" rather than "forbidden," so you cannot probe for the existence of resources or users outside your own tenant and its descendants. ### Tenant hierarchy Tenants can be organized into a hierarchy: a parent tenant can have child tenants. Administrative reach and sharing follow the tree strictly downward — a parent admin can create children and grant templates into its subtree, but a child tenant's data, users, and audit events are never visible upward or sideways. See [Tenant management and SSO](/builder/v2/administration/tenant-and-sso). ## PII detection and masking Ema can detect PII in the content it processes and apply a masking policy before that content is displayed to a person or sent to an external model or integration. Detection classifies values into a fixed taxonomy of entity types (for example `EMAIL_ADDRESS`, `US_SOCIAL_SECURITY_NUMBER`, `CREDIT_CARD_NUMBER`) following the Google Cloud DLP infoType naming convention. Two controls govern detected PII, both configured on the PII Management surface: - **Display levels** decide how a detected value appears to people inside Ema — `original`, `partial` (a revealed tail, such as the last four digits), `pseudonym` (a stable, non-reversible token like `SSN_61038472`), or `full_mask`. Each entity type has a platform-fixed ceiling reflecting regulatory baselines (HIPAA Safe Harbor, PCI DSS, NIST SP 800-122, GDPR, CCPA). Secrets and credentials are capped at Fully Masked; financial and government identifiers are capped at Partial. You can set a level at or below the ceiling, never above it. - **Sharing policy** decides what detected PII is allowed to leave Ema in cleartext for external models and integrations. A small set of business-context entities (name, email, organization, phone, address, employment, education) always passes; all sensitive types — credentials, financial, healthcare, government, device, and protected attributes — are hard-locked to never egress in cleartext and cross any external model boundary only as a pseudonym token. The egress lock at large language model (LLM) boundaries is a platform guarantee enforced in code, not a tenant preference: a tenant toggle can never push a locked entity type across an LLM vendor boundary in cleartext. For the full configuration reference, see [PII and data governance](/builder/v2/administration/pii-and-governance). > [INFO] > **Enabled per tenant.** PII detection and masking is gated by the `pii_masking` feature flag. When it is off, content passes through unchanged and the PII Management surface is hidden. Contact your Ema representative to enable it. ## Audit trail Every meaningful action in your tenant is recorded in an immutable, append-only audit log — sign-ins, user and role changes, workflow and AI Employee edits, runs, knowledge base changes, integration and API-key events, template and grant changes, and retention-policy changes. Events cannot be edited or deleted through any API. Each event captures who acted (actor ID, name, email, and role at the time), what they did (the action and the resource, with the resource name and version captured at event time), when, and the actor's IP address. Actor and resource names are denormalized into the event when it is written, so the record stays accurate even if a user or resource is later renamed or removed. Visibility is scoped to your role in the query itself: `system_admin` and `user_admin` see every event in the tenant, `builder_admin` and `builder` see events on build resources, and a `user` sees only their own actions. When PII masking is enabled, every masking decision is additionally recorded as a dedicated `pii_access` or `pii_data_export` event, queryable through a `system_admin`\-only PII access log that answers questions like "what cleartext PII left the tenant, for which integration, and when." See the [Audit log](/builder/v2/administration/audit-log) for the full field reference, filters, contextual activity feeds, and CSV export. ## Data retention and legal holds Ema manages the lifecycle of your data with configurable retention policies, and suspends deletion entirely while a legal hold is in place. ### Retention policies A retention policy sets how long a given type of data is kept before it expires and is deleted. Policies resolve by precedence — an AI Employee-specific policy overrides a tenant-wide default, which overrides the platform default. The platform defaults are: Data type Default retention Documents Never expire Chat sessions 365 days Workflow runs 365 days Audit events 365 days Token usage 365 days Evaluation runs 180 days Agent tests 180 days A custom retention period must be at least 7 days, or `0` to mean "never expire." Audit events are kept for the configured tenant retention period (365 days by default) and cleaned up by a background process — there is no API that edits or deletes an individual audit event. When data expires, the platform orchestrates a cascade deletion across the services that own the data, in dependency order, and records every deletion operation in a deletion log that is itself retained for seven years for compliance. Deletion is forward-only: a partial failure is logged and retried rather than rolled back, so deletions never silently undo themselves. ### Legal holds A legal hold is a first-class control that suspends all deletion for a tenant — retention expiry, tenant churn, and data-subject deletion requests all stop while the hold is active. A tenant can have one active hold at a time; placing it records who placed it and why, and releasing it records who released it and why. The platform surfaces holds older than twelve months for annual review. While a hold is active, any deletion the platform attempts for that tenant is refused. ### Data-subject deletion requests For privacy-regulation deletion requests (such as GDPR Article 17), Ema queues a data-subject request keyed to a subject's email with a tracked deadline. If the tenant is under a legal hold, the request is parked until the hold is released rather than deleting data that must be preserved. ## What's next - [PII and data governance](/builder/v2/administration/pii-and-governance) — configure detection display levels and integration egress. - [Audit log](/builder/v2/administration/audit-log) — review and export the immutable record of every action. - [Governance and permissions](/builder/v2/administration/governance-and-permissions) — the role and capability model that gates every surface. - [AI Employee export and import](/builder/v2/administration/ai-employee-export-import) — how AI Employees move between tenants, and the isolation rules that govern it. - [Tenant management and SSO](/builder/v2/administration/tenant-and-sso) — sign-in, providers, and tenant settings.