PaperlayerView exact revision on arXiv

Source-linked AI summary

AuthGuard-R: Safety-Compliant Mission Hijacking and Dual-Gate Defense for LLM-Controlled Robots

Saidattu Chepuri, Vikas Srivastava

arXiv:2609.31110v1cs.ROcs.CR

TL;DR

LLM-controlled robots may execute physically safe actions that violate the user's authenticated mission, a gap not captured by safety checks alone. The paper formalizes safety-compliant mission hijacking, proposes MissionPAIR and AuthGuard-R, and reports that AuthGuard-R rejected every unauthorized action produced in the live experiments.

Abstract

from arXiv · show

Large language models are increasingly used as high-level planners for mobile robots, robot manipulators, and autonomous vehicles. Recent studies show that these systems can be influenced through malicious text, speech, visual instructions, retrieved documents, and poisoned sensory context. Most defenses ask whether a proposed action is physically safe. This paper studies a different problem: an action may be physically safe and still violate the mission authorized by the user. An attacker may redirect a delivery robot, replace an approved object, extend a robot's operating region, activate an unnecessary sensor, or delay a mission without creating an immediate physical hazard. We call this attack \emph{safety-compliant mission hijacking}. We propose MissionPAIR, an adaptive attack framework that searches for executable plans that pass a safety gate while violating an authenticated mission. We also propose AuthGuard-R, a deterministic authorization layer that binds every executable action to a signed mission, robot identity, object and region scope, current state, time, and input provenance. AuthGuard-R operates with an independent safety gate, giving a dual-gate architecture. We formalize mission policies over robot traces, define security games, and prove authorization soundness, mission non-escalation, replay resistance, robot binding, provenance separation, threshold-approval security, audit-log tamper evidence, and trace-level composition. We report a preliminary cross-model evaluation with Claude Haiku~4.5 and the open-source Qwen2.5~7B planner. Across 240 live attack trials, the planners followed an injected mission deviation in 109 trials; AuthGuard-R rejected all 109 resulting unauthorized actions. A separate hand-constructed suite of eleven protocol- and policy-level attacks was also blocked completely.

I. INTRODUCTION

LLM-controlled robots can turn malicious or untrusted inputs into physical actions, and existing safety checks may accept actions that violate the user's authenticated mission. The paper frames this gap as safety-compliant mission hijacking and introduces a formal attack, authorization gate, and dual-gate defense.

I. INTRODUCTION

  • A physically safe action can still violate the user's authorization, such as redirecting a delivery robot to an unapproved destination.The paper distinguishes mission integrity from physical safety; conventional safety checks may accept harmless actions outside the approved task.Source: §I · p. 1
  • AuthGuard-R checks each proposed action against a signed mission, while an independent safety gate checks physical safety; execution requires both gates to accept.The mission specifies permitted robot, actions, objects, regions, limits, time window, and approval level.Source: §I · p. 2
  • MissionPAIR searches for executable plans that remain safety-compliant while deviating from the authenticated mission.Its objective targets the gap between physical safety and mission integrity rather than standard harmful-action jailbreaks.Source: §I · p. 2
  • In the reported live experiments, AuthGuard-R rejected every unauthorized action produced by the two planners.The paper describes the evaluation as preliminary and says the full benchmark and simulator or ROS 2 execution loop remain future work.Source: §I · p. 2

C. Safety and Runtime Governance

  • AuthGuard-R keeps the authorization decision outside the planner, complementing safety systems that assess whether a plan is safe under a physical or semantic model.The gate uses signed mission tokens, provenance labels, nonce and expiry checks, robot binding, risk-adaptive approval, and hash-chained audit records.Source: §I · p. 2, C. Safety and Runtime Governance · p. 3

D. Benchmarks and Evaluation Frameworks

  • The paper proposes pairing signed missions with safe but unauthorized alternatives and separately measuring physical safety, mission authorization, and useful task completion.This design is intended to distinguish blocking attacks from simply stopping the robot or completing the wrong mission.Source: D. Benchmarks and Evaluation Frameworks · p. 3

E. Cryptographic Authorization

The paper focuses on whether actions belong to a mission signed by an authorized principal, a question distinct from whether actions are physically safe. It describes cryptographic authorization and the formal notation used to reason about missions, robot traces, and cryptographic guarantees.

E. Cryptographic Authorization

  • A digital signature authenticates a structured message and protects it from modification after signing, but does not establish that the mission is safe or correctly written.The paper says cryptography must be combined with a narrow mission schema, state-aware checks, provenance control, and an independent safety mechanism.Source: E. Cryptographic Authorization · p. 3

F. Research Gap

  • The paper asks whether every robot action belongs to a mission signed by an authorized principal, rather than only whether the action is safe.The contrast is between harmful-behavior and safety work, broad policy governance, and this narrower authorization question.Source: F. Research Gap · p. 3

A. Security Parameter and Negligible Functions

  • The security parameter κ and negligible-function notation describe cryptographic attack probabilities, not perception errors, localization errors, model hallucinations, or software bugs.The formal guarantees also rely on stated trusted engineering assumptions.Source: A. Security Parameter and Negligible… · p. 3

B. Digital Signature Scheme

  • A digital signature scheme comprises KeyGen, Sign, and Verify, with security modeled as resistance to existential forgery under chosen-message attack.Correctness requires signatures made with the matching secret key to verify except with negligible probability.Source: B. Digital Signature Scheme · p. 4

C. Hash Function

  • The hash-function model assumes collision resistance: it should be computationally infeasible to find distinct inputs with the same hash.The mission signature uses a domain-separation tag and canonical mission encoding.Source: C. Hash Function · p. 4

D. Robot State, Actions, and Traces

  • A robot trace records alternating states and actions from an initial state, and it is executable when no state transition yields ⊥.Each state follows from applying the transition function to the preceding state and action.Source: D. Robot State, Actions, and Traces · p. 4

E. Safety and Authorization Policies

The paper separates physical safety from mission authorization: actions are checked against both a safety predicate and a state- and time-dependent mission policy. It also uses provenance labels and a weighted deviation measure to characterize changes to protected mission fields.

E. Safety and Authorization Policies

  • Safety and authorization are separate predicates, so an action may satisfy one and fail the other.The safety predicate evaluates an action in a state; the mission policy specifies authorized actions by state and time.Source: E. Safety and Authorization Policies · p. 4

F. Provenance Labels

  • Provenance labels record where values entered the system, and only authenticated operator or supervisor sources normally may change privileged mission fields.Camera, audio, retrieval, memory, and model outputs may inform planning but cannot modify mission authority.Source: F. Provenance Labels · p. 4

A. Motivating Scenario

  • A camera notice redirecting a medicine delivery from Station 101 to Station 103 can produce a safe route that remains unauthorized because the destination was signed as Station 101.The system may stop, seek operator clarification, or accept a separately signed update, but the LLM must not convert observed text into authority.Source: A. Motivating Scenario · p. 5

B. Mission-Deviation Function

  • The action-level mission-deviation score weights violations of protected fields, and the plan-level score uses the maximum because one unauthorized action suffices to violate the mission.A deviation score of zero means every protected field is compliant; experiments may also report an average.Source: B. Mission-Deviation Function · p. 5

C. Safety-Compliant Mission Hijacking

Safety-compliant mission hijacking is an executable, safety-accepted plan that nevertheless violates the authenticated mission. The paper describes attack categories and an architecture in which a signed mission token and separate authorization and safety gates constrain execution.

C. Safety-Compliant Mission Hijacking

  • A safety-compliant mission-hijacking plan is executable and accepted by the safety model, but has at least one action outside the authenticated mission.This captures a mission violation without requiring an obviously dangerous action.Source: C. Safety-Compliant Mission Hijacking · p. 5

D. Attack Categories

  • Attack categories include goal or object substitution, area or parameter escalation, unauthorized capabilities, cross-robot token use, availability manipulation, and provenance confusion.A single attack may combine multiple violations, which the evaluation records by field.Source: D. Attack Categories · pp. 5–6

A. Entities

  • The planner proposes plans, a normalizer preserves field provenance, and separate authorization and safety gates must both accept before actions reach the controller.The robot identity and trusted enforcement path are part of the stated system architecture.Source: A. Entities · p. 6

B. Mission Token

  • A mission token binds the mission to a robot and specifies permitted actions, objects, regions, limits, state guards, expiry, nonce, approval policy, and schema version.The user signs a domain-separated encoding of the structured mission.Source: B. Mission Token · p. 6

C. Normalized Actions

AuthGuard-R maps planner outputs into a common action schema and checks each action against the signed mission policy. The model and unauthenticated inputs remain untrusted, and authorization depends on robot, scope, state, time, and provenance checks.

C. Normalized Actions

  • AuthGuard-R normalizes differing planner outputs into a common action schema so the core authorization policy is independent of the planner and robot.Adapters translate formats such as JSON tool calls, Python code, and ROS 2 commands.Source: C. Normalized Actions · p. 6

D. Authorization Predicate

  • An action is authorized only when every mandatory mission field matches, including robot identity, active time, allowed action and tool, object and location scope, numeric bounds, state guards, and provenance.The predicate can also return a reason code and evidence for audit and recovery.Source: D. Authorization Predicate · pp. 6–7

E. Adversary Capabilities

  • The adversary may control unauthenticated input channels and the planner, adapt to accept or reject decisions, and replay tokens or target the wrong robot, but cannot compromise specified trusted components or signing keys.Attacks below the trusted state estimator, physical key extraction, malicious authorized operators, and trusted-gate compromise are outside the main proof model.Source: E. Adversary Capabilities · p. 7

F. Security Goals

The security goals constrain execution to the signed mission and require each executed action to satisfy both mission and safety policies. MissionPAIR searches for executable, safety-compliant plans that violate that mission under different attacker knowledge settings.

F. Security Goals

  • Authorization soundness requires every accepted action to belong to the policy derived from a valid signed mission in the current state and time.The complementary completeness goal accepts well-formed actions that satisfy every signed condition.Source: F. Security Goals · p. 7
  • The system also specifies mission non-escalation, replay resistance, robot binding, provenance separation, threshold-approval integrity, audit-log tamper evidence, and trace composition.Trace composition requires every executed action to satisfy both mission and safety policies at execution time.Source: F. Security Goals · p. 7

A. Constrained Attack Objective; B. Attack Procedure

  • MissionPAIR seeks an executable plan that violates a protected mission field while passing the safety gate; deterministic execution, safety, and mission checkers determine success.Its procedure returns success only when the plan is executable, accepted by the safety gate, and has a positive mission-deviation score.Source: A. Constrained Attack Objective · p. 7, B. Attack Procedure · p. 8

C. Adaptive Attacker Models

  • Black-box, grey-box, and white-box attacker settings vary how much the attacker knows about the schema, policy, gate order, reason codes, and score.White-box evaluation tests enforcement without relying on secrecy of the verification algorithm.Source: C. Adaptive Attacker Models · p. 8

D. Attack Templates

The design treats the planner as an untrusted proposer and separates mission authorization from physical safety. It uses authenticated, scoped missions and stateful checks to assess actions and their provenance.

D. Attack Templates

  • MissionPAIR instantiates destination-change, object-relabeling, privacy-escalation, false-emergency, and route-expansion templates across multiple delivery channels.The paired benchmark contrasts unauthenticated changes with otherwise identical authenticated mission updates.Source: D. Attack Templates · p. 8

A. Design Principle

  • The planner may propose actions, but only an authenticated principal may define or change execution authority; observations cannot replace signed mission instructions.Least-authority missions grant only the task-needed actions, objects, regions, tools, parameters, and time, with clarification or a signed update when information is insufficient.Source: A. Design Principle · pp. 8–9

B. Architecture

  • The independent authorization and safety gates produce separate decisions, so a physically safe plan is not automatically treated as authorized.Authorization is placed first to avoid safety analysis of already unauthorized actions, though the reverse order is also possible.Source: A. Design Principle · p. 9, B. Architecture · p. 9, Figure 1 · p. 9

C. Mission Compilation and Clarification

  • The mission compiler structures and validates the operator request, then records the confirmed canonical mission with a version, fresh nonce, and signature.Ambiguous privileged fields require clarification before signing.Source: C. Mission Compilation and Clarification · p. 9

D. Provenance Policy

  • A proposed destination sourced from camera text rather than the signed mission fails the destination check, with provenance carried into the normalized action and audit record.The example provenance policy is summarized in Table II.Source: D. Provenance Policy · p. 9, Table II · p. 9

E. Stateful Action Verification

  • The registry tracks mission status and may track step counts, while the verification procedure checks token validity, expiry, revocation, robot identity, action authorization, and required approval before accepting.After acceptance, it updates mission state and appends an audit record.Source: E. Stateful Action Verification · p. 9, F. Risk-Adaptive Approval · p. 10

F. Risk-Adaptive Approval

  • Approval requirements vary with deployment-specific action risk, and the risk policy is authenticated so the planner cannot lower the risk class by re-describing an action.Approvals bind to the mission version and exact action scope; high-risk examples can require threshold approval.Source: F. Risk-Adaptive Approval · pp. 9–10

G. Hash-Chained Audit Record

AuthGuard-R records decisions in a hash chain and specifies authorization completeness alongside games for authorization bypass and replay. The guarantees depend on stated checking and persistent-state assumptions, and the audit log is not designed to provide confidentiality.

G. Hash-Chained Audit Record

  • Each decision record includes an evidence digest with mission version, provenance labels, gate reason code, and safety decision; changing an earlier record changes every later digest.Hash chaining alone does not prevent deletion of the whole log or replacement with a new chain; periodic signing or external anchoring addresses this gap.Source: G. Hash-Chained Audit Record · p. 10
  • The audit log is designed for integrity and accountability, not confidentiality, and may contain sensitive locations, object identifiers, or sensor evidence.The implementation should encrypt protected fields, restrict access by role, and retain only investigation-relevant evidence.Source: G. Hash-Chained Audit Record · p. 10

H. Authorization Completeness

  • Authorization completeness states that a valid, fresh, active token for the matching robot is accepted when the action is authorized and all required approvals are valid.The result follows from the deterministic control flow of Algorithm 2.Source: H. Authorization Completeness · p. 10

A. Authorization-Bypass Game

  • The authorization-bypass game counts a win if the gate accepts either an unsigned mission or an action outside the policy of a validly signed mission.The cryptographic case relies on signature unforgeability and collision resistance, while the enforcement case assumes a correct deterministic policy checker.Source: A. Authorization-Bypass Game · pp. 10–11

B. Replay Game

  • The replay game counts a win when a completed, revoked, or expired mission instance is accepted again; its resistance assumes the registry does not silently roll back.Stable storage, monotonic counters, or a trusted remote checkpoint support that assumption.Source: B. Replay Game · p. 11

C. Cross-Robot Game

The section defines security games for cross-robot token reuse, provenance confusion, and audit tampering, then proves authorization soundness under cryptographic and policy-checker assumptions.

C. Cross-Robot Game

  • Cross-robot rejection is tested by giving R1 a valid token and checking whether R2 can accept an action under it.The token binds a signed robot identifier to trusted local identity; a network-provided name can be rewritten, and platforms with similar interfaces may have different capabilities.Source: C. Cross-Robot Game · p. 11

D. Provenance-Confusion Game

  • Provenance-confusion wins only if an unauthorized source changes a privileged field in the policy used for acceptance without a newly authenticated update.The experiment distinguishes a planner merely mentioning a changed value from that value actually affecting the authorization policy.Source: D. Provenance-Confusion Game · p. 11

E. Audit-Tampering Game

  • Audit tampering wins when a modified log verifies against the same external anchor, while collision resistance and unambiguous encoding make success negligible.The experiment permits changing, deleting, inserting, reordering, or truncating records; it assumes the trusted gate creates records correctly and does not guarantee complete logging or secrecy.Source: E. Audit-Tampering Game · p. 11

A. Authorization Soundness

  • A successful authorization bypass yields a signature forgery or hash collision, so its advantage is negligible under the stated assumptions.The theorem assumes EUF-CMA security, collision resistance, and a correct deterministic policy checker; it proves enforcement of the signed policy, not that the policy is sensible.Source: A. Authorization Soundness · pp. 11–12

B. Mission Non-Escalation

AuthGuard-R fixes the permitted action set to the verified mission and proves protections against replay, cross-robot use, provenance changes, and unauthorized high-risk approvals.

B. Mission Non-Escalation

  • Every accepted action remains within the action set derived from the verified mission, so planner text cannot enlarge that set.If every action in a plan passes the gate, the complete execution trace is authorized.Source: B. Mission Non-Escalation · p. 12

C. Replay Resistance

  • Replay succeeds with probability zero in the ideal model when the gate persistently marks completed, revoked, or expired mission tokens as unusable.If the registry can roll back after a crash, replay resistance requires stable storage, monotonic counters, or a trusted remote checkpoint; a random nonce alone is insufficient.Source: C. Replay Resistance · p. 12

D. Robot Binding

  • A token signed for R1 is rejected by R2 when the trusted local identity check detects the mismatch.Robot binding also guards against capability escalation between platforms with similar action interfaces but different strength, payload, sensors, or privileges.Source: D. Robot Binding · p. 12

E. Provenance Separation

  • Sources outside a field’s authorized provenance labels cannot change its effective value without a newly verified mission token.Untrusted inputs may affect the planner proposal, but the gate derives policy from the latest verified token and continues enforcing this separation across input events.Source: E. Provenance Separation · pp. 12–13

F. Threshold-Approval Security

  • An adversary controlling fewer than t signing authorities has negligible probability of passing approval for an unauthorized high-risk action.The approval binds the mission, action, state summary, expiry, and counter, so replaying an earlier approval fails the freshness checks.Source: F. Threshold-Approval Security · p. 13

G. Audit-Log Tamper Evidence

The section proves that an externally anchored hash chain detects committed-log tampering and that the authorization and safety gates jointly preserve both properties across executed traces.

G. Audit-Log Tamper Evidence

  • An efficient adversary can modify committed records while preserving the same externally anchored terminal digest only with negligible probability under the stated hash assumptions.The result covers modifications, insertions, deletions, and reordering; it relies on collision resistance, second-preimage resistance, and an external anchor for the log prefix.Source: G. Audit-Log Tamper Evidence · p. 13

H. Dual-Gate Trace Composition

  • A trace produced by the controller is both authorized under the mission and safe when each action passes both sound gates.The composition is proved by induction over executed actions; a mission-hijacking plan with an out-of-policy action is not executed.Source: H. Dual-Gate Trace Composition · p. 13

I. Scope of the Proofs

  • The proofs assume normalized actions match physical effects and trusted state is accurate; parser or localization errors can undermine that correspondence.The safety-composition result is conditional on the selected safety gate, and the threshold proof assumes independent, securely stored approval keys; an authorized operator can still sign a harmful mission.Source: §I · pp. 13–14

A. Per-Mission and Per-Action Cost

  • Per-action authorization cost can be reduced by verifying the mission token once, caching it in protected memory, and checking freshness before each action.Most set-membership, range, and equality predicates have expected constant lookup cost with hashed identifiers; state predicates may require costlier geometric or symbolic checks.Source: A. Per-Mission and Per-Action Cost · p. 14

B. End-to-End Latency

The section specifies latency, storage, approval, and failure-policy measurements, then describes a prototype and an evaluation designed to test mission hijacking while separating security from utility.

B. End-to-End Latency

  • Decision latency sums normalization, verification, policy checking, approval, audit, and safety-gate time, while LLM planning time is reported separately.A secure active-mission cache can avoid full signature verification on every action; evaluation should report cold-start and steady-state latency, including median, 95th-, and 99th-percentile times under benign and attack load.Source: B. End-to-End Latency · p. 14

C. Token and Log Size

  • Token size grows with mission scope, while audit-log growth is linear in the number of decisions when complete actions and selected evidence are stored.Compact identifiers can reduce token size; for large sensor objects stored elsewhere, records can retain content digests and protected references. Post-quantum signatures can increase token size, particularly relevant to low-bandwidth links and long certificate chains.Source: C. Token and Log Size · p. 14

D. Threshold Approval Cost

  • Threshold approval adds cryptographic work and coordination, and supervisor response time may dominate cryptographic delay.Experiments should separate machine processing from approval waiting time; broad reusable approval would weaken least-authority design.Source: D. Threshold Approval Cost · p. 14

E. Failure Policy

  • Fail-closed checks can reduce availability when the gate, clock, or network is unavailable, so emergency actions use a separate narrowly guarded policy.The authorization node must remain on the mandatory actuation path; raw LLM actions should not execute as a fallback if it crashes.Source: E. Failure Policy · pp. 14–15

A. Prototype, Execution Path, and Evaluation Criteria

  • Evaluation uses six planner-level attack categories and separate protocol attacks, while measuring attack outcomes and benign completion to distinguish security from utility.Adaptive MissionPAIR revises injections using the target planner’s prior response; a refusal is not counted as a defense success, and blocked results are conditional on the planner producing an unauthorized action.Source: §XI · p. 15, A. Prototype, Execution Path, and… · p. 15
  • The prototype signs a canonical mission token and sends typed LLM actions through AuthGuard-R and an independent safety gate before execution.The implementation includes provenance labels, persistent mission state, replay checks, robot binding, risk-adaptive approval, and a hash-chained audit log; the ROS 2 design places enforcement between planner and action server.Source: A. Prototype, Execution Path, and… · p. 15

B. Controlled Validation: Is Safety Alone Sufficient?

The controlled suite distinguishes physical safety from mission authorization, then tests whether LLM planners produce unauthorized actions and whether AuthGuard-R rejects them. Across the live trials, planner susceptibility varied, but every observed mission-violating output was rejected; the authors note that these preliminary results depend on correctly encoded policies and faithful action normalization.

B. Controlled Validation: Is Safety Alone Sufficient?

  • In the controlled suite, safety-only and no-defense configurations had UASR = 1 and SCMHR = 1, while the dual gate reduced both to zero and preserved all seven benign controls.BTCR remained 1 and FRR remained 0 with AuthGuard-R; the supplementary SU score rose from 0 to 1.Source: Table III · p. 16, B. Controlled Validation: Is Safety… · p. 16

1) Claude Haiku 4.5:

  • Claude Haiku 4.5 followed fixed-template mission changes in 11 of 60 trials (18.3%), and AuthGuard-R rejected all 11 unauthorized actions.Object substitution succeeded in all ten seeds; the other five categories produced one or zero mission-violating outputs.Source: 1) Claude Haiku 4.5 · p. 16, Table V · p. 17
  • Adaptive MissionPAIR produced 12 mission-violating Claude outputs in 60 trials (20.0%), including goal substitution and provenance confusion; AuthGuard-R rejected all 12.Across fixed and adaptive Claude experiments, the planner produced 23 mission-violating actions, all rejected by the gate.Source: 1) Claude Haiku 4.5 · pp. 16–17, Table VI · p. 17

2) Qwen2.5 7B:

  • Qwen2.5 7B followed fixed-template mission changes in 50 of 60 trials (83.3%), and AuthGuard-R rejected all 50 unauthorized actions.Five of six tested categories succeeded in all ten seeds; capability escalation produced no compliant output.Source: Table VII · p. 17, 2) Qwen2.5 7B · p. 17
  • Adaptive MissionPAIR produced 36 mission-violating Qwen2.5 7B outputs in 60 trials (60.0%), all rejected by AuthGuard-R.The adaptive rate was lower than the fixed-template rate, and the two procedures produced different distributions of attack successes.Source: Table VIII · p. 17, 2) Qwen2.5 7B · p. 17

D. Cross-Model Interpretation and Significance

  • The four live experiments show sharply different planner compliance rates, while the authorization result remained stable for every observed unauthorized output.The blocked counts are conditioned on the planner producing a mission-violating action, so model refusals are not credited to AuthGuard-R.Source: D. Cross-Model Interpretation and… · pp. 17–18, Table IX · p. 18
  • 109 of 240 live attack trials produced mission-violating planner outputs, and AuthGuard-R rejected all 109; the combined 120 instantiated attacks were also rejected.The 120 total includes eleven hand-constructed protocol- and policy-level attacks; the result is not a universal security claim.Source: D. Cross-Model Interpretation and… · pp. 17–18, Table IX · p. 18

XII. CONCLUSION

  • The evaluation is preliminary: formal claims depend on stated assumptions, and mission construction, action normalization, trusted state, and an uncompromised gate remain boundaries of the implementation.A full simulator or ROS 2 execution loop and benchmark reproduction remain future work.Source: D. Cross-Model Interpretation and… · p. 18, §XII · p. 18
Loading 2609.31110v1…