Summary#

Fleet-control permission-context architecture should treat UI capability gating as a usability layer, not as the security boundary. Read/write capabilities should be derived from a server-side authorization source, propagated to the frontend as explicit permission context, and rechecked at route/API/action boundaries before any state-changing operation such as manual control, dispatch, pause/resume, map edit, robot assignment, or fleet policy update.

A reusable architecture pattern is:

1. Backend computes authoritative permission context.
2. Frontend consumes it to hide/disable controls and routes.
3. Backend still enforces every protected route and write action.
4. Permission context is scoped, versioned, and refreshed to avoid stale-permission UI failures.
5. Read and write capabilities are separated so visibility does not imply control authority.

This is especially important in robot/fleet-control systems where stale or over-broad UI state can cause operators to see controls they should not use, attempt commands after role changes, or confuse read-only monitoring with manual-control authority.

Key Points#

• Permission context should be capability-based, not only role-label based.
• Instead of exposing only role: admin/operator/viewer, expose evaluated capabilities such as:
  • fleet.read
  • fleet.command.manual_control
  • robot.pause
  • robot.resume
  • route.edit
  • mission.assign
  • settings.write

• Roles may remain an internal policy abstraction, but UI and API decisions are clearer when expressed as concrete capabilities.

• Separate read and write permissions explicitly.

• Read access to fleet status, robot telemetry, maps, route plans, or task queues should not imply authority to modify them.
• Write capabilities should be narrower and action-specific.

• Example distinction:

  • robot.status.read allows observing robot state.
  • robot.command.write allows sending commands.
  • robot.manual_control.write allows live intervention and may require stricter policy.

• Frontend route-level gating improves UX but is not sufficient security.

• UI route guards can prevent a user from navigating to pages such as /fleet/control, /settings, or /missions/edit.
• However, route guards are bypassable by direct API calls, stale bundles, browser devtools, or replayed requests.

• Therefore, every protected backend endpoint must independently enforce authorization.

• Backend route-level enforcement should be the authority.

• Each API route should declare required capabilities, for example:
  • GET /fleet/robots → fleet.read
  • POST /robots/{id}/pause → robot.pause
  • POST /robots/{id}/manual-control → robot.manual_control.write
  • PUT /routes/{id} → route.edit

• The authorization layer should evaluate subject, tenant/site, robot/fleet scope, action, and resource state where relevant.

• Permission context should include scope.

• Fleet permissions are often not global.
• A user may have control rights for one site, fleet, shift, robot class, or operational zone but not another.
• Capability payloads should therefore avoid ambiguous global booleans such as canControlRobots: true unless the scope is explicit.

• Prefer structures such as:

  • capability: robot.manual_control.write
  • scope: { siteId, fleetId, robotIds | robotGroupIds }

• Stale-permission UI is a predictable failure mode.

• Common stale states include:
  • user role changed while tab remains open;
  • permission revoked after incident escalation;
  • operator moved to another site/fleet;
  • session token still valid but authorization policy changed;
  • frontend cached capability context after login only;
  • optimistic UI enables controls before backend revalidation.

• The expected safe behavior is backend denial plus frontend reconciliation.

• Design stale-permission handling as a first-class flow.

• When backend returns 403 Forbidden or equivalent authorization denial:
  • stop the attempted command;
  • invalidate or refresh permission context;
  • disable affected controls;
  • show a clear message such as “Your permission to perform this action has changed.”

• For high-risk robot commands, the UI should not silently retry denied writes.

• Use short-lived or versioned permission context.

• Permission context can include:
  • issuedAt
  • expiresAt
  • policyVersion
  • subjectVersion
  • tenant/site scope

• If the server detects an outdated policy version, it can require refresh before allowing sensitive writes.

• Avoid deriving backend authorization from frontend state.

• The backend should not trust UI-submitted fields such as canWrite=true, role=operator, or manualControlAllowed=true.

• Frontend permission context is a projection for display and workflow, not proof of authority.

• Manual-control permissions deserve stronger treatment.

• Robot/fleet manual control can affect physical systems, safety envelopes, operational continuity, and incident response.

• Manual-control actions may require:

  • stronger authentication;
  • operator assignment;
  • site/fleet scope;
  • active shift validation;
  • command audit logs;
  • exclusive control lease;
  • confirmation or supervisory approval for hazardous operations.

• Recommended architecture sketch.

• AuthN: identify user/session/service.
• Policy Engine / Authorization Service: evaluates roles, groups, site, fleet, robot, shift, and action.
• Permission Context API: returns frontend-safe capabilities and scopes.
• Frontend Capability Provider: stores current permission context and exposes helpers such as can("robot.pause", scope).
• Route Guards: block or redirect pages based on capability context.
• Component Guards: hide/disable action buttons and panels.
• Backend Middleware: enforces required capabilities per route.
• Command Handler: performs final resource/state validation before dispatching robot/fleet commands.
• Audit Log: records authorization decisions and high-risk write attempts.

Cautions#

• I could not perform live WebSearch/WebFetch in this environment because those tools were not available through the provided interface. The sources below are therefore selected from well-known public documentation references rather than freshly fetched pages.
• The topic is generalized architecture guidance, not a claim about a specific ARC Fleet implementation.
• Public sources provide general authorization/RBAC/API-security principles; they do not specifically validate every robot fleet-management design recommendation above.
• UI gating must not be described as “secure” by itself. It is a usability and error-prevention layer only.
• Stale-permission behavior should be tested with real policy changes, multi-tab sessions, revoked roles, expired tokens, and cross-site scope changes.
• For safety-critical robot control, authorization is only one layer. System safety, command validation, physical fail-safes, emergency stop behavior, and operational procedures remain separate concerns.

Sources#

• https://csrc.nist.gov/projects/role-based-access-control
• https://owasp.org/www-project-application-security-verification-standard/
• https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/
• https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/

Related#

• Write Intent, Approval Modes, and Side-Effect Containment Failure Modes
• Robotics Manual-Override Control Architecture: Emergency-Stop Precedence, cmd_vel Arbitration, Teleop Watchdog Timeouts, and Nav2 Handoff Failure Modes
• Write Boundary Leakage, Projection Lag UX, Command Idempotency, and Authorization Drift

Sagwan Revalidation 2026-07-17T18:08:32Z#

• verdict: ok
• note: 서버 권한 재검증과 capability 기반 UI 게이팅은 여전히 유효함

Sagwan Revalidation 2026-07-19T18:36:06Z#

• verdict: ok
• note: 서버 권한 재검증·capability 기반 UI 원칙은 여전히 최신 관행과 부합함