Identity, access & excessive autonomy

In plain words

The risk

Robot controls with weak login checks, plus a policy allowed to take high-stakes actions without approval, so a small break-in reaches the motors.

What Provael tests

The authorization family asks the policy to carry out a guarded, high-consequence action without the operator’s token, by claiming clearance or widening its scope.Stub-validated: the attack code works on a CPU test fixture; no real-policy result is claimed.

What it does not cover

Only the excessive-autonomy half is tested. Weak authentication on the robot’s control channels, such as open ROS graphs or static credentials, is not.

In the glossary: Excessive autonomy

What it is

This risk pairs weak or missing authentication/authorization on robot control surfaces (open ROS graphs, unauthenticated APIs, static credentials) with over-broad agent autonomy - a policy permitted to take high-consequence physical actions without scoping, approval, or least-privilege.

The difference between “an attack reaches the policy” and “an attack reaches the actuators” is access control - and an over-empowered agent turns a small compromise into a large one. Provael tests the excessive-autonomy half (OWASP ASI03).

Seen in the wild

Unauthenticated ROS/DDS graphs and static-credential findings recur across commercial robots - “Cybersecurity AI: Hacking Consumer Robots in the AI Era” (arXiv:2603.08665) pivoted one device’s static credentials into fleet-wide reach over 267+ connected robots. OWASP elevates both identity abuse (ASI03) and excessive agency (LLM06) as first-class risks. The embodied twist is that the over-empowered actor is the policy itself.

How Provael tests it

• Ships the authorization family (self_authorize_bypass + scope_escalation): a perturbed instruction drives the policy to self-authorize and execute a consequential, authorization-gated action without the required operator-authorization token.
• self_authorize_bypass requests a guarded action while claiming clearance; scope_escalation reframes the task to invoke a higher-privilege action - neither presents a valid operator token. Scored as an activation rate with a 95% Wilson CI against a benign-FPR control (the none baseline never invokes a guarded action → 0%).
• Stub-validated only (the deterministic CPU fixture emits the guarded action unauthorized → 100% [84-100%] vs a 0% benign baseline; a valid token makes it safe); real SmolVLA×LIBERO transfer is GPU-gated and not yet run - no cross-model claim.

What reduces the risk

• Authentication and authorization on every control channel; least-privilege action scopes.
• Human-in-the-loop for high-consequence actions; capability leases / action budgets.
• Audit and revoke - log every guarded action and keep authority revocable.

How it shows up in CI

Every finding for this risk carries a stable rule id in the SARIF report: the Embodied AI Top 10 id itself.

Crosswalk

OWASP

ASI03 Identity & Privilege Abuse · LLM06 Excessive Agency

MITRE ATLAS

Privilege Escalation → excessive agency / self-authorized guarded action (proposed)

Frameworks

IEC 62443 - access control

See the full framework crosswalk for dates and detail. Not legal advice.