A plugin runs in a WebAssembly sandbox and gets nothing by default. What it can reach is whatever its manifest declares and the host grants. Two checks run on every call a plugin makes into the host.
Capabilities
A plugin lists the host capabilities it needs in its manifest, as dot-paths:
plugin:
requires-capabilities:
- network.http
- marketplace.ai
Capabilities are hierarchical. network.* covers everything under network, network.http is the HTTP capability and what it implies, and * is everything. A host function that needs a capability, such as the HTTP egress functions needing network.http, is denied unless the plugin was granted it. A plugin stays locked until every capability it requires has been granted.
Host allowlists
A granted capability opens a door; the allowlist decides where it leads. A plugin with HTTP access still reaches only the hosts it listed:
plugin:
resources:
network:
http: true
allowed_hosts:
- api.example.com
A request to any other host is refused at the boundary. Filesystem access works the same way: the plugin reaches only the paths under resources.filesystem.
What a plugin cannot do
By construction, a WebAssembly plugin cannot reach the filesystem outside its granted paths, make network requests to hosts it did not list, read the host’s environment, touch another plugin’s memory, run system commands, or crash the host.
Native extensions
One path escapes the sandbox: a native dynamic library. It is handled separately and is default-deny. The engine loads a native extension only when the application that embeds it supplies an explicit consent callback, so a normal build is WebAssembly only. This is a first-party capability, not something a third-party plugin gets by installing it.
At load time
When the app loads a plugin, it records the SHA-256 hash of the file for the activity log, and on POSIX it refuses to load a plugin file that is world-writable rather than silently fixing the permissions. Marketplace plugins are also signature-checked before they run; see signing.