feat: approval-gate infrastructure for destructive ops (Phase 4) #2372

Merged

devops-engineer merged 1 commits from feat/platform-agent-approval-gate into main 2026-06-06 18:24:03 +00:00

Conversation 2 Commits 1 Files Changed 6

+398

devops-engineer commented 2026-06-06 17:43:43 +00:00

Member

Copy Link

Copy Source

Phase 4 of the org-level platform agent (RFC #2360). Independent of the re-parenting work (off main).

Server-side approval gate so destructive ops the user-driven concierge can trigger require a human approval. The platform MCP is a client of these handlers, so enforcement is here (the trust boundary), not in the MCP.

• migration: approval_requests.consumed_at (single-use) + request_hash (dedup) + partial index.
• internal/approvals/policy.go: the one auditable gated-action map + IsGated.
• requireApproval(): consumes a matching approved+unconsumed request (race-safe via conditional UPDATE … RETURNING / FOR UPDATE SKIP LOCKED) and proceeds; else creates/reuses a pending request, broadcasts to canvas, escalates to parent if any. gateDestructive() writes HTTP 202 pending.

Matching is (workspace_id, action, request_hash) — an approval for "delete ws A" can't be replayed to "delete ws B", and retries reuse one pending row.

Tests

• Unit: policy, hash stability + context-sensitivity, non-gated passthrough.
• Real-Postgres integration: full cycle — pending → dedup (1 row) → approve → consume → single-use (no replay) → context isolation. Verified locally (postgres:15, all migrations apply, green).

Scope note

Infrastructure only — not yet wired into live handlers. Wiring needs a platform-agent caller marker so the gate fires only for concierge-initiated calls (not operator/CP deletes); that lands with Phase 3's runtime/MCP marker, so existing delete/secret flows are unchanged until then. This keeps the gate safe to land now.

🤖 Generated with Claude Code

Phase 4 of the org-level platform agent (RFC #2360). **Independent** of the re-parenting work (off `main`). Server-side approval gate so destructive ops the user-driven concierge can trigger require a human approval. The platform MCP is a *client* of these handlers, so enforcement is here (the trust boundary), not in the MCP. - migration: `approval_requests.consumed_at` (single-use) + `request_hash` (dedup) + partial index. - `internal/approvals/policy.go`: the one auditable gated-action map + `IsGated`. - `requireApproval()`: consumes a matching approved+unconsumed request (race-safe via conditional `UPDATE … RETURNING` / `FOR UPDATE SKIP LOCKED`) and proceeds; else creates/reuses a pending request, broadcasts to canvas, escalates to parent if any. `gateDestructive()` writes HTTP 202 pending. Matching is `(workspace_id, action, request_hash)` — an approval for "delete ws A" can't be replayed to "delete ws B", and retries reuse one pending row. ### Tests - Unit: policy, hash stability + context-sensitivity, non-gated passthrough. - **Real-Postgres integration**: full cycle — pending → dedup (1 row) → approve → consume → single-use (no replay) → context isolation. Verified locally (postgres:15, all migrations apply, green). ### Scope note **Infrastructure only — not yet wired into live handlers.** Wiring needs a platform-agent caller marker so the gate fires only for concierge-initiated calls (not operator/CP deletes); that lands with Phase 3's runtime/MCP marker, so existing delete/secret flows are unchanged until then. This keeps the gate safe to land now. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

devops-engineer added 1 commit 2026-06-06 17:43:44 +00:00

feat(workspace-server): approval-gate infrastructure for destructive ops (Phase 4) ... 0b771d5770

Server-side gate so destructive org operations the user-driven platform agent can
trigger require a human approval (RFC docs/design/rfc-platform-agent.md). The
platform MCP is a CLIENT of these handlers, so enforcement lives here (the trust
boundary), not in the MCP.

- migration 20260606020000_approvals_consumed: approval_requests.consumed_at
  (single-use) + request_hash (dedup) + a partial index for the gate lookup.
- internal/approvals/policy.go: the one auditable map of gated actions
  (delete_workspace / deprovision / secret_write / org_token_mint) + IsGated.
- requireApproval(): consumes a matching approved+unconsumed request (race-safe
  via conditional UPDATE ... RETURNING / FOR UPDATE SKIP LOCKED) and proceeds,
  else creates/reuses a pending request (dedup by request_hash), broadcasts it to
  the canvas and escalates to the parent if any. gateDestructive() wraps it and
  writes HTTP 202 pending for gin handlers.

Matching is (workspace_id, action, request_hash) where request_hash is a stable
digest of the op + context, so an approval for 'delete ws A' can't be replayed to
'delete ws B', and retries reuse one pending row instead of flooding.

Tests: policy + hash-stability/context-sensitivity unit tests; gateDestructive
non-gated passthrough; and a real-Postgres integration test proving the full
cycle — pending -> dedup -> approve -> consume -> single-use (no replay) ->
context isolation (sqlmock cannot prove consume-once row state).

Infrastructure only — NOT yet wired into live handlers. Wiring requires a
platform-agent caller marker so the gate fires only for concierge-initiated calls
(not operator/CP flows); that lands with Phase 3's runtime/MCP marker so existing
delete/secret flows are unchanged until then.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

devops-engineer added the tier:medium label 2026-06-06 17:55:21 +00:00

molecule-code-reviewer approved these changes 2026-06-06 18:23:07 +00:00

molecule-code-reviewer left a comment

Member

Copy Link

Copy Source

Independent review confirmed: race-safe consume via FOR UPDATE SKIP LOCKED, dedup via conditional INSERT, context-isolated request_hash, best-effort broadcast, infra-only (no live wiring). Real-PG integration proves the full single-use cycle. Approving.

Independent review confirmed: race-safe consume via FOR UPDATE SKIP LOCKED, dedup via conditional INSERT, context-isolated request_hash, best-effort broadcast, infra-only (no live wiring). Real-PG integration proves the full single-use cycle. Approving.

core-security approved these changes 2026-06-06 18:23:42 +00:00

core-security left a comment

Member

Copy Link

Copy Source

Security review: server-side trust boundary (not MCP), fail-closed, single-use approvals (consumed_at), replay-blocked + context-isolated. No change to existing destructive handlers. Approving.

Security review: server-side trust boundary (not MCP), fail-closed, single-use approvals (consumed_at), replay-blocked + context-isolated. No change to existing destructive handlers. Approving.

devops-engineer merged commit 173881e67a into main 2026-06-06 18:24:03 +00:00

devops-engineer referenced this pull request 2026-06-06 23:18:22 +00:00

feat(approval-gate): wire gateDestructive into live destructive handlers (Phase 4b) #2382

Sign in to join this conversation.

Reviewers

No Reviewers

molecule-code-reviewer

core-security

Labels

Clear labels

area/ci

CI/CD pipeline issues

do-not-auto-merge

Opt out of autonomous merge-queue merging

kind/infrastructure

Infrastructure-related issues

merge-queue

Ready for serialized Gitea merge queue

merge-queue-hold

Temporarily hold PR in merge queue

platform/go

Go platform test issues

release-blocker

Blocks the staging→main promotion / a release

release-test

security

test-label-sre

tier:high

High risk per dev-sop §SOP-6 — ceo only, 24h cooldown

tier:low

Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve

tier:medium

Medium risk per dev-sop §SOP-6 — managers/ceo can approve

triage-test

test

wip

Work in progress — do not auto-merge

No Label tier:medium

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)

No Assignees

3 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#2372