Security and compliance

BullSequana AI applies security controls across the full platform rather than adding them separately to each AI or Data service. The product provides shared identity, authorization, tenant isolation, secret handling, encrypted service exposure, and operational evidence through Foundation services.

This page describes product behavior first, then identifies the settings that administrators control for their environment.

Identity and access

BullSequana AI centralizes authentication and identity federation through Keycloak. Platform services use the same sign-in boundary, and SSO-enabled components are enrolled automatically from declarative configuration. OpenFGA adds relationship-based authorization where a service needs permissions beyond role membership.

The administration model distinguishes several scopes:

Tenant administrators connect the approved identity provider, manage team membership, delegate roles, and revoke access. Platform operators manage the underlying identity, authorization, and secret services.

Use Administration and operations for role boundaries. Use Keycloak, OpenFGA, and External Secrets for implementation detail.

Tenancy and isolation

Multi-tenancy is a BullSequana AI product capability. Each tenant represents a customer-level isolation boundary. Teams provide a second access tier for departments and working groups inside that tenant.

Product services carry the tenant and team context into applications, Data workspaces, model access, pipelines, artifacts, and administrative views. Authorization limits which resources a user or service identity can discover and operate. Data workspaces add viewer, editor, administrator, and pipeline-runner roles instead of giving every collaborator the same permissions.

Administrators select the tenant and team structure, assign memberships, and configure delegated access. BullSequana AI supplies the isolation and policy mechanisms that enforce those choices.

Core concepts defines the hierarchy. Multi-tenancy and tiered access in Data explains how the model is enforced in Developer Workspace.

Audit and compliance evidence

Foundation observability centralizes metrics, logs, and traces from platform services. Identity, authorization, workflow, and application signals retain the context needed to explain platform activity and diagnose access decisions.

These signals support questions such as:

• which identity performed an action
• which tenant and team applied
• which application, data asset, model, or tool was involved
• which policy allowed or denied access
• where a workflow failed or changed state

Customers control access to operational evidence and define retention, export, and integration with their existing audit or security tooling. Foundation observability and audit explains the signal path; the Foundation security model explains the underlying controls.

Sovereignty and air gaps

BullSequana AI runs on customer-controlled infrastructure and supports disconnected operating models. Platform images, packages, models, and documentation can be delivered through approved private channels. Core operation does not depend on mandatory external telemetry, and usage exports remain customer-controlled.

The product separates software delivery from external internet access:

• Harbor provides a private image-delivery path.
• GitOps configuration keeps the installed state reviewable and reproducible.
• Local identity, storage, observability, and model services keep core workflows inside the controlled environment.
• Backup and recovery procedures cover stateful platform services without requiring a public control plane.

Customers provide the approved infrastructure, identity source, delivery channel, residency policy, and recovery objectives for their deployment. Use deployment environments, Harbor delivery, and backup and disaster recovery for those configuration paths.

Product controls and customer configuration

For a role-oriented walkthrough, use Govern and administer.