Enterprise security and operations
Available enterprise controls, deployment responsibilities, and current assurance boundaries.
Fabric Experiments combines organization-scoped access control, governed test evidence, audit history, and production release policy. This guide explains the controls available to enterprise evaluators and the responsibilities that remain with the deploying organization.
Available controls
| Area | Available capability |
|---|---|
| Authentication | Email/password, magic links, OAuth, SAML/OIDC SSO, SCIM surfaces, organization membership, sessions, and 2FA-capable authentication. |
| Authorization | Fixed viewer, experimenter, admin, and owner roles; scoped and expiring API keys; organization predicates on API and Quality operations. |
| Tenant isolation | Organization-bound data access, API-key tenancy, tenant-scoped Quality history, and tenant-scoped governance policy. |
| Release governance | Required Quality suites, freshness windows, server-enforced production promotion checks, and durable failure reasons. |
| Evidence lifecycle | Test-run history, runner-side redaction, API-side validation, configurable retention from 30 to 3,650 days, and legal hold. |
| Audit | Experiment lifecycle, publication, promotion, key, Quality, and governance events with external forwarding support. |
| Databricks identity | Databricks Apps OAuth at the gateway plus independent Fabric organization authorization; OAuth M2M, OIDC, bearer, and PAT test identities. |
| Databricks topology | Azure serverless data-engineering suite and an Azure classic-compute probe with explicit certification boundaries. |
| Secrets | Hashed API keys, show-once credentials, redacted test evidence, Databricks secret bindings, and live secret-rotation checks. |
| Recovery testing | Live checks for failure recovery, backup/restore, rollback, and Lakebase credential/pool refresh. |
Studio is not the security boundary. The API repeats authorization, tenancy, and Quality-policy checks for every protected operation.
Recommended enterprise setup
- Use separate organizations for unrelated security boundaries.
- Integrate the chosen IdP and exercise sign-in, sign-out, deactivation, and recovery before inviting production users.
- Assign the lowest suitable Fabric role and least-privilege Databricks grants.
- Create separate, expiring Quality publisher keys for each CI environment.
- Use dedicated development, staging, and production Databricks resources.
- Publish required suites to Quality Center and enable the production gate.
- Configure retention and export audit/evidence to the organization's approved archive or SIEM when independent retention is required.
- Exercise backup/restore, rollback, credential rotation, and access revocation on disposable resources.
- Record the exact supported cloud, region, runtime, compute mode, and network topology in the deployment acceptance criteria.
Identity and access
Databricks Apps authenticates access to the hosted application. Fabric then authenticates the application session or API key, resolves organization membership, and enforces the Fabric role. Access to the Databricks App alone does not grant access to another Fabric organization.
For automation, prefer short-lived OAuth or workload identity at the Databricks boundary and an expiring organization-scoped Fabric API key for Quality publication. Do not share human credentials with CI.
The current role model is fixed. Custom roles, group-to-role mapping, two-person approvals, and customer-operated break-glass workflows are not currently product capabilities.
Evidence, retention, and audit
Quality Center accepts Fabric BDD/live evidence and supported standard test formats. Evidence is associated with the authenticated organization and can be used by a server-enforced production promotion policy.
Retention and legal hold apply to Fabric-managed records. Organizations that require immutable or independently controlled archives should forward audit events and export evidence to an approved WORM/object-lock destination. Fabric does not represent legal hold as a complete e-discovery service.
Reliability and recovery
The Databricks live suite includes performance, failure-recovery, secret-rotation, backup/restore, and rollback probes. These checks validate the configured test target; they do not replace the customer's service-level, regional recovery, or business-continuity program.
Before production adoption, test dependency failures involving Databricks, Lakebase/Postgres, Cloudflare, identity providers, email delivery, and audit destinations. Define customer-owned RPO/RTO objectives and verify restoration from backups stored outside the primary failure domain.
Data and privacy responsibilities
Collect only identifiers and dimensions needed for the experiment or quality decision. Browser integrations should honor the organization's consent and tracking policy. Avoid placing production secrets, unrestricted personal data, prompts, model responses, or sensitive fixtures in test evidence.
The deploying organization remains responsible for data classification, lawful basis, residency, retention across external systems, data-subject workflows, subprocessors, and regulated-data approval.
Assurance boundary
Fabric provides implementation and operational evidence for the capabilities named in this documentation. It does not currently claim SOC 2, ISO 27001, HIPAA, FedRAMP, PCI, or another independent certification for the product. Customers requiring a formal attestation should treat that as an evaluation requirement rather than infer it from automated tests.
Azure Databricks is the current certified workload target. AWS and Google Cloud Databricks, private networking variants, customer-managed encryption keys, and regulated deployment profiles require customer-specific validation and are not currently certified by Fabric.
See Enterprise governance for configuration steps, Compatibility for precise supported and unsupported behavior, and Certification evidence for the named live target boundaries.