Skip to content
graal — documentation

Sovereignty and architecture

“Sovereign” is a heavily used word. At graal it has a single definition, repeated identically everywhere:

  1. the platform and the data run on the infrastructure chosen by the customer;
  2. no third-party service is required to operate: no SaaS, no telemetry, no external fonts or captcha;
  3. the publisher, which also integrates and supports the platform, is a French legal entity (GRAAL.SYSTEMS SAS);
  4. pipeline code is exportable and the formats are open (Parquet, S3, SQL, MLflow API).

The rest of this page shows how each of those points is verifiable in the architecture, rather than restating them differently.

Two namespaces, and nothing above them

Section titled “Two namespaces, and nothing above them”

The installation occupies two namespaces of a cluster you administer:

Namespace What lives there
application namespace console, API, low-code engine, platform services
execution namespace the jobs and workspaces of the users

The separation is not cosmetic: a workspace runs user code. No platform secret is materialised in that namespace, and runtime images are pulled there anonymously, with no pull secret. A user who starts a notebook cannot read the platform’s credentials, because they are not in their namespace.

Above those two namespaces, the installation asks for nothing:

  • no CRD — graal adds no object type to your cluster;
  • no cluster-scoped object: no ClusterRole, no ClusterRoleBinding, no StorageClass, no ClusterIssuer;
  • no Secret, Role, RoleBinding, NetworkPolicy, ResourceQuota or LimitRange: your guard rails stay written by you, and a policy a tenant grants itself is not a policy;
  • no namespace: your platform team creates them, with their quota and network policy.

In other words, graal does not need a cluster administration account — neither to install nor to run. And that statement does not require trusting us: the chart rendering can be read before it is applied, and it contains none of the objects above.

Every pod, including the users’ pods, follows the PSA restricted profile: runAsNonRoot, all Linux capabilities dropped, seccomp profile RuntimeDefault.

No remote resources

Section titled “No remote resources”

Not during installation, not at runtime, not in the interface:

  • no font from a CDN: fonts are self-hosted in the console and site packages — this is checked automatically on the build output, not just written in a rule;
  • no third-party script: no analytics, no pixel, no external captcha;
  • no telemetry: the platform does not call its publisher. There is no “disable telemetry” box to tick, because there is nothing to disable;
  • no image pulled from a public registry in our name: images come from the registry you control.

Consequence: an instance cut off from the Internet keeps working. For an environment isolated from installation onwards, see the Deployment page.

Your data stays on your side

Section titled “Your data stays on your side”
What is produced Where it lives
Data, files, buckets Your S3 object storage
Tables Apache Iceberg, on your object storage
Table catalog Your PostgreSQL database, one schema per tenant
Metadata, projects, rights Your PostgreSQL database
Identities, sessions Your Keycloak (one realm per tenant, federable directory)
Execution logs Your cluster
Project secrets Encrypted at rest in your database

There is no control plane at the publisher, hence no copy of your metadata elsewhere.

A project’s secrets (your credentials to your own systems) are encrypted at rest (AES-256-GCM), with a key derived by HKDF-SHA256 from a salt that you generate and that only you hold — a distinct key per tenant. That salt is generated once and backed up like a database encryption key: the procedure is on the Installation page.

AI agents and the language model you choose

Section titled “AI agents and the language model you choose”

The platform and the data stay on your side. As soon as you connect an agent to a language model hosted by a third party, what the MCP tools return to that agent goes through the model you chose. The boundary is therefore “nothing leaves without you having chosen where it goes”.

What graal gives you to hold that boundary: an agent only has the rights of its account, no deletion tool is enabled by default, and the read tools are bounded by per-project RBAC. If your policy forbids any egress, back the agent with a model you host — and the platform also works without any agent at all.

Reversibility

Section titled “Reversibility”

The useful question is not “can you export?” but “what is left if you leave?”.

  • Pipeline code is code: a pipeline drawn in the low-code editor exports to Pandas or PySpark and runs elsewhere, without graal.
  • The formats are open: Parquet, Iceberg and S3 for data, SQL for querying.
  • Experiment tracking is compatible with the MLflow client: experiments can be read back with standard tooling.
  • Identities live in your Keycloak, not in a proprietary directory.

What does not travel: the screens, the scheduling and the per-project governance — that is the product.

Qualified hosting providers

Section titled “Qualified hosting providers”

SecNumCloud and HDS qualify hosting offerings and hosting providers, not software installed on your side. graal is deployable with a SecNumCloud-qualified or HDS-certified hosting provider, or in your own datacentre: the hosting offering you select carries the qualification.

The regulatory context — SREN, Data Act, DORA, NIS2 — is covered on the public Sovereignty page, with its sources and their consultation dates.

Go further

Section titled “Go further”