Skip to main content
A plugin can only do what its manifest declares and the operator approves. The capability catalog is generated from one source of truth (capabilities.toml) into the agent (Python and Rust) and the GCS (TypeScript) so the three halves cannot drift. This page lists the real catalog, the risk levels each capability carries, and how the install dialog presents them. There are 43 agent capabilities and 19 GCS capabilities. Three agent capabilities are runtime-enforced (see the note in the agent section); the GCS set is 12 UI slot registrations plus 7 data and command capabilities.

Risk levels

Every capability in the catalog carries a risk level. The install dialog badges each requested capability by its level and surfaces an overall risk for the plugin. The manifest also declares a top-level risk field (low, medium, high, or critical).

Declaring permissions

Permissions go in the agent.permissions and gcs.permissions lists. Each entry is an object with an id and an optional required flag:
Required permissions are pinned on in the install dialog; the operator cannot install while leaving them off. Optional permissions default to off and the operator flips them on when wanted.

Agent capabilities

43 capabilities, grouped by namespace. The risk column is the value carried in the catalog.
Three agent capabilities are runtime-enforced at the IPC layer: event.publish, event.subscribe, and hardware.gpio_out. The host re-resolves the required capability from the method (and, for the event bus, from the topic) on every request and rejects an ungranted call. The other capabilities gate access at the surface they front (for example, a manager refuses to register a driver without the matching permission).

event.* (event bus)

Flight commands

telemetry.*

sensor.*.register

hardware.*

vision.*

Data, compute, and radio

GCS capabilities

19 capabilities. The GCS half declares 12 UI slot registrations plus 7 data and command capabilities. UI slot capabilities mount a panel in a named slot; the slot value itself goes in contributes.panels[].slot (see the Manifest reference).

UI slots

ui.slot.node-detail-tab, ui.slot.cockpit-panel, and ui.slot.flight-skill are scoped to the currently selected node; the other nine are fleet-level.

Data and command

Two-stage install

  1. The operator drags a .adosplug into the install dialog.
  2. The host parses the archive in memory: it validates the manifest, verifies the Ed25519 signature, and returns a summary with the requested permissions, the signer id, and the risk level. Nothing is written to disk.
  3. The dialog renders the summary plus a permission grid. The operator flips optional toggles and clicks Install.
  4. Only then does the host commit the install, unpacking the archive and writing state to disk.
A plugin that never makes it past step 3 leaves no traces.

Re-prompt on update

Installing a newer version that requests one new optional permission re-opens the dialog with only the new permission highlighted. Existing grants are preserved. A new required permission is shown with emphasis and the operator must approve it. Removing permissions in an update is silent: the host drops the no-longer-declared grants on load.

Capability tokens on the wire

Every plugin process runs with a capability token the supervisor mints at start, bound to the plugin id, the granted capability set, a session id, and an expiry. The agent IPC server checks the token and the required capability before routing each request. The plugin cannot forge a capability by lying in the envelope; the host re-resolves the required capability from the method (and, for the event bus, from the topic) and rejects an ungranted call with permission_denied.

See also