Embodied AI Agent Identity: Controlling Who Can Command Robots, Drones and Machines

When an AI agent can move a robot arm, dispatch a mobile robot or fly a drone, a stolen token or an injected prompt stops being a data incident and becomes a physical safety event. Robots and drones already carry device identities, and agents already carry software identities, but the link between them is usually a single API key on a fleet manager that accepts any command it receives. This guide covers identity and command authority for embodied agents: how to authenticate the agent, the robot and the human principal separately, how to scope and sign commands, how to keep safety functions independent of the agent, and how to log who ordered what. It is written for robotics, OT and identity teams putting language-model agents or autonomous planners in front of physical systems. Device hardening and SROS 2 setup are covered in the Robotics Security Guide and are not repeated here.

Key takeaways

• Three identities, not one. The human or system principal, the agent and the physical device each need their own verifiable identity, and every command should carry all three.
• Authority belongs to commands, not sessions. Scope what an agent may order by action, area, speed and time, and check it at the robot or fleet controller, not only in the agent's prompt.
• Safety functions must not trust the agent. The EU Machinery Regulation requires autonomous mobile machinery to perform its safety functions itself, even when actions come from a remote supervisor.
• Sign and timestamp command messages. Protocols such as MAVLink 2 signing and DDS-Security in ROS 2 give message authentication and replay windows, but both have permissive defaults that must be changed.
• Logs are a legal requirement, not a nicety. The Machinery Regulation asks for evidence of interventions in safety software and a tracing log kept for five years; agent command logs should meet the same bar.

Why embodied agents change the identity problem

For a software agent the worst outcome of misused authority is usually data loss or a bad transaction. For an embodied agent, the action is motion, force or flight, and it cannot be rolled back. Three differences follow.

• Latency and connectivity: robots and drones act on local loops and may lose the link. Credentials and policy must work offline for a bounded period, then fail safe.
• Shared space with people: a command that is authorised in identity terms can still be unsafe in context. Authorisation has to include physical conditions such as zone occupancy and mode.
• Long-lived hardware: controllers stay in service for many years, often with weak native authentication. A gateway or fleet manager often becomes the enforcement point, which concentrates risk.

The general model for agent credentials, delegation and token exchange is in the Agent Identity and Access Guide. This page applies it where the resource is a machine.

The identity chain from principal to actuator

Delegation should be explicit. Where the agent calls a fleet API with OAuth, use token exchange so the access token names both the agent and the human it acts for, and attenuate scopes at each hop. See Delegation Chains and Attenuated Authority for AI Agents. SPIFFE's documentation recommends X.509-SVIDs over JWT-SVIDs where possible because bearer JWTs can be replayed, and suggests separate trust domains for different physical locations or environments, which maps well to one trust domain per site. See the SPIFFE and SPIRE Guide.

Command authority: what an agent may order

Scopes written for APIs ("fleet.write") are too coarse for machines. Express command authority in terms the controller can check.

• Approval for high-consequence commands: fleet-wide stops or starts, entry into occupied zones, payload release and overrides should require a human approval bound to the specific command, not a general session. See the AI Agent Action Approvals and Spending Limits Guide.
• Intent check at the controller: the controller re-validates each command against the token's constraints and the live state of the site. A prompt-injected agent can only ask; the controller decides.
• No credential in the model context: device keys and fleet API secrets stay in a broker or workload identity service, never in the prompt or agent memory, so a prompt injection (ATLAS AML.T0051) cannot read them.

Authenticating and signing commands on the wire

Agent-to-controller traffic usually runs over HTTPS with mutual TLS. Controller-to-device traffic often uses robotics or autopilot protocols with their own security options. Two common ones are summarised below; check your vendor's implementation, since defaults differ.

The ROS 2 design notes are explicit that security is off unless switched on and that permissive mode launches without it, so a missing keystore silently downgrades the robot. The MAVLink specification says implementations may accept unsigned packets under local rules, which is a common gap: a signed link that still accepts unsigned commands gives little protection. For DDS, OMG published DDS Security version 1.2 in February 2026; confirm which version your middleware implements.

Device identity and attestation

An agent should only command a device it can verify. That means a device identity bound to hardware and, where possible, evidence that the device is running expected firmware.

• Hardware-backed keys: issue device certificates with keys in a TPM, secure element or equivalent. Provisioning and renewal are covered in the IoT and Device Certificate Provisioning (EST, SCEP) Guide.
• Remote attestation: the IETF RATS architecture (RFC 9334, Informational, January 2023) defines the Attester (the device), the Verifier that appraises Evidence against reference values, and the Relying Party (the fleet controller) that acts on Attestation Results. In the passport model the device presents a signed result; in the background-check model the controller asks the Verifier. Either way, the controller can refuse tasks to a robot whose firmware does not match.
• Broadcast identity for drones: in the United States, 14 CFR Part 89 requires Remote ID for registered drones operating after 16 September 2023, broadcasting a serial number or session ID, aircraft and control station position, velocity, a time mark and emergency status. Remote ID identifies the aircraft to observers; it is not an authentication mechanism for commands. See the Drone and Counter-UAS Security Guide.
• Inventory: list every device identity with owner, site, firmware version and the agents permitted to command it. Unowned device credentials are the physical-world version of orphaned service accounts. See the Device and IoT Identity Guide.

Keeping safety independent of the agent

Identity controls reduce who can command a machine. They do not make a command safe. The EU Machinery Regulation (EU) 2023/1230, which applies from January 2027, sets requirements that line up with this separation:

• Malicious attempts: Annex III section 1.2.1 requires control systems to withstand reasonably foreseeable malicious attempts from third parties leading to a hazardous situation.
• Protection against corruption: section 1.1.9 requires safety-critical software to be protected against accidental or intentional corruption, and the machinery to collect evidence of legitimate or illegitimate intervention in software or configuration.
• Tracing logs: section 1.2.1 asks for a tracing log of interventions and of safety software versions uploaded after the product is placed on the market, kept for five years, and for self-evolving systems, safety-related decision data kept for one year.
• Supervisory function: section 3.2.4 limits a remote supervisor of autonomous mobile machinery to stopping and starting, only when the supervisor can see the machine's movement and working area. Section 3.3 requires the control system to perform safety functions itself even when actions come through a remote supervisory function.

In practice: the agent never holds credentials that can alter safety controllers, geofences or emergency stop logic; safety limits are enforced below the agent; and the agent's own kill switch is separate from the machine's safety stop. See the AI Agent Kill Switch and Containment Guide. Industrial robot safety standards such as ISO 10218 and the IEC 62443 series for industrial automation security also apply; check which your sector requires.

Choosing an architecture

Small deployments with one vendor fleet should start with the first pattern plus approvals for high-consequence actions. Large multi-site operators should move to per-site trust domains, signed task tokens and attestation before scaling agent autonomy.

Implementation steps

1. Inventory: list agents, fleet controllers, devices and the credentials linking them. Find shared API keys used by more than one agent or human.
2. Give each agent its own identity: a workload identity or OAuth client per agent and per site, with delegated tokens that carry the principal.
3. Define command scopes: action class, area, envelope, time and mode for each agent role. Start deny-by-default.
4. Enforce at the controller: make the fleet manager or gateway validate every command against the token and live state. Run in log-only mode first and compare decisions with what operators would allow.
5. Turn on protocol security: enforce DDS-Security in ROS 2 and require signed MAVLink where used, after a pilot in a test cell or simulator. Keep a rollback plan that returns to supervised manual control, not to unsigned operation.
6. Add approvals: bind human approval to fleet-wide and occupied-zone commands.
7. Separate safety: confirm no agent credential can change safety controllers, geofences or firmware.
8. Log and rehearse: record principal, agent, device, command, decision and outcome for every action, and rehearse revoking an agent mid-task to confirm devices stop safely.

Detection and measurement

• Commands without full identity chain: share of commands lacking principal, agent or device identity, target zero.
• Denied commands by reason: out-of-zone, over-envelope or expired-token denials, which show both misuse and policy that is too tight.
• Unsigned or unauthenticated traffic: unsigned MAVLink packets accepted, DDS participants joining without security.
• Credential age: device certificates and agent credentials past their rotation date.
• Time to revoke: seconds from revoking an agent to the last command it can issue.
• Attestation failures: devices refused tasks for unexpected firmware.

Framework mapping

Common failure patterns

• One fleet API key for everything: the agent, the dashboard and the integration partner share a key, so no command can be attributed and revoking one revokes all.
• Safety rules only in the prompt: "never enter zone C" lives in the system prompt, not in the controller, so an injected instruction or a bug overrides it.
• Permissive protocol defaults: ROS 2 security left in permissive mode or MAVLink accepting unsigned packets after signing was enabled.
• Long-lived delegated tokens: an agent keeps a day-long token for a five-minute task, so a stolen token can command machines after the shift ends.
• Agent can change its own limits: the agent's credential can edit geofences, speed limits or firmware, which collapses the separation between authority and safety.
• Logs that miss the principal: the robot log shows the fleet manager as the actor, with no record of which agent or human asked.

Practitioner checklist

• Give every agent, controller and device its own identity, and stop sharing fleet API keys.
• Carry principal, agent and device identity on every command and in every log entry.
• Define command scopes by action, area, envelope, time and mode, enforced at the controller.
• Require human approval bound to the command for fleet-wide, occupied-zone and override actions.
• Enforce DDS-Security in ROS 2 and signed MAVLink where used, and reject unsigned commands.
• Keep device keys in hardware and use attestation before tasking where the platform supports it.
• Ensure no agent credential can modify safety controllers, geofences or firmware.
• Rehearse revoking an agent mid-task and measure time to safe stop.

Standards and references

• EUR-Lex: Regulation (EU) 2023/1230 on machinery
• eCFR: 14 CFR Part 89, Remote Identification of Unmanned Aircraft
• IETF: RFC 9334 Remote ATtestation procedureS (RATS) Architecture
• OMG: DDS Security specification
• ROS 2 Design: ROS 2 DDS-Security integration
• MAVLink: Message signing
• SPIFFE: SPIFFE concepts
• FAA: Remote Identification of Drones

Related NHI Mgmt Group resources: Agent Identity and Access Guide · Robotics Security Guide · AI in OT and Industrial Systems Guide · Device and IoT Identity Guide