Skip to content

Security checklist#

Astralyx enforces its boundaries whatever you configure: every request is checked against the person's role and confined to its workspace, secrets never reach Astralyx, and your machines accept no inbound connection. What remains yours to decide is who gets access and how much. Use this checklist when you set up an organisation, and review it every quarter.

What Astralyx guarantees#

These hold for every organisation, with nothing to configure:

  • Confinement. Everything a person does in a workspace — console, astra, API, MCP — is done as them, with their workspace role, inside that workspace only. Another workspace's work on the same machine appears only as taken capacity.
  • Tenant isolation. On Astraeus Cloud, your machines run only your workspaces' work, your workers reach only your machines, and your names resolve only on your machines.
  • No secret values. Credentials are references to your secret manager, resolved on your machines; the console and API refuse fields holding a secret value.
  • Data stays on your machines. Datasets, drives, model weights, logs and notebooks stay on your machines; the console reads logs from the machine when you open them.
  • Outbound only. Machines connect out over HTTPS; nothing connects to them.
  • No private addresses. URLs you give Astralyx — your identity provider, webhooks, SIEM — are reached only on public addresses.
  • Machines act only for themselves, and a removed machine's credentials stop working at once.

The Security model and What leaves your machines explain each.

People and roles#

  • At least two owners, both people you trust with the whole organisation. Only owners make owners. (Members)
  • Few admins. Each organisation admin is an admin of every workspace, sees every machine and can grant host access.
  • Each person has the narrowest workspace role that lets them work; compliance reviewers are auditor, not viewer. (Roles)
  • Pending invitations you no longer expect are revoked; nobody is invited as admin who should be a member.
  • People who left are removed, after being disabled at your identity provider. (Offboarding)

Sign-in#

  • Single sign-on is on, with Allowed e-mail domains set to your company's domains and Role for new members member. (Single sign-on)
  • Your identity provider releases email_verified only for addresses it has verified.
  • People know that signing in is at console.astralyx.cloud only, and approve a CLI code only when they just ran astra login themselves.

Tokens and automation#

  • Automation runs as a dedicated account, an organisation member added only to the workspaces it needs. (Automation and CI)
  • Every API token has an expiry, one token per pipeline or tool, stored in a secret store.
  • Eos API keys name only the deployments they need, and expire. (Eos)

Workspaces and their terms#

  • Privileged work is granted only to workspaces whose people you would give root on the machines. (Host access)
  • Host paths are as narrow as possible (/datasets, never /).
  • Maximum priority above 0 is granted deliberately: higher priority preempts other teams' work. (Maximum priority)
  • Sensitive machines are in their own pool, granted only to the workspaces allowed on them. (Pools)
  • Workspaces that share a cluster have quotas.
  • The hosted inference gateway is on only for workspaces that need it: with it, requests and answers to their deployments pass through Astralyx. (Eos)

Machines#

  • Install commands are treated as secrets until used: one per machine, never committed to a repository. (Add machines)
  • No machine is marked behind for long: update agents from the cluster's Machines tab. (Update agents)
  • Retired machines are removed from the cluster and uninstalled. (Remove a machine)
  • Each machine's data location is on a disk meant for data, with a size limit where disks are shared. (Data location)
  • Faulty GPUs are cleared only after they were reset or replaced.

Monitoring#

  • Alert rules for every workspace, and the machines cover at least machine_down, gpu_degraded and job_failed. (Alerts)
  • An event stream sends at least outbound_denials, tool_denials, approvals and guardrails to your SIEM. (Event streams)
  • Someone reads the audit log regularly, looking for sso.configure, sso.remove, org.member.role, workspace.binding.update (host access and priority), cluster.enroll and cluster.node.remove. (Audit log)
  • Each workspace's event retention matches your policy. (How long events are kept)

Agents#

  • Organisation guardrails forbid what no agent may do anywhere. (Agent governance)
  • The marketplace requires an admin's approval for templates published by others. (Marketplace)
  • Each workspace with agents has budgets and approvals for sensitive actions. (Anemoi)

If something is compromised#

What Do at once
A person's account Remove them from the organisation; they reset their password, which ends every session. Rotate the secrets they could use at their source.
An API token The person revokes it in Account & tokens; or remove the person from the organisation.
An install command not yet used It expires by itself (24 hours from the console). On Astraeus Cloud it counts towards the machine limit until then. If an unknown machine joins, remove it.
A machine Remove it from the cluster: its credentials stop working at once. Reinstall it from a clean system.
An SSO client secret Rotate it at your provider, then save the new one in Single sign-on.
A webhook signing key Remove the channel or stream and add it again: a new key is made.

To report a vulnerability in Astralyx, see security.txt.