ATEP in practice
This page explains, without protocol jargon, what ATEP changes for the people who run, build, certify, insure or fund robots and AI agents. The technical detail lives in the specification.
The problem
Robots and AI agents from different makers have no shared, open way to prove three things: who is sending a command, that it was not changed on the way, and that the sender is certified for that kind of command. In practice, each vendor tends to build its own closed version of this, these rarely work across vendors, and many assume a working internet connection. To our knowledge, no open, vendor-neutral standard combines these today (see the related-work section of the specification).
Words used here
- Envelope
- A message wrapped so that it is signed, and between agents also encrypted, which lets the receiver check who made it and that it is unchanged.
- Attestation
- A signed statement by a third party, for example that a named robot passed a safety standard.
- Certifier
- Any organization that issues attestations, such as a safety testing body or a fleet operator; each receiver decides which ones it trusts.
- Revocation list
- A signed list, published by an issuer, of identities or certifications that must no longer be trusted.
- Offline verification
- Checking an envelope on the machine itself, using keys and lists saved earlier, with no internet connection.
What ATEP gives you
Who sent it
Every sender has an identity that is a fingerprint of its own public keys. A receiver can recognize a known sender without looking anything up, and nobody without the matching private keys can sign as that identity.
Was it altered
The sender signs the message, so a change after signing makes the check fail. Messages between agents are also encrypted from sender to receiver, so relays, brokers and base stations carry them without being able to read them.
Is the sender certified for this kind of command
In the robotics profile every command belongs to one of seven classes, and each class needs certificates the sender must hold. Moving a robot is a lower bar than operating its arm: see the table below.
Works offline
The checks run on the robot or agent itself. Nothing needs to be fetched at the moment of use, as long as the keys and revocation lists were saved earlier and have not gone stale.
Cutting off a compromised unit
An operator publishes a signed revocation list naming the unit. To be honest about the limit: a unit learns of a revocation when it next receives the updated list. A unit whose list is too old refuses motion, actuation and maintenance commands (and safety commands other than an emergency stop) but still accepts telemetry.
Quantum-safe
Every signature and key exchange pairs a classical algorithm with a NIST post-quantum standard (FIPS 204 and FIPS 203), and both halves must hold. That is why we say quantum-safe, not more. The reference code has not been independently audited.
Two further properties. ATEP is carrier-agnostic: an envelope is a string of bytes that is checked the same way whether it travelled over MQTT, ROS 2, HTTP, MCP, A2A or as a file. It is also vendor-neutral: each receiver chooses which certifiers it trusts, and there is no mandatory root authority.
| Class | Examples | The sender must hold |
|---|---|---|
| telemetry | position, battery, status | fleet member |
| sensor | lidar, camera, detections | fleet member and trusted sensor source |
| coordination | task claims, path reservations | fleet member |
| motion | waypoints, velocity, path updates | fleet controller, or fleet member with the controller's permission to command the listed peers |
| actuation | arms, tools, payload release | fleet controller and safety certified |
| safety | emergency stop, geofence changes | safety authority (an emergency stop is also accepted from any safety certified fleet member) |
| maintenance | firmware, configuration, key rotation | maintenance authority |
Five scenarios
Illustrations of how the protocol behaves, not case studies: no deployment is described. Each has a link to the section of the specification that defines the behavior.
A warehouse with the network down
Robots from three vendors share a floor. Without ATEP, a check that depends on a cloud service stops working when the network does, and the robots either stall or trust more than they should. With ATEP, they verify each other from keys and certificates saved earlier and keep coordinating, even while the fleet controller is unreachable (the demo (opens in a new tab) shows two robots doing exactly that). A motion command from a device the fleet holds no certificate for is refused. This holds while their revocation lists are fresh; once a list is past its update time, motion commands are refused until a new one arrives.
A hospital robot is offered an update
A delivery robot receives a software update from a sender it has never seen. Without ATEP, whether it accepts depends on how well that vendor's own update channel is guarded. With ATEP, an update is a maintenance command, and that class needs a sender certified as a maintenance authority by a certifier the robot trusts. This sender holds no such certificate, so the robot declines the update and carries on with its last safe behavior.
A remote farm with patchy connectivity
A field robot is online for a few minutes a day. Without ATEP, proving that a machine is safety certified usually means asking someone over the internet. With ATEP, the safety certificate travels with the message and is checked on the machine against issuer keys saved earlier. The robot works with the last revocation list it has. If that list is too old, it fails closed: it refuses motion commands and keeps handling telemetry.
A compromised unit
One robot's keys are stolen. Without ATEP, each vendor system has its own way to cut it off, if any. With ATEP, the operator publishes one signed revocation list, and units that receive it reject that unit's commands from the revocation time on. Units that have not yet received it do not know. An emergency stop from any certified fleet member still works even if its other certificates have expired, but never from a revoked or retired identity.
AI agents handing work to each other
An agent passes a result to another agent. Without ATEP, the receiver knows little beyond the channel the text arrived on. With ATEP, the receiving agent can tell which agent produced the result and that it was not altered on the way. The protocol treats the content as data, never as instructions. ATEP does not make the content true or safe; it makes its origin checkable, so the receiver can handle it accordingly.
| Situation | Without ATEP | With ATEP |
|---|---|---|
| Network is down | Checks that need the internet cannot run | Robots verify each other from keys saved earlier, even with the fleet controller unreachable; unknown senders are refused |
| Unknown sender offers an update | Depends on the vendor's own update channel | Declined unless the sender is a certified maintenance authority |
| Patchy connectivity | Proving a certification needs a connection | Certificates are checked on the machine; motion stops when the revocation list is too old |
| A unit is compromised | Vendor-specific, often manual | One signed revocation list; units that receive it reject that unit |
| Agents hand off work | Origin and integrity are not checkable | Producer and integrity are checkable; the content is still treated as data |
How it fits together
- Sender: signs the message with its private keys and encrypts it for the receiver.
- Any carrier: radio, MQTT, ROS 2, HTTP, MCP, A2A or a file. Relays cannot read the message.
- Receiver: checks identity, signature, certificates and the revocation list on the machine itself. No internet is needed at that moment.
- Cached keys and revocation lists, filled earlier: the receiver reads these during the check. They must have been saved before the connection was lost.
What ATEP does not do
- It does not make a robot safe, and it does not decide whether a command is wise. It shows who sent the command and what that sender is certified for.
- Certifications are as good as the certifier. ATEP shows that a certificate exists and who issued it; each receiver decides whether that issuer deserves trust.
- A compromised sender that still holds valid keys can keep sending valid commands until it is revoked, and a unit learns of the revocation when its list is updated, not before.
- Offline verification needs caches filled earlier. A unit that has been cut off for longer than its revocation list stays fresh will refuse the commands that matter most.
- It is not a product. It is an open protocol with an open specification, reference code and test vectors.
- It is a working draft (Draft 07), not a standard, and the code has not been independently audited.
Who it is for
- Fleet operators choose which certifiers to trust, issue fleet and authority certificates, and publish revocation lists. Start with the live simulator (opens in a new tab), where one of four units is revoked and refused on screen, and where certified members keep verifying each other with the controller offline.
- Robot and software makers add verification to the software they already ship, over whatever carrier it uses. Start with the quick start.
- Safety certifiers and insurers can issue certificates that are checked on the machine and can be withdrawn, with a public log of issuance defined to keep certifiers accountable. Start with the claim types and section 17 of the specification.
- Agent developers can verify which agent produced a result and that it was not altered before acting on it. Start with the quick start; the repository also has carrier examples for MCP and A2A.
- Funders and journalists can read the status on the overview and the commitments on the governance page.
Try it in your browser in the live simulator (opens in a new tab), read the specification, or follow the work on GitHub.