Route Maestro approvals, sandbox, and firewall decisions through Platform policy services

[haasonsaas]

From the Maestro/platform integration review using gh on 2026-04-22.

Reviewed heads:

• ae6e88a
• evalops/platform@7b003938349939052f90ae41241599993a7c06c9

Problem

Maestro has local approval, sandbox, and firewall decision points. Platform has governance, approvals, habit learning, and policy services, plus planned maestro.* event subscribers. The Platform side is partly tracked in evalops/platform#748, evalops/platform#763, and evalops/platform#764, but Maestro does not yet have a concrete issue to route its runtime decisions through those services.

Scope

• Add an optional decision adapter that can ask Platform governance/approvals before privileged tool, shell, filesystem, network, or MCP actions.
• Normalize decision inputs: command/tool name, arguments, cwd/repo, touched resources, network host, model/provider, surface, user intent, session id, and workspace/team context.
• Keep local/offline behavior available, with explicit fallback semantics when Platform policy is disabled or unreachable.
• Map Platform approval requests/responses into Maestro's existing approval UI and headless protocol messages.
• Emit maestro.events.approval_hit, maestro.events.sandbox_violation, and maestro.events.firewall_block with Platform decision ids / approval request ids when present.
• Consume learned approval/governance habits where available without silently weakening local policy.

Acceptance Criteria

• Mocked Platform policy tests cover allow, deny, approval-required, unavailable, and malformed-response cases.
• Local-only Maestro approval/sandbox/firewall behavior remains unchanged when the adapter is disabled.
• A Platform-backed smoke path shows a decision request, an approval wait/resume, and correlated maestro.* events.
• UI/headless users receive actionable denial or approval-pending reasons instead of generic tool failures.

Related: evalops/platform#177, evalops/platform#748, evalops/platform#763, evalops/platform#764, evalops/platform#765, #49, #72.

---

Runtime Parity / Conformance Links

• Define Rust core runtime parity contract for hosted Maestro #84 — Rust core runtime parity decision for hosted Maestro.
• Add headless runtime conformance suite for Rust parity #85 — headless runtime conformance suite that should gate Rust-hosted runner parity.

Use #85 as the protocol-level acceptance bar: lifecycle, subscribe/events/messages/heartbeat/disconnect, viewer/controller roles, permission request/response, utility operations, workspace-root enforcement, cursor replay/reset, and drain/resume behavior should match across the current TypeScript web/headless bridge and the target Rust runtime.

[haasonsaas]

Cross-linking from the integration tracker:

• Platform policy evaluator work: evalops/platform#748
• Approval habit/generalized learning pattern: evalops/platform#764
• Durable runtime waits that should carry approval pauses: Use Platform agent-runtime as Maestro's durable run ledger #72 and evalops/platform#780
• maestro.* event contract and subscribers for approval/sandbox/firewall signals: evalops/platform#762, Publish Maestro telemetry as typed CloudEvents onto platform's event bus #49, evalops/platform#763
• Governed MCP tool calls should use the same decision path where possible: Consume Platform-governed MCP skill endpoints as Maestro tool sources #74

Implementation note: treat Platform policy as optional/configured. Local Maestro approval/sandbox/firewall behavior should remain intact when disabled or unavailable.

[haasonsaas]

Cross-linking from the hosted remote-server hardening pass:

• Bind headless remote sessions to explicit workspace sandboxes #77 (workspace sandbox) is a prerequisite for meaningful policy decisions around utility_command_start, file read/search/watch, MCP config, LSP, and git/team-memory context.
• Use verified principals for hosted remote session scope and authorization #79 (verified principal scoping) gives this policy issue durable actor/workspace/team claims instead of token-hash scopes.
• Bring Maestro Helm and runtime image up to hosted remote-server requirements #80 should surface the production env/chart switches that make the policy path required in hosted mode.

This issue remains the policy/governance integration; those remote-server issues define the boundary policy should govern.

[haasonsaas]

Stale triage (2026-07-19): local approval/sandbox/firewall still primary; Platform policy adapter not the default. Related E2E slice #171 still open. Pending: optional decision adapter + consent/fallback semantics. Keep.