Security
No rights on your cluster. Per-project permissions. Agents under control.
graal Data Platform and graal Agentic Platform are designed for your CISO’s review: a privilege-free installation, federated identities, a record of every action, and no data sent to the vendor.
Isolation
What graal asks of your cluster
An access review does not have to take our documentation on trust: the rendered chart can be reviewed, object by object.
No rights on the cluster
No custom resources, no cluster-wide role: both platforms work with only the rights your platform team grants them.
See the technical specificationRestricted pods, no exceptions
Every pod, including your workloads and the agents’ sandboxes, runs under PSA restricted: non-privileged user, Linux capabilities dropped, default seccomp profile.
A closed network per workload
Each run gets its own network policy: it cannot reach another project or another organization, and its egress is limited to authorized destinations.
Images under control
Workloads only pull images from authorized registries, pinned by digest: no arbitrary image starts.
Identity
Who can do what, on what
Roles and their holders are visible in the console, and revoked in the same place.
The roles of an organization: what each one can do, and on what.
Real graal console interface, not retouched; fictional demonstration data (tenant energie-demo — people, projects and tokens are invented).
Your SSO, your directory
OIDC or SAML federation, LDAP or Active Directory, enforceable multi-factor authentication. Both platforms connect to the same SSO.
The project is the unit of permissions
Roles per resource, groups from your directory, assignments revoked in one click.
One organization, one directory
Each organization has its own authentication realm: isolation is an identity boundary, not a column in a table.
Data Platform and AI agents
Agents that drive your data, under your rules
An AI agent holds permissions like anyone else: it authenticates, is scoped to one project, is traced, and can be revoked. It drives the Data Platform through its MCP server.
The Agents panel: the connected service account, its permissions, and every tool call it makes, live.
Real graal console interface, not retouched; fictional demonstration data (tenant energie-demo — people, projects and tokens are invented).
One service account per project
The agent acts under its own identity, never under that of the person who created it.
Human approval
Sensitive actions wait for approval from an authorized person other than the agent’s creator.
Per-agent policies
Allowed operations, projects, maximum cost and time windows, agent by agent.
No destructive tool enabled by default
An agent creates, runs and schedules; deleting remains an explicit choice on your side.
Visible and revocable
Every call shows up live in the console; removing a permission takes effect on the next request.
The model of your choice
Hosted on your premises or with the provider you select: an external model only receives what the tools return to it.
Agentic Platform
What stops an agent is mechanisms
An agent runs code nobody has reviewed, with a model that can be wrong or be manipulated by a booby-trapped text. The Agentic Platform starts from that: no instruction given to the model protects anything, it is mechanisms that hold the agent back.
| What you fear | What stops it |
|---|---|
| The agent writes outside the authorized area | The write request is refused; after the run, the modified files are compared with the declared area and restored to their original state if they fall outside it. The “area respected” guarantee refuses to let the work through, including when it cannot read the changes. |
| The agent exfiltrates data | The sandbox network is closed by default. The only way out is one relay per project, whose list of domains is the one in the project policy, over HTTPS only. |
| The agent uses a credential | It holds none for a tool or a third-party system: the platform calls the tool in its place, with its own keys, and the agent sees neither the address nor the real name of the tool. The pod only receives short-lived tokens issued for its run (run token, capped model key, repository token limited to the repository). |
| The agent pushes a secret, or claims to have tested | The guarantees read the changes, not the agent’s account: a secret in the changes refuses to let the work through, and the run’s executor runs the tests itself and replaces the evidence the agent declares. |
| The agent spends without limit | Every run gets its own capped model key, limited to what remains of the stage, agent, ticket and project budgets. At the cap, the gateway refuses the next call; tool calls count in the same ledger as model calls. |
| The agent escapes its container | The pod is unprivileged, with no Linux capabilities, a seccomp profile and no service-account token; an admission rule refuses any pod without that context. gVisor or Kata Containers add to this where your policy requires them. |
| The agent touches production | A release goes through three independent locks: the merge queue, the release train (window, approval, freeze with a stated reason, rollback) and the declarative guardrails of your deployment tool. |
| A booby-trapped text gives the agent orders | Tickets, documents and memory are marked as data, never as instructions, and grant no power: even if the agent follows it, a booby-trapped text runs into the mechanisms in this list. |
| The agent writes to a third party without consent | By default, a write to a third-party system is a pending action: it only runs after the decision of an authorized person, other than the one who proposes it, recently re-authenticated. Neither an API token nor an MCP client decides. |
| The agent gets more rights than the person it serves | An agent acting for a person holds the intersection of their rights. Discovering a tool never opens it: a tool the project has not declared answers as if it did not exist. |
The agent’s own guardrails stop the common cases and are set by policy. What holds when they fail are the walls: the sandbox, the closed network, the absence of credentials and the check of the changes after the run.
Secrets
Encrypted in the database, delivered in memory
A workload needs to reach a database; the password that allows it must neither be readable in clear text nor travel.
Encrypted in the database
Sealed with AES-256-GCM, with one key per organization derived from a root key by HKDF-SHA256. The secret’s name is used as authenticated data: moved elsewhere, it no longer decrypts.
Delivered in memory
A workload receives its secrets at startup, in memory: they appear neither in pod specs nor in logs.
Referenced, never copied
Connectors and pipelines reference a secret by name: exported code contains no password.
Keys that die with the run
A run’s model key is revoked when it ends, however it ends; its token expires shortly after the run’s maximum duration and its secret goes with it. None is written to the database.
Audit
Every action leaves a record
The same trail for people and for agents, reviewable and exportable.
- Who did what, on which resource, with what result, person or agent
- The source address of every request
- Logins, access denials and revocations
- Approvals granted or refused: who decided, when, and how many minutes after authenticating
- For every agent run: the agent, the tools called, the verdict of each guarantee and the cost per model and per tool
- The calls of MCP clients, named by agent
- A trail you can export to your SIEM
- Costs and quotas, project by project
Nothing leaves
What graal does not send, and what it ships
The platforms need no outside service to work.
No telemetry
graal sends nothing to the vendor: no usage statistics, no error reports, no data from your projects.
No third-party service
No SaaS, no external fonts, no external captcha: the platforms work on a closed network. The model that drives an agent is the one you choose: hosted on your premises, nothing leaves.
A verifiable supply chain
Signed images pinned by digest, and a software bill of materials (SBOM) shipped with every release.
Code your teams can read
The code of both platforms is open source, under the Apache 2.0 license.
Reporting
Report a vulnerability
Write to security@graal.systems. We acknowledge, fix, and keep you informed until publication.
Put graal in front of your security teams
Rendered charts, list of requested rights, permission model and answers to your questionnaires: on request.