The security model
What plugs can do, what the agent can see, and which protections come from the host.
This page describes where the boundaries are. It does not say that a configuration is safe: that depends on what you put in it.
Plugs are trusted code
A plug is a module that runs in the process of the run, on the runner, with the rights of the user
who started blaise-agent listen. It can read that user's files and environment and reach the
network. A local plug file, or a package in your dependencies, therefore has the same standing as
any other dependency of the project. Review plugs the way you review code you run.
A blaise:shell script is the same: it runs on the host with the rights of the account the host
gives it.
What the agent receives
On the runner's own machine, processes start from the runner's environment without the runner
token (BLAISE_RUNNER_TOKEN). The environment of the adapter that Blaise configured for the
agent, and what plugs add to ctx.agent.env, are layered over it. Every other variable of the
runner's environment is therefore visible to the agent and to the scripts of plugs: do not keep
secrets in the environment of a runner that you do not want them to see. On a remote host, processes
start from that machine's own environment, plus what plugs add.
Plugs read the runner's environment through ctx.runnerEnv, which also omits the token, and pass
chosen values on. The runner talks to Blaise; the agent and the host do not hold its credentials.
The runner and the host
With a host plug, the plugs after it and the agent run their commands and file operations on the other machine, while the plug code stays on the runner. The agent's messages reach the runner over the process's input and output, so the host needs no route back to Blaise. See Hosts and where code runs.
What a host protects depends on the host:
ssh. The machine's own account and permissions apply. The plug connects only to a machine whose key matches the pinned fingerprint. The private key is read from a file on the runner.docker. The container's isolation applies, and it is only as strong as the container configuration. A mounted Docker socket or a volume of your home directory removes it.sandbox. Operating-system limits on files and the network apply to the processes it wraps. It works on the runner's machine only.
The Docker and sandbox plugs have unit tests, and opt-in tasks that use the real Docker daemon and the sandbox runtime. Those opt-in tasks have not been run yet on a real runner, so do not rely on the isolation of these two plugs for untrusted work until you have checked it on your own machine.
What Blaise stores for plugs
Persisted plug state is encrypted at rest, never shown in the dashboard, and readable only with the session token of that session's runs. It is for ids and paths. A secret should be derived again on every run.
Messages are stored as the runner reports them. A plug that redacts messages changes what is reported, not what the agent sees or does. See Redact secrets from messages.