# Phase 20: Remediation, Approval & Audit Safety - Discussion Log

> **Audit trail only.** Do not use as input to planning, research, or execution agents.
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.

**Date:** 2026-07-16
**Phase:** 20-remediation-approval-audit-safety
**Areas discussed:** Remediate scope, Permission grant, Approval scope, FP state guard

---

## Remediate scope

| Option | Description | Selected |
|--------|-------------|----------|
| Simulated internal effect | No real external API call for any action type. Remediate transitions `remediation_actions.status` to `completed` internally, writes the audit event, and returns success — the "effect" REMED-04's idempotency test asserts doesn't duplicate. All 7 action types behave the same way. | ✓ |
| Always not_implemented | Every remediate call returns not_implemented/501 for every action type, since no provider is configured. Pure safety-contract stub. | |
| Wire one real action for real | Actually implement `disable_forwarding_rule` via MS Graph — real effect for one action, not_implemented for the other 6. More scope/risk. | |

**User's choice:** Simulated internal effect (Recommended)
**Notes:** Confirmed no provider client (Mimecast, MS Graph, RMM) has a block/purge/forwarding-rule/isolate method today, before presenting this question.

---

## Permission grant

| Option | Description | Selected |
|--------|-------------|----------|
| Admin + Super-Admin | Same tier as `analyze` today — parity with how this milestone has treated admin/super-admin identically so far. | ✓ |
| Super-Admin only | Stricter tier — approve/remediate can affect real security posture, so only super-admin gets it. | |

**User's choice:** Admin + Super-Admin (Recommended)
**Notes:** Confirmed via direct read of `lib/permissions.ts` that both roles currently have only `phishing: ["read", "analyze"]` before asking.

---

## Approval scope

| Option | Description | Selected |
|--------|-------------|----------|
| Operator selects a subset | Request body includes which action(s) to approve and can override params (e.g. narrowing `block_sender` to a specific address). Matches REMED-02's "exact approved action parameters" wording. | ✓ |
| Approve the full set verbatim | One approve call locks in ALL recommended_actions exactly as proposed — simpler, less operator control. | |

**User's choice:** Operator selects a subset (Recommended)
**Notes:** None.

---

## FP state guard

| Option | Description | Selected |
|--------|-------------|----------|
| Block after approve/remediate | mark-false-positive returns an explicit conflict/error if the campaign already has an approved or completed remediation_actions row. | ✓ |
| Always allow, just label it | mark-false-positive is a pure label change regardless of remediation state — simpler but permits a contradictory audit trail. | |

**User's choice:** Block after approve/remediate (Recommended)
**Notes:** None.

---

## Wrap-up check

Asked whether any further gray areas needed discussion before writing context.

**User's choice:** I'm ready for context (Recommended)

## Claude's Discretion

- Exact idempotency detection mechanism for `POST /remediate` re-runs.
- Exact `audit_events.actor` value format (likely session email).
- Whether `POST /approve` allows multiple approve calls over time vs. one-shot.
- Exact JSON request/response shapes for the three new routes.
- Whether a `not_implemented` code path still exists as a defensive fallback.

## Deferred Ideas

- Real remediation provider wiring (Mimecast block, Graph forwarding-rule, RMM isolate, password reset) — `REMEDEXEC-01..05`, v2.
- False-positive reversibility — not discussed, no signal it's needed.
- Multi-round approval — noted as Claude's discretion, not locked.
