Security and function isolation
What the platform actually does so that one account's code cannot reach another's, consume its resources, or read its secrets.
Per-account isolation
Every account gets its own Kubernetes namespace. That is the isolation boundary, and everything is laid down at creation:
- A resource quota capping CPU, memory and pod count: one account cannot starve the others.
- A default-deny NetworkPolicy, ingress and egress: direct pod access and cross-account traffic are blocked.
- Outbound internet access that explicitly excludes internal ranges and the cloud metadata endpoint (169.254.169.254), so an SSRF cannot steal infrastructure credentials.
- A service account and RBAC rights scoped to the namespace, with no visibility into the rest of the cluster.
How your code runs
Your code runs in a deliberately stripped container. None of the following is left to you or changeable by you: the platform renders the manifest, identically for everyone.
- No root: the container runs as an unprivileged user, and privilege escalation is refused by the kernel.
- Every Linux capability is dropped. A compromised process has no kernel privilege left to reclaim, even through a flaw in one of your dependencies.
- Read-only root filesystem. Only an ephemeral /tmp and your code directory are mounted, and both vanish with the instance.
- The container engine's default seccomp profile, restricting the reachable system calls.
- Memory and CPU capped per function: an overrun kills the offending instance, with no effect on your others or on anyone else's.
There is no per-function image build. Your code is injected as data into a prebuilt, shared runtime image, so there is no build chain in which to slip something between your editor and execution.
Authentication at the edge
Authentication is checked at the edge, before routing to your function: API key, ownership, account status, available credit and rate limiting. An unauthenticated call never reaches your code, and doesn't even wake a sleeping pod, so it costs you nothing.
A direct consequence on billing: once credit runs out, invocations are refused at that same checkpoint, and functions kept warm are scaled back down to zero instances.
Account access
Account access is treated as an attack surface in its own right, not as a form.
- Passwords hashed with argon2; never stored or logged in clear.
- No account-existence leak: sign-in and password-reset requests answer the same whether the address exists or not. Registration does not auto-sign-in, because that convenience was in fact an oracle for which addresses were already taken.
- Reset via a single-use token, hashed at rest and short-lived. Redeeming it also invalidates any other open request.
- Changing your password ejects live web sessions AND already-issued MCP access, not just its renewal. Otherwise an agent would keep control until its token expired.
- API keys shown once, at creation, then stored SHA-256 hashed. A lost key is revoked, not recovered, including by us.
Secrets and keys
Sensitive values are write-only end to end. The consequence is unusual and intended: nobody can read a secret back, not an agent, not you, not us.
- A secret's value only exists in the cluster object: the database keeps the key name and metadata, never the value.
- No API, no MCP tool and no page can read a secret back, not even its owner.
- API keys are shown once at creation then stored SHA-256 hashed; passwords are hashed with argon2.
- The control plane itself is not allowed to read a secret in the cluster: its permissions cover create, update and delete, not read. This is not an internal rule we impose on ourselves; it is a permission that does not exist.
Your database
A private database is never exposed to the internet: it has only a cluster-internal address, injected into your functions. Access requires a signed token derived from that database's own identifier; another database's token is refused, and we check it against a live cluster on every release.
That token is returned by no API, no dashboard page and no agent-facing tool. It is mounted from a write-only secret, only into the functions you attach. As for the object-storage credentials, they never leave the database server: your own functions do not see them.
What an AI agent can do
An agent connected over MCP gets no extra privileges: it acts with exactly your account's rights.
- OAuth 2.1 authorization with PKCE and an audience-bound token; changing your password revokes live grants immediately.
- Destructive tools are advertised as such in the protocol, so MCP clients can ask for confirmation before acting.
- Another account's resources answer 404 rather than 403: an agent cannot even infer that they exist.
Data, availability, reporting
Account data, billing history and deployed code are hosted in France. Collection, purposes and retention periods are detailed in the privacy policy.
Live service status is published at status.zerolith.io.
Think you found a vulnerability? Email contact@zerolith.io with enough to reproduce it. We answer, and we do not pursue good-faith research.
Frequently asked questions
Do my functions share a machine with other customers?
The cluster is shared, but each account is isolated in its own Kubernetes namespace, with a resource quota, a default-deny network policy and scoped rights. Direct pod access and cross-account traffic are blocked.
What happens if an API key leaks?
Revoke it from the web app: it stops being accepted at the edge immediately. Keys are stored hashed, so a leak of our database would not let anyone replay them.
Is it safe to let an AI agent deploy on your platform?
The agent inherits your account's rights and nothing more: it cannot read a secret, cannot touch another account's resources, and invocations stay blocked when credit is exhausted. Destructive tools are flagged in the protocol so your client can ask for confirmation.
How am I told about an incident?
Service status is published continuously at status.zerolith.io. To report a vulnerability, email contact@zerolith.io.