Security
How Volter World handles credentials and the network, and how to report a vulnerability to Volter AI, Inc.
Reporting a vulnerability
Email security@volter.ai: what you found, the package and version (or the page of this site), and the steps that show it. Please give us a reasonable time to fix it before you disclose it publicly. We will acknowledge your report, keep you informed as we work on it, and credit you in the changelog if you would like. Do not access data that is not yours, and do not test against a real vendor's account other than your own.
What runs where
Volter World is software you run. The volter command and the @volter/* packages run on your machines or
servers; Volter operates no service that holds your Worlds, your app's data or your credentials. This site is
static documentation with no accounts. A hosted service is not offered today.
Credentials
- A World needs no real keys. Twins answer your app with fake, structurally valid credentials generated when the
World is set up.
volter world initjudges a committed example (.env.example) by each variable's name: a name shaped like a credential (…_KEY,…_SECRET,…_TOKEN, a password) gets a fake, never the committed value; any other variable is read as app configuration and copied as it is. Its report lists what it kept — check it when an example might carry a live value under an ordinary name. - A real vendor's credential is sealed. When you point a twin at the real vendor (a root), the credential you
give is sealed beside that World under a key held in your user configuration directory (on a host that serves
Worlds, the host's sealing key), and is opened only on the
paths that call that vendor: refresh, deploy, and a write under the
autopolicy. A client of a shared World can use it without ever receiving it. A library you run can also deploy with a credential it holds itself, which the World never seals or sees. - World tokens are credentials. A token to a shared World grants what its scope says (a read token cannot
write). The CLI keeps the tokens it is given in your user configuration directory;
volter world servewrites the token of the World it serves to.volter/tokenin that World's directory, which its.gitignoreexcludes. Treat them like any other secret. - Deploys are checked. Before a change is performed against a real vendor, the World's checks run on it; the built-in check refuses a change that carries a credential-shaped string.
The network
A World calls a real vendor only through a root you configured, and only on refresh, a deploy you run, or a write
under a policy you chose (auto). Apps run inside a World have their calls to vendors that have a twin redirected
to the twins. Other traffic — a vendor with no twin — is refused only when the World runs sealed or under a network
policy; otherwise it goes where the app sends it. That refusal is cooperative — it works inside the processes the
World starts — and is not a network boundary: where you need a guarantee of no egress, run the World inside an
environment that enforces one.
The packages
The @volter/* packages on npm are published from the Volter World source, under the license its package.json names, by an
automated release on each change; each version's contents are the tarball npm holds. Report a package that behaves
unlike its documentation as you would a vulnerability.
Last updated: 28 September 2026.