Plugin permissions

A plugin can only do what its manifest declares and the operator grants. The capability catalog is generated from one source (capabilities.toml) into the agent (Python and Rust) and Mission Control (TypeScript), so the halves cannot drift. This page is the canonical list of capabilities, their counts and their risk levels. There are 53 agent capabilities and 26 GCS capabilities. The GCS set is 13 UI slot capabilities plus 13 data, command, cloud and bus capabilities. A plugin can also define capabilities of its own for the data it shares (see Plugin-declared capabilities).

Risk levels

Every capability carries a risk level. The install dialog badges each requested capability by its level. The manifest also declares a top-level risk for the whole plugin (low, medium, high or critical, default medium).

Level	Meaning
Low	Sandboxed or read-only. No flight or hardware effect.
Medium	Touches shared hardware, opens the network, reads frames, or registers a sensor.
High	Can command the vehicle, inject into the estimator, drive output hardware, accept inbound connections, or spawn subprocesses.
Critical	Direct attitude and rate control of the aircraft (`flight.rate_setpoint`).

Declaring permissions

Permissions go in the agent.permissions and gcs.permissions lists. Each entry is an object with an id, an optional required flag and an optional degraded_behavior; a bare string means required.

agent:
  permissions:
    - id: telemetry.read
      required: true
    - id: recording.write
      required: false
      degraded_behavior: "Runs without saving clips."

Required permissions are pinned on in the install dialog. Optional permissions are shown with a toggle the operator sets. An id that is not in the catalog is a warning, not an error: the manifest loads, but the permission grants nothing.

How capabilities are enforced

44 of the 53 agent capabilities are enforced, by one of three mechanisms:

The dispatch gate re-resolves the required capability from the method on every request and rejects an ungranted call.
A handler-side check covers what a method alone cannot classify, such as an event topic or a MAVLink message id.
The generated unit’s sandbox covers the rest: the device policy, the socket address families and bind ports, and the mount namespace. See the security model.

The other nine are advisory metadata: mavlink.component.camera, mavlink.component.gimbal, mavlink.component.payload, mavlink.component.peripheral, sensor.camera.register, sensor.depth.register, sensor.lidar.register, sensor.imu.register and sensor.payload.register. GCS capabilities are enforced by the Mission Control bridge, which resolves the capability each call needs and checks it against the grant.

The catalog

The table covers both halves. Rows whose Enforced column reads n/a are GCS capabilities; an id listed twice (such as event.publish or mission.write) exists on both halves, one row for each.

Capability	Category	Risk	Enforced	Description
`button.subscribe`	hardware	medium	Yes	Lets the plugin receive press events (short, long, chord) from the host’s front-panel buttons. Used by node plugins that drive an on-device workflow from physical buttons. Read-only; it does not remap or consume the buttons from other consumers.
`cloud.publish`	data_network	medium	Yes	Lets the plugin publish small messages (at most 64 KiB each) on its own cloud stream through the agent’s cloud relay, so a signed-in operator can receive them off the local network. Publishing detections onto the shared detection topic additionally needs vision.detection.publish.
`cloud.read`	data_network	low	n/a	Lets the plugin read shared fleet data from the cloud backend (drone status rows, paired devices, fleet roster).
`cloud.records`	data_network	medium	Yes	Lets the plugin write small JSON records (at most 64 KiB each) into its own collection in the operator’s cloud account, where the plugin’s GCS half can read them back.
`cloud.records`	data_network	low	n/a	Lets the plugin list, read, write and delete records in its own cloud collection for the signed-in operator (for example job history). Records are keyed by plugin, so a plugin can never read another plugin’s records. Each record is capped at 64 KiB and each plugin at 5000 records.
`command.send`	flight_control	medium	n/a	Lets the plugin ask the GCS to send takeoff, land or return-to-launch to the drone it is bound to, or retarget that drone’s follow tracker. The operator confirms every one of these in a prompt that names the drone. Arming, mode changes and every other command are refused. The same grant lets the plugin write its own per-drone configuration without a prompt.
`display.oled.page`	hardware	low	Yes	Lets the plugin register a page (its rendered content and touch or hit zones) on the host’s onboard display, so a plugin can present status without recompiling the display service. The host owns page switching and arbitration between contributed pages.
`estimator.pose.inject`	flight_control	high	Yes	Lets the plugin push pose samples (position, attitude, or both) directly into the autopilot state estimator. A bad pose stream produces unsafe position commands and fly-aways.
`event.publish`	data_network	low	Yes	Lets the plugin emit events on topics it has been granted access to. Other plugins and host services that subscribe to the same topic will receive the payload.
`event.publish`	data_network	low	n/a	Lets the plugin emit events on the in-memory GCS event bus other installed plugin panels subscribe to. The bus never leaves the browser tab; it carries no host authority of its own.
`event.subscribe`	data_network	low	Yes	Lets the plugin subscribe to topics it has been granted access to. The plugin sees payloads from other plugins and from host services that publish on those topics.
`event.subscribe`	data_network	low	n/a	Lets the plugin subscribe to topics on the in-memory GCS event bus and see payloads other installed plugin panels publish.
`filesystem.host`	compute_process	medium	Yes	Lets the plugin read and write files outside its own data directory. Required by plugins that ingest logs, maps, or other host-provided files.
`flight.guided_setpoint`	flight_control	high	Yes	Lets the plugin command the flight controller with guided-mode position or velocity setpoints (and the guided-mode entry and exit handshake) through a scoped sender, instead of raw MAVLink writes. The setpoint stream is the only flight-command surface this capability grants.
`flight.rate_setpoint`	flight_control	critical	Yes	Lets a plugin command the flight controller with SET_ATTITUDE_TARGET setpoints (an attitude quaternion and/or body rates, plus collective thrust) through a scoped sender, for GUIDED-mode vehicles that accept attitude/rate offboard control. This is a second flight-command surface alongside guided-mode position/velocity setpoints; the setpoint stream is the only flight-command surface this capability grants.
`hardware.camera.csi`	hardware	medium	Yes	Lets the plugin capture video frames from CSI-attached cameras on the SBC’s camera connector. Required by native camera drivers.
`hardware.gpio`	hardware	medium	Yes	Lets the plugin read input pins and drive output pins on the SBC. Used by switches, LEDs, and discrete peripheral control.
`hardware.gpio_out`	hardware	high	Yes	Lets the plugin drive a host GPIO output line high or low and play a bounded buzzer or LED beep pattern through the agent’s GPIO-output service. Output-only; it does not read input pins.
`hardware.gpu`	hardware	medium	Yes	Lets the plugin open the host’s GPU and neural-accelerator device nodes (DRM render nodes, Mali, RKNPU, NVIDIA) for inference or rendering. Without it the plugin runs in a private /dev with no accelerator.
`hardware.i2c`	hardware	medium	Yes	Lets the plugin talk to I2C devices on the SBC’s I2C buses. Used by sensor drivers and small peripherals.
`hardware.spi`	hardware	medium	Yes	Lets the plugin talk to SPI devices on the SBC’s SPI buses. Used by displays and high-rate sensor drivers.
`hardware.uart`	hardware	medium	Yes	Lets the plugin open and exchange data over UART serial ports. Required by GPS, range-finder, and modem drivers.
`hardware.usb`	hardware	medium	Yes	Lets the plugin attach to and exchange bulk transfers with USB devices. Required by vendor SDK drivers that talk to specific USB peripherals.
`hardware.usb.uvc`	hardware	medium	Yes	Lets the plugin capture video frames from USB Video Class cameras. Required by webcam and machine-vision drivers.
`mavlink.component.camera`	flight_control	medium	No	Lets the plugin register itself as a MAVLink camera component and respond to camera-related MAVLink messages from the GCS and the autopilot.
`mavlink.component.gimbal`	flight_control	medium	No	Lets the plugin register itself as a MAVLink gimbal manager or device and handle gimbal control messages. Required by gimbal driver plugins.
`mavlink.component.payload`	flight_control	medium	No	Lets the plugin register itself as a MAVLink payload component for actuators, droppers, and other mission-specific hardware.
`mavlink.component.peripheral`	flight_control	medium	No	Lets the plugin claim a MAVLink component id for a peripheral that does not fit the camera, gimbal, or payload categories. Used by sensor bridges and experimental devices.
`mavlink.component.vio`	flight_control	high	Yes	Lets the plugin register as a VIO source that publishes pose estimates over MAVLink. The autopilot can fuse these directly into the EKF, so a faulty source can cause unsafe flight behavior.
`mavlink.read`	flight_control	low	Yes	Lets the plugin observe the live MAVLink message stream, including telemetry, mode changes, and status text. Useful for analytics, logging, and dashboards.
`mavlink.tunnel`	flight_control	high	Yes	Lets the plugin exchange application payloads over MAVLink TUNNEL frames (a private payload_type) on the existing link, without the full MAVLink write surface. Used for plugin-to-plugin or node-to-node application data carried inside the MAVLink stream.
`mavlink.write`	flight_control	high	Yes	Lets the plugin inject MAVLink commands to the autopilot, including mode changes, arming, and parameter writes. An untrusted plugin with this capability can take control of the aircraft.
`mcp.expose`	data_network	medium	Yes	Lets the plugin publish its declared tools, resources, and prompts to an MCP client, and lets the host route a tool invocation into the plugin. Exposure alone grants no host authority: each tool acts only through the plugin’s OTHER granted capabilities, so a tool can never do anything the plugin could not already do.
`mcp.expose`	data_network	medium	n/a	Lets the plugin publish its declared GCS-half tools, resources, and prompts to an MCP client. A GCS-only tool routes through the GCS bridge (command / mission), so its effect is still bounded by the plugin’s other GCS capabilities and the MCP token’s scope.
`mission.read`	flight_control	low	Yes	Lets the plugin read the active mission, waypoints, fences, and rally points stored on the agent.
`mission.read`	flight_control	low	n/a	Lets the plugin read the active mission, waypoints, fences, and rally points that the operator has loaded into the GCS planner.
`mission.write`	flight_control	high	Yes	Lets the plugin upload new missions, edit waypoints, or change fence and rally definitions. Used by mission-planner and pattern-generator plugins.
`mission.write`	flight_control	high	n/a	Lets the plugin upload, edit, or replace missions in the GCS planner. Used by pattern generators and mission-template plugins.
`msp.read`	flight_control	low	Yes	Lets the plugin observe the raw MSP byte stream from a Betaflight / iNav / KISS flight controller, so it can decode telemetry, sensor, and status replies. Read-only on the MSP stream; the sibling of mavlink.read for an FC that speaks MSP instead of MAVLink.
`msp.write`	flight_control	high	Yes	Lets the plugin write raw MSP commands to a Betaflight / iNav / KISS flight controller, including MSP_SET_RAW_RC (the RC channel values that fly the aircraft in a rate mode). An untrusted plugin with this capability can command the aircraft, exactly like mavlink.write on a MAVLink FC.
`network.listen`	data_network	high	Yes	Lets a declared plugin service bind the TCP ports it lists in its manifest (listen_ports) so other nodes on the network can reach it, and advertise those ports on the local network over mDNS through the agent. Every other port stays closed to the plugin, and the plugin’s main process never listens.
`network.outbound`	data_network	medium	Yes	Lets the plugin make outbound TCP, UDP, and HTTP connections from the agent host, and find services on the local network over mDNS through the agent. Required by plugins that talk to external services.
`node.info.read`	hardware	low	Yes	Lets the plugin read what kind of node it runs on: the node profile, the board and whether it has a neural accelerator, the ground-station role, whether the camera pipeline is up, and the main video stream’s size and frame rate. Read-only facts; no telemetry, imagery, credentials or configuration values.
`perception.read`	data_network	low	n/a	Lets the plugin read the drone’s perception state: where detection runs (on the drone or offloaded to a compute node), the bound compute node, and the live session health (feed freshness, throughput). Read-only on derived data; it does not open or read the camera.
`perception.subscribe`	data_network	low	n/a	Lets the plugin subscribe to the live detection stream (bounding boxes, classes, track ids) for the drones the operator has paired, the same detections the cockpit already renders. Read-only; the detections are derived data, not the raw camera feed.
`process.spawn`	compute_process	high	Yes	Lets the plugin launch helper subprocesses listed in its manifest’s spawn allowlist. Required to ship vendor-binary drivers and language runtimes outside the Python plugin host.
`radio.aux_stream`	data_network	high	Yes	Lets the plugin open a dedicated auxiliary stream on the radio link (a separate radio-port from the data and control planes) managed by the radio service, and read or write application frames on it. Used by plugins that need an isolated low-rate channel between nodes.
`recording.write`	data_network	low	Yes	Lets the plugin save video, telemetry, or analysis outputs into the agent’s recording store so the GCS and post-flight tools can find them.
`recording.write`	data_network	low	n/a	Lets the plugin write recordings (video, telemetry CSV, analysis output) into the GCS recording library so the operator can replay them later.
`sensor.camera.register`	hardware	medium	No	Lets the plugin declare a camera device the rest of the agent and the GCS can address (live preview, recording, mission usage).
`sensor.depth.register`	hardware	medium	No	Lets the plugin declare a depth-camera or stereo sensor. Downstream services can consume depth maps for obstacle avoidance and SLAM.
`sensor.imu.register`	hardware	medium	No	Lets the plugin declare a secondary IMU device the rest of the agent can address. Often paired with VIO and odometry workflows.
`sensor.lidar.register`	hardware	medium	No	Lets the plugin declare a LiDAR device. Downstream services can consume point clouds for mapping and obstacle avoidance.
`sensor.payload.register`	hardware	medium	No	Lets the plugin declare a payload device (sprayer, dropper, sampler) so missions and the GCS can address it.
`telemetry.extend`	data_network	low	Yes	Lets the plugin add new fields to the telemetry stream that ships to the GCS. Used by sensor plugins that surface custom readings on the dashboard.
`telemetry.read`	data_network	low	Yes	Lets the plugin read the same telemetry feed the GCS consumes (battery, GPS, attitude, mode). Useful for logging and analytics.
`telemetry.subscribe`	data_network	low	n/a	Lets the plugin subscribe to live telemetry streams (attitude, GPS, battery, mode) for the drones the operator has paired with the GCS.
`ui.slot.cockpit-panel`	ui_slot	low	n/a	Lets the plugin add a panel to the in-flight cockpit quick-settings surface, scoped to the currently selected drone.
`ui.slot.cockpit-widget`	ui_slot	low	n/a	Lets the plugin place a small widget in one of the cockpit’s corner zones over the live video, scoped to the drone the cockpit is flying. The widget renders inside a sandboxed iframe with no host DOM access.
`ui.slot.fc-tab`	ui_slot	low	n/a	Lets the plugin add a tab to the per-drone flight controller area. The tab renders inside a sandboxed iframe with no host DOM access.
`ui.slot.flight-skill`	ui_slot	medium	n/a	Lets the plugin register a flight skill that appears in the cockpit Skill Bar, can be bound to a hotkey or gamepad button, and activated by the operator. Activation flips the plugin’s per-drone config; the cockpit’s arm and confirmation gates still apply.
`ui.slot.hardware-tab`	ui_slot	low	n/a	Lets the plugin add a tab on the Hardware page so the operator can inspect or configure devices the plugin manages.
`ui.slot.map-overlay`	ui_slot	low	n/a	Lets the plugin draw geometry on the map view (polygons, markers, heatmaps). The overlay is rendered in a sandboxed canvas.
`ui.slot.mission-template`	ui_slot	low	n/a	Lets the plugin add a new entry to the mission template picker so the operator can start missions with the plugin’s parameters.
`ui.slot.node-agent-page`	ui_slot	low	n/a	Lets the plugin add a page to the sectioned Agent sidebar of a node’s detail panel, next to the built-in companion and configuration pages. The page is scoped to the selected node.
`ui.slot.node-detail-tab`	ui_slot	low	n/a	Lets the plugin add a per-node tab inside the node detail panel on any node profile (drone, ground station, compute). The tab is scoped to the currently selected node.
`ui.slot.node-surface`	ui_slot	low	n/a	Lets the plugin add a top-level surface to the node detail tab strip for the node profiles it declares (for example a workstation overview). The surface is scoped to the selected node.
`ui.slot.notification-channel`	ui_slot	low	n/a	Lets the plugin push notifications into the GCS notification center so it can surface alerts and status changes to the operator.
`ui.slot.settings-section`	ui_slot	low	n/a	Lets the plugin add its own section to the GCS Settings page so the operator can configure the plugin from a single place.
`ui.slot.video-overlay`	ui_slot	low	n/a	Lets the plugin draw overlays on top of the live video feed (detection boxes, telemetry HUDs). The overlay is rendered above the player.
`video.source.set`	data_network	medium	Yes	Lets the plugin declare the camera and stream sources the agent’s video pipeline should serve (one primary plus optional secondary legs), so a smart-camera or pod driver can auto-configure its own feeds without an operator hand-typing them. Applying a new source list restarts the video pipeline.
`vision.detection.publish`	data_network	low	Yes	Lets the plugin publish detection results (bounding boxes, class labels, confidence, track ids) that other plugins, overlays, and mission logic can consume. Detections are derived data; they do not command the vehicle.
`vision.detection.subscribe`	data_network	low	Yes	Lets the plugin receive the detection batches the vision engine publishes (bounding boxes, class labels, confidence, and the tracker’s stable track id and lock state on the locked object). Detections are derived data; subscribing does not command the vehicle or open the camera.
`vision.frame.read`	compute_process	medium	Yes	Lets the plugin subscribe to normalized camera frames the vision engine publishes (resolution and pixel format set by the engine). Frames are shared read-only; the plugin does not open the camera itself.
`vision.model.read`	compute_process	low	Yes	Lets the plugin read the resolution of its own declared models: for each model the state (resolved, needs-model, verify-failed), the resolved on-disk path and runtime when resolved, and the reason otherwise. This is how a plugin finds where its delivered model was cached so it can load it. Reads only this plugin’s own resolution; it does not read frames, other plugins’ models, or command the vehicle.
`vision.model.register`	compute_process	medium	Yes	Lets the plugin register an inference model (and its input format and output classes) so the vision engine can load and run it, or so the plugin can run it against shared frames. Registered models appear to detection consumers.
`vision.offload.advertise`	compute_process	medium	Yes	Lets the plugin report the perception offload link it holds (whether a compute node is paired, whether the bearer to it is good enough, its address and the model it runs). The node’s perception tier and status read it. The agent counts the node as paired only when the advertised address answers, and only one plugin owns the link at a time.
`vision.track.designate`	flight_control	medium	Yes	Lets the plugin choose which object the vision engine’s single-object tracker locks onto (the follow target), by naming the box to track. This selects a target for downstream follow / framing logic; designation alone does not command the vehicle.
`vision.track.designate`	flight_control	medium	n/a	Lets the plugin ask the GCS to set the vision engine’s follow target on the drone it is bound to, by naming the detection box to track. Designation selects a target for downstream follow and framing logic; it does not command the vehicle.

Telemetry topics

On the GCS half, declare one telemetry.subscribe.<topic> per stream you read (for example telemetry.subscribe.battery). The bridge checks the topic-scoped id exactly; the bare telemetry.subscribe grants no stream.

Commands and designation

command.send lets a GCS half ask for takeoff, land or return-to-launch on its bound drone; the operator confirms each one and every other command is refused. Retargeting the drone’s follow tracker (command.send with vision.designate) needs the separate vision.track.designate capability.

Node-scoped UI slots

ui.slot.node-detail-tab, ui.slot.node-agent-page, ui.slot.node-surface, ui.slot.cockpit-panel, ui.slot.cockpit-widget and ui.slot.flight-skill are scoped to the selected drone; the other seven are fleet-level. Where each slot renders is on Contribution points.

Plugin-declared capabilities

A plugin that shares data on the event bus can define a capability for it under agent.declared_capabilities, with an id of the form plugin.<leaf>.<name> (the leaf is the last segment of the plugin id), a risk and a description. Its shared_topics name that capability as the one a subscriber needs. Another plugin requests it like any catalog capability, and the install dialog shows it with the declared risk and description. The World Engine, for example, declares plugin.world-engine.world.read for its point cloud, occupancy, splat and mesh topics. See Shared topics and declared capabilities.

Two-stage install

The operator opens the drone’s Extensions tab and chooses Install from file, or picks an extension from the list.
The agent parses the archive in memory: it validates the manifest, verifies the Ed25519 signature, checks compatibility, and returns a summary with the requested permissions, the signer and the risk. Nothing is written to disk.
The review shows the summary, the board compatibility and the permission grid grouped by category, with required permissions pinned. The operator sets the optional toggles and chooses Install, a button that names how many permissions it grants.
Only then does the agent unpack the archive and write the install record, and Mission Control grants the approved permissions.

A plugin that never gets past step 3 leaves no trace. From a shell, ados plugin install shows the same summary and asks for approval; see the Plugin CLI reference.

Permissions on update

Auto-update does not apply a version that asks for new permissions; the node reports update_available with the new permissions, and the operator reinstalls to approve them. Grants are recorded per permission, independent of enable and disable. An operator can grant or revoke a declared permission at any time from Mission Control or with ados plugin perms; the change takes effect at once, with no restart.

Capability tokens on the wire

Every plugin process runs with a capability token the host mints, bound to the plugin id, the granted capability set, a session id and an expiry. The host checks the token and the required capability before routing each request. A plugin cannot claim 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. The agent replies capability_denied: <cap>; the Mission Control bridge replies permission_denied.

Start here

Tutorials

Reference

SDKs

Deep dives

Test and distribute

Risk levels

Declaring permissions

How capabilities are enforced

The catalog

Telemetry topics

Commands and designation

Node-scoped UI slots

Plugin-declared capabilities

Two-stage install

Permissions on update

Capability tokens on the wire

Next steps

Manifest

Security model

​Risk levels

​Declaring permissions

​How capabilities are enforced

​The catalog

​Telemetry topics

​Commands and designation

​Node-scoped UI slots

​Plugin-declared capabilities

​Two-stage install

​Permissions on update

​Capability tokens on the wire

​Next steps

Manifest

Security model

Risk levels

Declaring permissions

How capabilities are enforced

The catalog

Telemetry topics

Commands and designation

Node-scoped UI slots

Plugin-declared capabilities

Two-stage install

Permissions on update

Capability tokens on the wire

Next steps