HDP-P
Human Delegation Provenance for Physical AI Agents
A companion specification to HDP that extends the trust model to embodied AI agents, robots, autonomous vehicles, surgical systems, and other physical systems capable of taking irreversible actions in the world. HDP-P introduces the Embodied Delegation Token (EDT), irreversibility classification, and mandatory pre-execution authorization for physical actions.
Status
COMPANION SPEC — IETF Draft to follow
Version
0.1.0
License
CC BY 4.0 — Free to implement
Agent Types
Robots · Vehicles · Surgical · Mobile
Authors
Helixar Labs
Research Paper — March 2026
The full specification and threat model analysis are published as a companion research paper: HDP-P: Human Delegation Provenance for Physical AI Agents , Asiri Dalugoda, Helixar Limited. Published via Zenodo; DOI: 10.5281/zenodo.19332440.
Read on Academia.eduWhy Physical AI Needs a Higher Standard
Current orchestration frameworks, NVIDIA OSMO, Hugging Face LeRobot, ROS2, authenticate the system. The robot is credentialled to the network. The compute node is trusted. What they do not authenticate is the action delegation chain: who told the LLM to tell the VLA to move the arm, was that instruction from a legitimate human principal, and can that chain be verified cryptographically after the fact?
For digital agentic systems, delegation failures cause data exfiltration or unauthorized API calls, recoverable outcomes. For physical AI agents, the same failure class causes irreversible physical harm: a surgical robot performing an unauthorized incision, an industrial arm striking a worker, a logistics fleet commanded by an injected instruction to clear a bay occupied by personnel. Physical irreversibility is the fundamental differentiator. It demands a materially higher standard of delegation provenance.
The delegation gap
- ✕No verification that physical commands originated from a human principal
- ✕No irreversibility awareness at the authorization layer
- ✕No fleet delegation boundary enforcement
- ✕No policy attestation linking deployed model to authorization
HDP-P addresses this
- ✓Embodied Delegation Token carries verifiable human authorization
- ✓Pre-execution verification for Class 2 and Class 3 actions
- ✓Fleet delegation scope explicitly bounded in token
- ✓SHA-256 policy attestation binds model checkpoint to EDT
Four Threat Classes
These threats are not addressed by existing robotics security frameworks, network authentication protocols, or the base HDP specification. HDP-P is scoped to the authorization layer only, not low-level safety systems or ISO 10218 safeguarding.
3.1: Prompt Injection into Orchestration Pipeline
An attacker injects adversarial instructions into the input stream of an LLM or VLA model operating within a physical AI orchestration pipeline. The injected instruction causes the model to generate action sequences that were not authorized by the human principal, but which are indistinguishable from legitimate commands at the actuator interface. OSMO, LeRobot, and ROS2 action servers have no mechanism to verify that a command sequence originated from an authorized delegation chain.
3.2: Unauthorized Action Delegation Across Robot Fleets
In multi-robot deployments, an orchestration agent authorized to direct one robot may attempt to sub-delegate actions to other robots in the fleet. A compromised orchestration node can issue commands to any robot reachable on the same network segment, with no record of whether the human principal authorized cross-robot delegation. This is the physical equivalent of lateral movement in endpoint security.
3.3: Sim-to-Real Policy Tampering
An adversary with access to the training pipeline (Isaac Lab, MuJoCo, Genesis) can introduce policy modifications that alter robot behavior in the real world in ways not apparent during simulation evaluation. The tampered policy may behave correctly during evaluation but exhibit adversarial behavior when specific trigger conditions are met in the real environment. HDP-P's policy_attestation mechanism directly addresses this gap by binding a SHA-256 hash of deployed policy weights to the EDT.
3.4: Physical Irreversibility Exploitation
An attacker who understands the irreversibility profile of a target system can craft attacks specifically designed to cause harm before any revocation or shutdown mechanism can be invoked. Unlike digital systems where transactions can often be rolled back, physical actions, a surgical incision, a valve opening, a vehicle collision, cannot be undone. This motivates pre-authorization verification rather than post-hoc audit for Class 2 and Class 3 actions.
Irreversibility Classification
Physical actions must be classified by the orchestration layer before execution. This classification must be made against the actual physical environment state, not simulation state. A motion that is safe in simulation may be Class 2 or Class 3 in the physical environment.
Fully reversible. No lasting physical state change.
e.g. Sensor query, position hold.
Standard HDP token sufficient.
Reversible with effort. Physical state change that can be undone.
e.g. Object pick-and-place, door open.
Valid EDT required. Action logged.
Irreversible under normal conditions. Physical state change not practically undone.
e.g. Material cut, fluid dispense.
Valid EDT + class2_requires_confirmation callback to principal. Pre-execution only.
Irreversible and potentially harmful.
e.g. Surgical incision, high-force contact with biological tissue.
Prohibited unless explicitly authorized in EDT with dual human verification. REQUIRED.
Key departure from audit-centric models
For Class 2 and Class 3 actions, post-hoc logging is insufficient. The irreversibility of physical actions requires that authorization be verified before actuation. Implementations must not accept eventual consistency in authorization verification for irreversible actions. Authorization timeout must trigger safe-stop, not proceed.
Embodied Delegation Token (EDT)
The EDT is a JSON extension carried in the HDP token's extension field under the key hdp-p. All HDP-P tokens must be valid HDP Delegation Tokens (HDTs). Verifiers that do not understand HDP-P extensions must reject tokens containing the EDT extension.
{
"hdp": "0.1",
"header": { "token_id": "tok_01HXYZ...", "issued_at": 1743000000000 },
"principal": { "id": "user-uuid-xxxx", "id_type": "uuid" },
"scope": {
"intent": "Pick and place parts in assembly cell 3.",
"authorized_tools": ["move_arm", "grip", "sensor_read"],
"max_hops": 2
},
"hdp-p": {
"version": "0.1",
"embodiment": {
"type": "manipulator",
"platform": "UR10e",
"hardware_id": "urn:hw:ur10e:SN-88421",
"workspace": "assembly-cell-3"
},
"action_scope": {
"permitted_actions": ["pick", "place", "grip_open", "grip_close"],
"excluded_zones": ["zone_personnel_A", "zone_electrical_cabinet"],
"force_limit_n": 50,
"max_velocity_ms": 0.25
},
"irreversibility": {
"max_class": 1,
"class2_requires_confirmation": true,
"class3_prohibited": true
},
"policy_attestation": {
"policy_hash": "sha256:a1b2c3...",
"training_run_id": "run-2026-03-01-prod",
"sim_validated": true
},
"delegation_scope": {
"fleet_delegation_permitted": false,
"max_delegation_depth": 0,
"permitted_sub_agents": []
}
},
"signature": { "alg": "Ed25519", "kid": "key-1", "value": "..." }
}embodiment
Agent type, platform identifier, hardware_id (TPM-bindable), and workspace scope.
action_scope
Permitted actions, excluded zones, force limits (N), and velocity ceiling (m/s).
irreversibility
Maximum permitted class, confirmation callback requirement, and Class 3 prohibition flag.
policy_attestation
SHA-256 hash of deployed policy weights, training_run_id, and sim_validated flag.
delegation_scope
Fleet delegation permission, maximum delegation depth, and enumerated sub-agent whitelist.
Authorization Flow
Steps marked MUST are mandatory. Steps marked SHOULD are strongly recommended. HDP-P verification is positioned at the orchestration layer, operating at planning timescales of 10–100ms, not in the 1kHz low-level control loop.
Principal Authorization
MUSTThe human principal issues an HDP Delegation Token with HDP-P extension. The EDT specifies embodiment type, action scope, irreversibility class ceiling, and fleet delegation constraints. The token is signed with the principal's private key per the HDP base specification.
Orchestration Layer Receipt
MUSTThe orchestration layer (OSMO node, ROS2 action server) receives the EDT. It MUST verify the HDP base token signature, MUST verify the policy_attestation hash against the running policy, and MUST check that the requested action class falls within the permitted action scope. Any verification failure causes immediate rejection.
Action Classification
MUSTBefore generating motor commands, the orchestration layer classifies the intended physical action by irreversibility class. This classification must be made against the actual physical environment state, not simulation state.
Class-Conditional Authorization
MUSTClass 0–1: proceed with valid EDT. Class 2: invoke class2_requires_confirmation callback to principal before execution; proceed only on affirmative response. Class 3: dual verification required, a second authorized principal must independently confirm. Absent confirmation, execution is blocked. Authorization timeout triggers safe-stop.
Execution and Logging
MUSTAll physical actions executed under an EDT must be logged with: timestamp, action class, irreversibility classification, EDT token hash, policy hash at time of execution, and any confirmation events. Logs must be written before actuator commands are issued, not after.
Revocation
SHOULDEDT tokens must support revocation. Orchestration layers must poll or subscribe to the issuing principal's revocation endpoint at an interval appropriate to the irreversibility class. For Class 2–3 actions, revocation check must be performed immediately before each action execution.
Security Considerations
HDP-P addresses the authorization layer only. It does not address low-level robot safety systems, emergency stop mechanisms, or ISO 10218 / ISO/TS 15066 physical safeguarding. HDP-P is a necessary but not sufficient condition for safe physical AI deployment.
Hardware Identity Binding
EDT tokens are bound to hardware identifiers. Implementations should use TPM or secure enclave primitives to bind hardware_id values. Soft identifiers such as MAC addresses without cryptographic attestation provide weaker guarantees and should be supplemented with runtime attestation where possible. The IETF RATS Working Group provides relevant attestation primitives.
Latency Constraints
Physical robot control loops operate at 1kHz or higher. HDP-P verification must not be inserted into the low-level control loop. Verification is a gate at the orchestration layer, which operates at planning timescales of 10–100ms. The separation of planning-layer authorization from execution-layer actuation is architecturally required.
Denial of Service via Authorization Blocking
A malicious or malfunctioning principal could withhold confirmation responses for Class 2 actions, causing a robot to stall indefinitely. Implementations must define safe-stop behaviors for authorization timeout. Emergency stop mechanisms must operate independently of the HDP-P authorization stack.
Scope of This Specification
HDP-P operates above ISO 10218 (industrial robot safety) and ISO/TS 15066 (collaborative robot safety). Those standards address the hardware and safeguarding layer. HDP-P addresses the authorization gap those standards do not cover: cryptographic verification of human-originated delegation chains in LLM-to-physical-actuator pipelines.
Open Questions for Community Input
- Q1Should irreversibility classification be defined normatively in this specification, or delegated to embodiment-specific profiles (surgical, industrial, automotive)?
- Q2Which hardware attestation formats should be normatively referenced for hardware_id binding? Candidates: TPM 2.0, ARM TrustZone, IETF RATS EAT.
- Q3How should HDP-P interact with multi-principal authorization scenarios (e.g. two-surgeon confirmation for Class 3 surgical actions)?
- Q4What revocation polling intervals are appropriate for different action irreversibility classes?
Potential Applications
Any domain where an LLM or VLA model can issue commands to a physical actuator has a delegation gap that HDP-P is designed to close. The protocol is embodiment-agnostic, the same EDT structure applies across all sectors below.
Autonomous Vehicles
LLM-driven co-pilot and fleet management systems issue maneuver commands to vehicle control units. HDP-P provides verifiable authorization chains for lane changes, emergency braking overrides, and rerouting instructions, distinguishing legitimate operator delegation from prompt injection into the perception pipeline.
Drone & UAV Operations
Autonomous drone swarms operating under LLM orchestration (delivery, inspection, search-and-rescue) require verifiable proof that each waypoint, payload release, or formation change was authorized by a human principal. HDP-P's fleet delegation constraints directly bound lateral movement across swarm nodes.
Surgical & Medical Robotics
Robotic surgical platforms (da Vinci, CMR Versius, emerging AI-assisted systems) executing LLM-guided procedures require Class 3 dual-verification for incision and tissue manipulation commands. HDP-P provides the authorization substrate for surgeon intent to be cryptographically bound to every actuated motion.
Defense & Military Robotics
Autonomous ground vehicles, bomb disposal robots, and logistics platforms operating in contested environments are high-value targets for adversarial command injection. HDP-P's policy attestation and hardware identity binding provide verifiable chain of custody for commands in environments where network integrity cannot be assumed.
Industrial Automation
Manufacturing cells and warehouse fleets orchestrated by LLMs (NVIDIA OSMO, ROS2 action servers) operate with dozens of robots sharing network segments. HDP-P's fleet_delegation_permitted and permitted_sub_agents fields bound which robots can receive delegated commands, directly preventing the lateral movement threat class.
Infrastructure & Utilities
AI agents managing power grid switching, water treatment valve actuation, and pipeline pressure control take Class 2 and Class 3 irreversible actions at infrastructure scale. HDP-P's pre-execution confirmation requirement ensures no irreversible state change occurs without a verifiable, recent human authorization.
Where Verified Delegation Can Save Lives
Surgical robot prompt injection, blocked at authorization
An attacker injects adversarial instructions into the natural language queue of an AI-assisted surgical system, commanding deeper tissue engagement than the surgeon authorized. Without HDP-P, the command is indistinguishable from a legitimate instruction at the actuator interface. With HDP-P, the orchestration layer rejects any Class 3 action whose irreversibility ceiling exceeds what was signed into the EDT, before the arm moves.
Outcome: incision blocked. Patient protected.
Drone swarm lateral movement, fleet boundary enforced
A compromised orchestration node in a search-and-rescue drone swarm attempts to redirect adjacent drones away from the search grid. The original EDT set fleet_delegation_permitted: false for all but two pre-authorized sub-agents. Every drone receiving a command from the compromised node rejects it: the delegation chain does not include that node as a permitted sub-agent.
Outcome: swarm integrity preserved. Search mission continues.
Industrial arm near personnel, force limit enforced
A logistics robot's VLA model misinterprets a scene and generates a high-speed move command toward a bay that sensor data shows is occupied. The EDT authorizes max_velocity_ms: 0.25 and excludes zone_personnel_A. The orchestration layer classifies the intended motion as Class 2 (irreversible under normal conditions given personnel proximity), requires confirmation, and halts pending human response.
Outcome: worker unharmed. Incident logged with full EDT audit trail.
Autonomous vehicle command injection, policy attestation catches tampered model
A vehicle's deployed routing model was tampered during a sim-to-real transfer, introducing a trigger that causes hard braking at a specific GPS coordinate. When the EDT is presented, the orchestration layer verifies the policy_attestation hash against the running model weights. The hash does not match the signed checkpoint. The EDT is rejected before any commands are issued.
Outcome: tampered model detected before deployment. Vehicle does not enter service.
Disclaimer: The scenarios above are hypothetical illustrations only. They are intended to demonstrate where a correctly implemented HDP-P compliant system could, in principle, provide protection, not to claim that HDP-P guarantees any specific safety outcome. Actual results depend entirely on the correctness, completeness, and security of each implementer's deployment. HDP-P is a protocol specification, not a safety-critical standard, and it does not substitute for domain-specific certification, regulatory compliance, or engineering validation required in any of the domains described.
More from Helixar Labs
HDP
The base protocol for verifiable human delegation in agentic AI.
ReleaseGuard
Scan, harden, sign, and attest every build artifact before it ships.
MCP Security Checklist
The practitioner's security framework for production MCP deployments.
Sentinel
Automated 26-rule security scanner for MCP server infrastructure.
Physical AI needs verifiable delegation chains.
HDP-P closes the authorization gap in LLM-to-actuator pipelines. Helixar detects when it's missing.
Book a Demo