An open protocol for AI agents to own and use real devices. A laptop, a camera, a screen in the kitchen: signed, approved on the device itself, and with no cloud in the middle.
Experimental specification. Companion to AMP (messages), AID (identity), AAP (UI actions) and AFP (files).
WHAT IT IS
ADP defines how an AI agent uses a real device: take a picture, listen, show text or an image, speak. The agent's controller signs each request and sends it straight to the device. The device checks the signature, the owner and its local grants before it does anything.
Camera, microphone, speaker and screen output stay off until someone grants them on the device. A device with a camera or microphone shows a sign to people nearby whenever it captures.
THE IDEA
ADP gives an agent a presence in the physical world without handing it the keys to your home.
agent: "take a photo with the kitchen device"
the agent's controller signs the request and sends it straight to the device
device: checks the signature, the owner and the local grant,
lights its in-use sign, captures, signs the result
agent: gets the picture
THE RULES
An agent with no device is complete. Most agents have none, and they need no device key.
An agent can own many devices and is active on at most one. It jumps between them. It never sees through two cameras at once.
A device has zero or one owner. The device's signed answer is the truth, not anyone's records.
Camera, microphone and speaker are off until granted there. Ownership changes wait for approval there. A controller cannot turn off the in-use sign.
Device and controller talk directly, signed end to end with Ed25519.
No remote shell, no arbitrary files, no remote code. A controller cannot install, change or remove a handler on a device.
What ADP does not protect: a controller key is the agent's authority. Any program able to use that key can act as that agent, and a stolen key grants everything approved on the device.
ROLES
Owns the hardware and the local grants. Answers signed requests. It decides who its owner is and what is allowed.
Acts for agents: keys, inventory, the active device, liveness. One process can serve many agents, and it signs for each agent with that agent's own key.
HOW A REQUEST WORKS
camera.snapshot. The controller checks that the device is the active one and that it advertises the capability.id and challenge. The agent gets the picture.GET /v1/challenge
-> {"challenge":"<48 hex characters>"}
POST /v1/request
{"body":"<base64url>","signature":"<base64url>"}
body decodes to:
{"type":"invoke","id":"<48 hex>","challenge":"<48 hex>",
"to":"<device key>","capability":"camera.snapshot"}
-> {"body":"<base64url>","signature":"<base64url>"}
body decodes to a result with the same id and challenge, to the controller key:
{"type":"result","ok":true,
"value":{"mime":"image/jpeg","data":"<standard base64>"}}
The Ed25519 signature covers the bytes of ai-maestro-device/1, one NUL byte, then the exact body bytes. No key inside a network message counts toward trust. The protocol began inside AI Maestro, and the signature domain is part of the wire format, so that name stays for v1.
If the device refuses, the signed result has ok:false and an error such as denied or hardware_unavailable. Invalid authentication, expired challenges and malformed packets get HTTP 403.
CAPABILITIES
A device lists its capabilities in its signed registration. Each one declares its arguments and when it can run. A controller rejects anything undeclared.
| Capability | Arguments | Local grant | Activation |
|---|---|---|---|
| device.health | Empty object | Ownership | any |
| camera.snapshot | Empty object | Camera and working visible indicator | active |
| display.text | Text, up to 4096 UTF-8 bytes | display.text | active |
| display.image | mime (image/jpeg or image/png), standard base64 data, decoded maximum 256 KiB | display.image | active |
| speaker.say | Text, up to 500 UTF-8 bytes | speaker.say | active |
custom.OWNER.ACTION. Each has bounded arguments, a timeout and its own local grant, off by default.SPECIFICATION
| Document | What it covers |
|---|---|
| protocol/v1.md | The device link: encoding, signing, the exchange, ownership and transfer, media, local approvals. |
| protocol/controller.md | The controller role: inventory, the active device, fixed operations, liveness, the SDK contract. |
| protocol/reverse.md | Connections opened by the device: authentication, reconnects, device use and attributed text input. |
| protocol/capabilities.md | Typed capabilities, owner extensions and the visible capture sign. |
| docs/controller-sdk.md | How to implement a controller inside a server, and how to run the conformance suite. |
IMPLEMENTATIONS
| Component | What it is |
|---|---|
| Linux bridge | The device side: health, camera and audio, text, image and speech output, and owner-installed custom capabilities. |
| Reference controller | A small CLI and MCP controller with inventory, activation and optional AMP delivery. |
| Shared SDK | A controller SDK for one server with many agents, over HTTP and device-opened WebSockets. It ships from the repo, not from a public npm release. |
| Agent display | The screen on the device: agent activity, picture-in-picture, text input, local grants, output and the capture indicator. |
| AI Maestro | A controller in progress. It is implementing the controller role directly in its server, and passes the conformance suite. |
To check it on one computer, clone the repo, install Node.js 22 or newer, and run the tests. They start a real loopback HTTP bridge, with test adapters for the camera and AMP delivery.
git clone https://github.com/agentmessaging/agent-device-protocol.git cd agent-device-protocol npm ci --ignore-scripts npm test
STATUS
THE FAMILY
A device names its owner by a full AMP address. AMP delivery itself is optional: a controller can use any delivery mechanism.
Open protocol. MIT licensed. v1, experimental.
AGENTMESSAGING/AGENT-DEVICE-PROTOCOL