Understand encryption, workspace isolation, data retention, backups, and least-privilege access in the hosted service.
Embrasure is a hosted service. Connectors use dedicated identities and bounded scope to read catalog metadata, lineage evidence, and data required by enabled checks.
Access follows the operation
Catalog and investigation access is read-only. Explicitly enabled operations need additional permissions: configured Snowflake deletion requires DELETE privileges and an administrator-confirmed preview. Policy context alone does not authorize warehouse changes.
Embrasure stores workspace configuration, catalog metadata, lineage evidence, saved context, conversations, and query results needed to provide the service. Selected sources can be synced into the Embrasure Warehouse, where table data is stored in Apache Iceberg in Embrasure-managed object storage.
Snowflake and BigQuery can also be queried in place with the identity configured for the connection. Querying in place does not sync the entire source into Embrasure, but metadata, query results, and context used by enabled workflows may still be stored. On Enterprise, Iceberg tables can stay in storage buckets you own; agree on storage access and recovery responsibilities during setup.
Use the connector's secure credential flow. Secrets must not appear in tickets, logs, screenshots, or browser environment variables. Prefer workload identity, OAuth, managed service accounts, and key pairs over copied passwords.
The hosted service uses logical workspace isolation on shared infrastructure. Workspace membership, roles, and token scope govern API access; database row-level security restricts direct access to workspace records. Backend operations also check workspace authority because service processes can use privileged database access.
Managed warehouse data uses workspace-specific storage prefixes and catalog namespaces. Query authorization checks the requesting workspace and permitted tables before execution. Storage paths alone do not grant access, and being a member of one workspace does not grant membership in another.
Queries normally use the role or service account configured for the source, so that identity's source permissions set the upper bound on what Embrasure can access. A user's source-system permissions are not automatically inherited. Supported Snowflake and Databricks connections can use warehouse identity federation after the member signs in to the source and an administrator configures trust.
Configure workspace roles, supported data policies, and column masking for the people and agents using each connection. Keep the source identity's permissions limited even when workspace controls are enabled.
Connector credentials stay backend-only. Grant access through the setup flow and keep secrets out of Terraform plans and other shared artifacts. Revoke or rotate credentials in the source system when access should end.
Use SSH tunneling or an approved private path for supported SQL sources. Define private networking requirements before production cutover.
The API accepts a bearer session JWT or workspace-enabled personal access token. Tokens carry scopes, and workspace membership still controls access. Write operations require write scope plus an editor or administrator role.
SSO and SCIM can govern user access. They do not widen connector permissions or change the read-only data boundary.
Retention depends on the data type and the applicable customer agreement. The privacy policy describes the terms and exceptions.
| Data | Retention and deletion behavior |
|---|---|
| Workspace records and synced data | Retained while the subscription or evaluation is active, then deleted or de-identified within 30 days after termination unless a contract, legal obligation, security need, or backup lifecycle requires a different period. |
| Temporary warehouse query-result files | Files in primary storage are configured to expire after 7 days; recoverable copies have separate retention. This file lifecycle does not delete saved conversations, context, or query-history records. |
| Closed workflow history | Configured for 7 days after the workflow closes. History may include progress notes. |
| Operational logs | Generally retained for up to 365 days for reliability and security investigation. Audit and security records may have separate preservation requirements. |
| Recovery copies | Retention differs by store and replica. Deleted data may remain recoverable after active copies are removed; confirm the disposition of backups as part of a deletion request. |
Removing a connector stops future synchronization but does not automatically erase data already imported into the managed warehouse. To request deletion or export, contact your workspace administrator or privacy@embrasure.ai. We verify the requester's authority and check preservation obligations before acting.
The scope of a deletion request must account for active records, managed warehouse copies, files, caches, recoverable backups, and applicable subprocessors. Legal holds and required security records can affect timing. Any restore must respect earlier deletion restrictions rather than return deleted data to active use.
Deleting Embrasure's stored copies does not delete records in your source systems. Configured Snowflake deletion is a separate, administrator-confirmed operation with its own permissions.
Embrasure uses managed database backups, separate daily snapshots of hosted file storage, and versioned managed warehouse object storage. Backup monitoring checks database and file-snapshot freshness and alerts on failed or stale backups. Database backups and file-storage snapshots protect different data; a database restore alone does not restore stored files.
Primary hosted file-storage snapshots have a 35-day expiration lifecycle and are replicated to a second AWS region. Those regional file-backup replicas currently have no automatic expiration lifecycle, so 35 days is not a limit on every recoverable copy. Deletion requests must account for both stores.
Managed warehouse objects also have regional replicas, with overwritten or deleted recovery versions generally retained for 30 days. Temporary artifacts and internal datasets can have shorter lifecycles. Current warehouse tables are not deleted merely because their files reach that age.
Recovery uses the backup or version history appropriate to the affected system, followed by validation of service health and access controls. Versioning and regional replication support recovery; they do not provide automatic failover or a per-workspace restore button. Recovery time and recovery point commitments depend on your agreement. Contact security@embrasure.ai to review backup scope, retention, and recovery requirements before connecting regulated or critical data.
For customer-owned storage, agree on which backup, versioning, replication, encryption, and deletion controls your team manages.
The public security page, Data Processing Addendum, and subprocessor list provide the current security-review and data-processing information. Additional evidence is available through a security review; request it from security@embrasure.ai.
Send vulnerability reports to the same address with steps to reproduce the issue and its potential impact. Share a minimal example and keep credentials and customer data out of the report.