Security
Built to hold a risky call for a person
Glion runs agents that hold real credentials and act on real infrastructure. This page says how it is designed to keep that safe, where the design stops, and how to tell us when something does not hold.
How it is designed
Reads run, writes wait
- Before a connector call that may write, Glion reads what the target looks like now and records a change plan with a hash. When a policy holds the call, a person approves that hash; by default, every destructive call and every shell command is held. If the target has changed by the time the call commits, the call is asked about again, never retried.
- Policies attach to classes of action, not to agents, so a new agent inherits them. They can match on what a call does and where it lands: its risk, reach, effect, reversibility and target.
- Every policy says how long a held call may wait before it is denied. Waiting forever is a box someone has to tick.
- A policy can ask for two approvers and refuse self-approval, and every decision is made by a named account.
- Some calls are refused outright, and no approval overrides them.
An agent has only what it was granted
- Tools are granted one at a time, per agent, and the grant is checked again on every call rather than once at the start.
- Registering a connector grants nothing on its own. A tool can be blocked for every agent at once.
- A subagent runs inside a share of its parent’s budget, so it cannot outspend the agent that started it.
Credentials stay out of sight
- Provider keys and connector credentials are encrypted at rest with AES-256-GCM, and decrypted only for the call that needs them.
- They are never logged, never returned to the browser, never placed in a URL and never written to the audit log. The console sees a masked hint at most.
- Glion asks for a scoped, revocable token, never a login password, and says the least privilege that will work. A credential is verified by calling the service before Glion says it worked.
- A native driver passes a service’s responses through an allowlist of fields, so a password field a service returns, or adds in a later release, does not reach the model.
The process is fenced
- The shell tool and MCP servers started as local processes get an allowlisted environment, not the control plane’s own. Its encryption key and database address do not reach them.
- File tools resolve every path inside the session’s workspace and refuse to leave it. Web fetches are checked against the environment’s egress allowlist.
- Files an agent writes are served as downloads with a sandboxing content policy, so a page an agent wrote cannot run in the console.
- The container runs as an unprivileged user.
The scan is gentle and recorded
- Glion scans private address ranges only, a /22 at most, one scan at a time.
- Before the first packet it records the range, who asked, from where, and a hash of the exact consent wording they accepted. A scan with no consent is refused.
- It never logs in, sends a credential or guesses a password. It never connects to print servers or industrial control ports, where a bare connection can do harm.
- An agent cannot start a scan. Scanning is an operator’s action.
The defaults are the careful ones
- The console is published on loopback only until you change it.
- The database password, the encryption key and the console password are generated on the first run. The console password is printed once.
- In production Glion refuses to start with no encryption key set.
What this does not fix
Whatever the host Glion runs on can reach, an agent can reach. That is what makes it useful, and it is the whole risk.
Text an agent reads, such as a container log, an annotation or an issue, can carry instructions, and the agent may follow them from inside your network with your credentials. No network control stops that. Holding the destructive calls for a person is the layer that does, which is why Glion has one. Grant the fewest tools that do the job, and keep the destructive ones behind a policy.
A shell has one operation, "run this", so no policy can tell a harmless command from a destructive one. Glion offers SSH as a last resort and never recommends it: every call over it is judged by a person or not at all.
Glion is not built to face the open internet. Reach it over a VPN or an overlay network, with TLS in front.
How it was checked
In September 2026 Glion had an internal security review: a threat model, a findings list with each serious finding put to a second reviewer whose job was to refute it, and a record of the controls that were read and found sound. The review's documents are internal. A report that a control described on this page does not actually hold is especially welcome.
Report a vulnerability
Email [email protected]. Please do not report anything exploitable in public. Include, as far as you can:
- what an attacker gains,
- the version or commit you tested,
- the smallest steps that reproduce it.
If you have a fix in mind, say so, but a clear report is enough. Do not send live credentials, yours or anyone else's. There is no encryption key for reports yet; if a report cannot go by plain email, say so in a first message and we will agree a way.
You can expect an acknowledgement within a few days. Glion is maintained by one person, so please allow reasonable time for a fix before any public disclosure. We will agree a timeline with you.
In scope
The server, the console, the container image and Compose file, the default configuration and the database migrations. A finding that a default deployment is unsafe is in scope even without a memory-safety bug.
Out of scope
Anything that needs the development switch that turns authentication off, which the operator sets on purpose and which refuses to run anywhere but loopback. Weaknesses in a model provider or a connected service, rather than in Glion itself.
This policy is also published as security.txt.