Tauri Native Boundary and Command Mediation

1. The problem: a generic command erases the trust boundary

Assume a desktop UI needs three native actions: inspect worker status, rotate a local credential, and request a controlled restart. If all three are routed through admin_action(name, payload), operation identity, input validation, authorization, resource scope, native effect, and audit become one opaque tunnel. The short-term API is convenient, but it becomes difficult to answer a basic review question: exactly which webview was allowed to cause which native effect, for which node, with which validated input? LOC-002 exists to keep that answer explicit.

2. The owned LOC-002 boundary

This lesson owns command mediation, not the capability/CSP matrix. LOC-003 controls which windows or webviews receive Tauri permissions and scopes; LOC-002 controls what happens once an invocation is eligible to reach an application command. Human identity and device identity are also not re-proven here. Actor and node identifiers must bind to prior evidence rather than being inferred from a UI label.

3. What a Tauri command actually provides

In Tauri v2, a Rust function can be exposed with #[tauri::command], registered in a builder with invoke_handler(tauri::generate_handler![...]), and called from the frontend with invoke(...). Arguments and results use Serde-compatible types. Those mechanics establish an invocation path. They do not, by themselves, establish application-level authorization or semantic safety of a particular request.

4. What runtime authority does before the command body

Tauri runtime authority evaluates whether the calling origin is allowed to use the requested command and applies relevant capability, permission, and scope information before invocation. If the origin is not allowed, the request is denied and the command body is not invoked. That framework boundary is necessary, but it does not replace MAKNOW domain authorization. A window may be technically allowed to reach rotate_local_credential while the current actor is still not allowed to rotate credentials for node-42.

5. One sensitive operation, one narrow command

Replace admin_action(name, payload) with explicit commands such as inspect_worker_status, rotate_local_credential, and request_controlled_restart. A command name should make intent and side-effect class obvious. Each command owns its input contract and only the resources required by that use case. When a fourth operation is needed, add a fourth contract rather than extending an action string inside a privileged dispatcher.

6. Type safety still needs semantic validation

A String node identifier is only a type check. The command still needs to confirm that the node belongs to the actor's allowed scope, a credential version is valid and current, a restart reason belongs to the accepted set, and a resource key does not escape its boundary. Keep schema validation distinct from semantic/domain validation and return deterministic typed errors instead of collapsing all failures into false or an ambiguous message.

7. Do not confuse domain authorization with a Tauri permission

A Tauri permission can expose a command or technical scope to a frontend context. Domain authorization decides whether the current actor, node, policy, and request may perform the business operation. These checks are independent. A defensible PASS requires the runtime-authority gate, validated input, domain authorization, and bounded resource scope to agree for the same request.

8. Re-bind resource scope close to the native effect

Native operations should not accept arbitrary paths, processes, credential targets, or cache keys. If rotate_local_credential owns only credential/node-42/*, a request for credential/global/root must be blocked even when a broader upstream Tauri permission would technically let the frontend reach the command. The domain scope lives close to the native effect so a configuration mistake above it cannot become a generic escape hatch.

9. Managed state is a dependency, not authority by itself

Tauri can inject managed state into commands, which is useful for repositories, sessions, caches, or policy snapshots. The presence of State<T> does not prove that state is current or authoritative. A sensitive command still needs provenance and freshness rules, and states such as STALE, REVOKED, or UNBOUND must remain non-success states instead of being silently upgraded.

10. State-changing commands need idempotency

A UI can double-click, a promise can time out, or a reconnect can replay a request. If credential rotation or restart creates another effect on every invocation, retries can multiply side effects. Bind request_id and an idempotency_key to actor, node, operation, and content. When the same content-bound request has already completed, return the traceable prior outcome without creating a second effect.

11. Audit both effects and non-effects

Audit is not only for successful mutations. Runtime denial, resource-scope block, unresolved authority, domain denial, and an idempotent replay should all be reviewable. At minimum preserve request ID, actor ID, node ID, command name, side-effect class, decision, error/reason, and audit event ID. Do not copy raw secrets into the audit record; reviewability should not create a new data leak.

12. Failure example: “the capability allowed it, so it is safe”

Assume rotate_local_credential is reachable from the main window and its input is type-correct, but domain_authorized=false. The correct result is DENIED / DOMAIN_AUTHORIZATION_DENIED, not PASS. Tauri has enforced its framework boundary; the application policy has still refused the native effect. Reachability and authorization are not the same claim.

13. Failure example: resource escape

A credential rotation request targets credential/global/root, while the command owns only credential/node-42/. Even with an allowed origin, capability, permission, and type-correct input, the decision must be BLOCK / RESOURCE_SCOPE_EXCEEDED. Do not fall back to an arbitrary path or a generic dispatcher. A genuinely new use case requires a new explicit contract and review.

14. Lab: Tauri Command Boundary & Mediation Contract v1

lab://LOC-002/LOC002-LAB1 contains eight synthetic fixtures. For each case, build command-boundary, runtime-authority, input-validation, resource-scope, idempotency, auditability, and decision evidence. The oracle is not present in the learner root. Cases cover a valid read, a generic dispatcher, runtime denial, invalid typed input, domain denial, scope expansion, unresolved runtime authority, and a transfer operation that deletes only stale cache entries. The goal is to preserve PASS/BLOCK/DENIED/DEFER honestly, not to force success.

15. Transfer: delete stale cache without reintroducing a dispatcher

Add delete_stale_cache_entry as a fourth explicit operation. It may accept only keys under cache/stale/, must validate stale=true, must have independent domain authorization, and must use an idempotency key because it changes state. A replay of the same request returns the previous auditable result without a second effect. An attempted expansion into cache/live/ or another resource is blocked and recorded. The new feature must not widen the native boundary.

Official sources and claim boundary

• Tauri v2 — Calling Rust from the Frontend: https://v2.tauri.app/develop/calling-rust/
• Tauri v2 — Runtime Authority: https://v2.tauri.app/security/runtime-authority/

K1 and K2 are Tauri framework facts rechecked on 2026-09-17. K3 (narrow application commands) and K4 (idempotency/audit binding) are MAKNOW design rules and are not presented as Tauri requirements.