Position: Embodied AI Requires a Privacy-Utility Trade-off¶

Conference: ICML 2026
arXiv: 2605.05017
Code: https://github.com/rminshen03/EAI_Privacy_Position
Area: AI Safety / Embodied Intelligence / Privacy Protection
Keywords: embodied AI, privacy-utility trade-off, SPINE framework, lifecycle privacy, hierarchical control

TL;DR¶

This position paper argues that privacy in embodied AI cannot be addressed by single-stage patches, but must be treated as an architectural, dynamic control signal spanning the entire lifecycle—across instruction, perception, planning, and interaction. The SPINE framework is proposed, leveraging an L1-L4 four-level privacy classification matrix to coordinate agent behavior at each stage.

Background & Motivation¶

Background: Embodied AI (EAI) is rapidly transitioning from simulation to real-world environments such as homes, hospitals, and offices. Existing research mainly optimizes task success rates within each stage: instruction understanding, environment perception, action planning, and physical interaction.

Limitations of Prior Work: Current privacy protection in EAI is almost entirely stage-local—e.g., face blurring in perception, or adding noise in planning. However, (1) these patches are often "reversed" downstream; for example, even if faces are anonymized at the perception layer, planning logs may record precise action patterns (e.g., medication retrieval), allowing inference of conditions like Parkinson's disease. (2) The privacy-utility trade-off is a nonlinear safety constraint; aggressive planning restrictions not only reduce efficiency but may directly cause robots to collide with walls or people.

Key Challenge: Privacy in EAI is inherently a cross-stage, temporally cumulative property, yet current architectures treat it as a locally controllable feature at each stage. Legally, only high-level principles like GDPR/CCPA exist, lacking actionable guidance for "embodied closed loops," resulting in a gap between technology and regulation.

Goal: (1) Argue why privacy must be treated as a lifecycle-level architectural constraint; (2) Design a unified framework that propagates privacy constraints consistently across stages and dynamically adjusts the trade-off in different contexts; (3) Provide real case studies as preliminary evidence of how privacy reshapes downstream utility.

Key Insight: The authors use embodied navigation as a controlled probe, since navigation naturally couples all four stages, allowing controlled observation of "upstream strong privacy → downstream utility changes," making the trade-off a quantifiable engineering relationship.

Core Idea: Upgrade privacy from a "local patch" to a "dynamic control signal," using a four-level privacy classification matrix and cross-stage orchestration to realize a "context-aware" privacy architecture.

Method¶

Although this is a position paper, it proposes a complete conceptual framework, SPINE, along with two case studies, which can be regarded as methodological contributions.

Overall Architecture¶

SPINE consists of three components: (1) An L1-L4 four-level privacy classification matrix mapping any scenario to a privacy level; (2) A conceptual architecture diagram arranging the four stages (Instruction / Perception / Planning / Interaction) × four levels (L1-L4) into a 4×4 matrix, specifying the technical primitives to activate in each cell; (3) A cross-stage orchestration strategy defining the "highest-triggering-criterion" rule—once any stage reaches a higher-level constraint, the entire pipeline is immediately upgraded, with quantitative analysis of utility degradation.

Key Designs¶

Multi-criteria Privacy Classification Matrix (L1-L4):
- Function: Uses a unified tuple \(PL = \{S, I, C, \Phi\}\) to describe each privacy state, where \(S\) is scenario context, \(I\) is permitted information flow, \(C\) is the enforced control primitive, and \(\Phi\) is the dominant utility objective. L1 (Public, e.g., parks) allows cloud inference and full sensing, \(\Phi\) = max utility; L2 (Internal, e.g., office corridors) allows mixed information flow, removes biometric features but retains geometry; L3 (Confidential, e.g., private offices) uses local processing, semantic desensitization, and privacy-aware rerouting; L4 (Restricted, e.g., bedrooms/bathrooms) retains only minimal safe functionality, uses LiDAR instead of RGB, and TEE container isolation.
- Mechanism: Replaces the traditional "public vs private" dichotomy with four levels and a four-tuple encoding scenario, information flow, control primitive, and utility objective, clarifying that high-cost primitives (FHE/ZKP) are triggered only at L4 when necessary, avoiding unnecessary performance loss.
- Design Motivation: Cross-stage consistency requires a shared "privacy state machine" so each stage can select matching technical primitives based on the current level; binary classification is too coarse to distinguish between, for example, bedrooms and private offices with different sensitivities.
Adaptive Privacy Orchestration:
- Function: Defines what instruction, perception, planning, and interaction should do under L1-L4. For example, in perception: L1 uses full FoV RGB-D, L2 applies real-time face/license plate anonymization, L3 dynamically masks non-task areas and restricts field of view, L4 switches from RGB to LiDAR. In planning: L1 uses shortest path, L2 plans on de-identified semantic maps, L3 introduces a "privacy cost map" with higher traversal penalties in private areas, L4 retains only minimum viable navigation.
- Mechanism: Employs the "highest-triggering-criterion" rule—if any stage triggers a higher-level constraint, the entire pipeline upgrades until the condition is lifted or a manual audit occurs. This prevents downstream reversal and ensures end-to-end privacy constraint enforcement.
- Design Motivation: Completely breaks the limitation of stage-local patches—once a sensitive scenario is detected (e.g., entering a bedroom), not only does the perception module anonymize, but planning and logging also switch to L4 mode, preventing any downstream leakage.
Threat Model + Quantification of Privacy-Utility Boundary:
- Function: Identifies three adversary types—honest-but-curious cloud providers, compromised storage/insiders, and external/overprivileged observers; quantifies the trade-off as a function of utility degradation and privacy strength. In the case study, navigation task uses \(K\) (pixelation strength) as the trade-off knob: \(K=1\) corresponds to L1, \(K>1\) progressively to L3, allowing measurement of task success rate decline as \(K\) increases.
- Mechanism: Grounds the abstract "trade-off" in a concrete, tunable parameter, defining the "operational boundary"—beyond a certain \(K\), the task fails completely, marking the enforceable upper bound of privacy for that scenario.
- Design Motivation: Slogans like "balance privacy and utility" do not guide engineering; quantifiable relationships are necessary for product managers and engineers to make deployment choices in different contexts.

Loss & Training¶

As a position + framework paper, there is no end-to-end training objective. The case study uses existing EAI simulators and real robots, recording navigation success rates and path lengths under different \(K\) to form trade-off curves.

Key Experimental Results¶

As a position paper, this work provides conceptual validation rather than comprehensive experimental comparison.

Main Results¶

A comparison of SPINE and stage-local patches using the four-stage × four-level conceptual architecture:

Privacy Level	Typical Scenario	Instruction	Perception	Planning	Interaction
L1 Public	Park	Cloud LLM	Full FoV RGB-D	Shortest path	Complete logs
L2 Internal	Office corridor	Local logs	Real-time face/license plate anonymization	De-identified semantic map planning	Standard latency, desensitized storage
L3 Confidential	Private office	Local semantic desensitization	Restricted FoV + dynamic mask	Privacy cost map + rerouting	Session-only encrypted logs
L4 Restricted	Bedroom/Bathroom	TEE processing	Switch RGB to LiDAR	Minimum viable navigation	Trace-free ephemeral execution

Ablation Study¶

The paper uses a navigation case study to observe task success rate and path length degradation under different pixelation strengths \(K\):

Configuration	Privacy Level	Task Success Rate	Path Length	Notes
\(K=1\) Original	L1	High baseline	Short baseline	No privacy constraint
\(K\) Moderate	L3	Moderate drop	Slight increase	Partial semantic loss but still feasible
\(K\) High	L4 boundary	Significant drop	Large increase	Near operational boundary
Beyond boundary	Infeasible	Failure	Unreachable	Task cannot be completed

Key Findings¶

Stage-local privacy patches are reversed downstream: after face anonymization in perception, action patterns in planning logs can still infer identity or health status, indicating the necessity of a lifecycle perspective.
The privacy-utility relationship is nonlinear, with an "operational boundary"—beyond a certain privacy strength, tasks fail outright; this threshold is critical for deployment decisions.
Fixed privacy strategies may work in the lab but often fail in real deployments due to lack of context-adaptive adjustment, highlighting the need for dynamic classification mechanisms.

Highlights & Insights¶

Framing "privacy as a dynamic control signal" elevates privacy from a compliance issue to a system control problem, enabling seamless integration with control theory and safety filters—a highly generative conceptual migration.
The L1-L4 four-tuple \(\{S, I, C, \Phi\}\) provides a formalizable carrier for privacy grading, far superior to the industry's common "sensitive/non-sensitive" dichotomy, and can directly guide SDK design.
The highest-triggering-criterion rule draws from priority inheritance in real-time systems; it is simple yet thoroughly resolves inter-stage responsibility shifting—once a higher level is triggered, the entire pipeline must upgrade.
Using navigation as a controlled probe to quantify the trade-off is clever, as navigation naturally couples all four stages and utility metrics (success rate, path length) are mature, making the approach reusable for privacy evaluation in other EAI sub-tasks.

Limitations & Future Work¶

The framework remains conceptual; the case study only covers navigation and home pixelation, lacking coverage of more complex scenarios such as manipulation robots or medical assistance.
The specific thresholds for L1-L4 grading and who defines them are not clarified; there is a risk that more levels lead to more conservative settings and worse utility, necessitating principled grading algorithms rather than manual tuning.
The highest-triggering-criterion may cause "privacy level locked at L4" in concurrent multi-tasking, requiring a release mechanism and refined audit log design.
Although heavy primitives like FHE/ZKP are mentioned, computational budget analysis is lacking; in practice, these often become system bottlenecks.

vs Pape et al.'s prompt obfuscation: Their work focuses on privacy obfuscation in single-turn LLMs; this paper extends the perspective to the full embodied AI loop, emphasizing the systemic issue of "upstream masking, downstream reversal."
vs Legal compliance frameworks (GDPR/CCPA): Legal frameworks provide principles but not stage-specific operational guidance; this paper uses a four-level matrix to map high-level compliance principles to concrete technical primitives at each EAI stage.
vs Classical differential privacy: DP offers mathematical guarantees but is oriented toward data release; this paper emphasizes real-time, context-aware strategy switching during deployment, better aligning with embodied agent needs.

Rating¶

Novelty: ⭐⭐⭐⭐ The "lifecycle privacy as control signal" framing is an early systematic attempt in embodied AI literature.
Experimental Thoroughness: ⭐⭐⭐ Only navigation + pixelation cases; lacks diverse validation in manipulation/medical domains.
Writing Quality: ⭐⭐⭐⭐ Clear structure, progressing smoothly from problem → grading → orchestration → case.
Value: ⭐⭐⭐⭐ Provides a blueprint for privacy architecture design in embodied robots and home service agents.