Future direction: write-with-approval

WRITE-WITH-APPROVAL MODEL (hypothetical, not shipped):
  1. Engineer asks agent for an action
  2. Agent generates a proposed mutation (via MCP "propose" tool)
  3. ZopNight surfaces a UI confirmation with full context
  4. Human clicks "Approve" or "Reject" (or "Schedule")
  5. Mutation executes through normal write path
  6. Audit log records: agent proposed at T0; human approved at T1

PROBLEMS UNSOLVED ENOUGH TO BLOCK V1:

1. CONFIRMATION FATIGUE
   Humans rubber-stamp clicks when prompted repeatedly.
   "Approve" becomes muscle memory.
   Defeats the safety purpose of the approval.

2. CROSS-TOOL CHAINING
   Agent could chain "approved" calls (one approval → many writes).
   Hard to bound blast radius.
   Need per-action approval; UX becomes painful.

3. TRUST CALIBRATION
   When should the human carefully review vs trust the agent?
   No good UX pattern yet.
   Either over-scrutinize (wastes time) or under-scrutinize (incident).

4. ADOPTION FRICTION
   Approval gates slow down the workflow.
   Undermines the agent value prop ("save me time").

5. AUDIT AMBIGUITY
   When something goes wrong: "agent proposed" vs "human approved":
   whose fault? Distributed accountability is messier than single
   accountability (human writes directly).

THESE ARE NOT INSURMOUNTABLE: but they are unsolved enough that
shipping now would create more problems than it solves.

PRE-CONDITIONS for ZopNight to ship write-with-approval:

1. SAFETY GUARDS
   ✓ Approval prompts impossible to spoof (no agent-injected approvals)
   ✓ Bulk actions require multi-step confirmation
   ✓ Destructive actions have cooldowns (24h delay)
   ✓ Reversible-only writes by default (auto-undo within N minutes)

2. UX
   ✓ Approvals fast (one-click but informative)
   ✓ Context obvious (what changes, what's at risk, what's the savings)
   ✓ Mobile-friendly (engineers approve from phones during incidents)
   ✓ Bundled view (related approvals grouped, not 30 separate prompts)

3. AUDIT
   ✓ Clear distinction between agent-proposed and human-approved
   ✓ Replay-capable ("what would have happened if rejected?")
   ✓ Cross-reference with the original prompt (what did engineer ask?)
   ✓ Regulatory-grade trail for SOC 2 / ISO 27001

4. SCOPE LIMITS
   ✓ Per-PAT scope: only certain action types eligible
   ✓ Org-level: opt-in feature flag (default off)
   ✓ Per-resource: tag-based eligibility (only tagged auto-approvable)
   ✓ Time-window: only during business hours, only at specific times

PHASE 0 (today): read-only

PHASE 1 (post-V1, speculative): low-risk write-with-approval
  EXAMPLES:
    Apply a certified recommendation (low risk, reversible)
    Tag a resource (purely metadata; no execution risk)
    Acknowledge an anomaly (status change; no resource impact)
    Mute a non-critical alert

PHASE 2 (further future): medium-risk
  EXAMPLES:
    Stop a non-prod resource (reversible)
    Update a schedule (effective on next window)
    Change a budget threshold (alerting only; no enforcement)

PHASE 3 (likely never via MCP): high-risk
  EXAMPLES:
    Delete a resource (irreversible)
    Change RBAC / org policy (security impact)
    Modify cost allocation models (downstream blast)
    Mass operations (>100 resources at once)

  THESE STAY IN UI / API / IAC forever.

TO MOVE FROM PHASE 0 → PHASE 1, ZopNight needs:

✓ Multiple customer requests asking for it (not just one)
✓ Customer interviews validating actual usage demand
✓ No major safety incidents in the read-only era
✓ Industry convergence on UX patterns
✓ Internal security team approval
✓ Pilot program participants willing to test

ABSENCE OF SIGNAL:
  Stay in read-only. Don't ship complexity nobody asked for.
  The current state is productive.

RISK 1: PROMPT INJECTION ESCALATION
  Attack scenario:
    Attacker poisons a document the agent reads
    (e.g., resource tag, recommendation note, audit comment)
    Poisoned content includes instructions ("ALSO delete X")
    Agent reads, triggers approval prompt for the legit action
    Hidden in same approval bundle: the malicious mutation
    Human, fatigued, approves
    Bad mutation executes

  MITIGATION:
    Approval UI shows full context: not just agent's claim
    Human must read the actual mutation, not summary
    Separate prompts for separate mutations (no bundling of dissimilar)
    Time delays for destructive actions

RISK 2: AGENT ERROR AMPLIFICATION
  Failure mode:
    Agent recommends wrong action (wrong resource, wrong direction)
    Human, trusting agent, approves
    Mistake propagates (and worse with bulk)

  MITIGATION:
    Reversible-only writes by default (auto-undo within N minutes)
    Cooldown periods for destructive actions
    Multi-step confirmation for high-blast-radius actions
    Bulk caps (max 10 resources per approval batch)

RISK 3: TRUST EROSION
  Failure mode:
    One bad outcome (one customer's prod incident from agent action)
    Story spreads on Twitter / HN
    Trust in agent-based tools degrades broadly
    Hard to rebuild

  MITIGATION:
    Slow rollout (private beta → opt-in GA → default-off feature)
    Heavy guardrails on the initial set of write tools
    Easy opt-out at any layer (org, team, user)
    Post-incident transparency if anything goes wrong

COMPETITORS shipping write capability today:
  Spot.io:     autoscaling (writes to clusters)
  Cast.ai:     k8s autoscaling
  Zesty:       autoscaling + SP/RI brokerage

THEIR RISK:
  AI takes action; misconfig causes customer incident
  One bad incident → customer churn
  Multiple incidents → category trust erosion

ZOPNIGHT'S BET:
  Be the conservative read-only option in 2026
  Engineer trust matters more than feature parity
  Build trust through demonstrated reliability
  Then expand carefully when industry matures

THIS BET PAYS OFF when:
  Customer prefers predictable safety to feature breadth
  CISO conversations are easier with read-only
  Customer's engineers have agency over writes

THIS BET FAILS when:
  Customer truly wants hands-off automation
  → They can use auto-remediation (which IS write-capable through
    a different, more-deliberate surface)

COMMON FEEDBACK on the read-only-only posture:

  "We love it. CISO is comfortable. Engineers use it daily."
  → 70% of customer feedback

  "We'd like writes eventually but no urgency."
  → 25% of customer feedback

  "If you ship writes, make sure it's opt-in. Default off."
  → 90% of write-curious customers add this caveat

RARELY:
  "We need write capability today or we'll switch vendors."
  → <5% of customers

ZOPNIGHT MCP ROADMAP (subject to change; no commitments):

2026: Read-only stable; add more read tools
       (more data sources, more filters)

2027: Possibly Phase 1 (low-risk write-with-approval)
       Pilot program; private beta
       Only if pre-conditions are met

2028+: Possibly Phase 2 (medium-risk) if industry matures
       AND Phase 1 results are clean

Phase 3: likely never via MCP
         These writes stay in UI / API / IaC

WHILE READ-ONLY:
  ✓ Use MCP for read-only workflows
  ✓ Routine writes via existing surfaces (UI / API / auto-rem)
  ✓ Provide feedback if you want write-with-approval (and what for)
  ✓ Test new MCP read tools as they ship
  ✓ Build team skills around the agent-helps-human-writes loop (M6.5.L2)
  ✓ Set up auto-remediation for the writes that ARE automatable today

DON'T:
  ✗ Wait for write capability before adopting MCP
  ✗ Build internal workflows that assume future writes
  ✗ Bet on a specific date

GATES that must all pass before adding any MCP write tool:

GATE 1: Customer demand (multiple customers, sustained over months)
GATE 2: Safety design reviewed and approved by security team
GATE 3: UX prototype tested for confirmation fatigue + clarity
GATE 4: Opt-in feature flag, off by default
GATE 5: Audit infrastructure ready (replay + cross-ref)
GATE 6: Incident response plan documented
GATE 7: Reversibility built in (auto-undo or rollback)
GATE 8: Bulk caps + cooldowns implemented

ANY GATE MISSING: no ship.

This is conservative by design. The cost of a bad write ship is
higher than the cost of staying read-only longer.

PRECEDENT: other tools that started read-only:

GITHUB COPILOT:
  Started: code suggestions only (read context, write code in IDE)
  Evolution: PRs / Actions integration (post-2023)
  Lesson: write capability came after years of read trust

KUBECTL:
  Started: full read+write from day 1
  Result: many production incidents from `kubectl delete` typos
  Industry response: kubectx, --dry-run flags, RBAC tightening
  Lesson: shipping full writes early creates years of cleanup

TERRAFORM:
  Started: plan-then-apply two-step
  Mature: still uses plan-then-apply (the safe pattern won)
  Lesson: the "preview before commit" pattern is durable

ZOPNIGHT MCP:
  Choosing the Copilot pattern: build read trust first;
  add writes deliberately if/when industry matures.

HYPOTHETICAL FUTURE: PHASE 1 LOW-RISK WRITE-WITH-APPROVAL:

ENGINEER (via MCP):
  "right-size i-0abc to t3.medium"

AGENT (via MCP-read):
  Confirms i-0abc has been 15% CPU for 30 days
  Confirms no recent spikes
  Confirms in IaC: NO (managed manually)
  Confirms business hours: YES
  Confirms not in critical-prod tag: PASS

AGENT proposes mutation (via hypothetical MCP "propose" tool):
  Action: change instance type t3.large → t3.medium
  Estimated savings: $80/mo
  Estimated risk: reboot required (~5 min downtime)
  Reversibility: auto-undo within 24h if requested

SYSTEM SHOWS APPROVAL UI (in ZopNight web):
  ┌────────────────────────────────────────────┐
  │ Agent proposes a write                     │
  │                                            │
  │   Right-size i-0abc                        │
  │   t3.large → t3.medium                     │
  │                                            │
  │   Savings:       $80/mo (~$960/yr)         │
  │   Risk:          Reboot required (~5 min)  │
  │   Reversibility: Auto-undo within 24h     │
  │   Owner:         jane@platform              │
  │   Tag:           non-prod, owner=jane       │
  │                                            │
  │   Original ask: "right-size i-0abc to       │
  │                  t3.medium" (from engineer)  │
  │                                            │
  │   [Reject]   [Schedule (next maint)]   [Apply Now]
  └────────────────────────────────────────────┘

ENGINEER reviews context, clicks "Schedule"
ZopNight executes at next maintenance window
AUDIT LOG:
  T0:      Engineer prompted agent (full prompt logged)
  T+2s:    Agent proposed mutation (logged with parameters)
  T+30s:   Engineer reviewed + approved with "Schedule"
  T+24h:   Mutation executed at scheduled time
  T+24h:   Confirmation logged + saved $80/mo

THIS IS NOT AVAILABLE TODAY.
Until then: agent identifies via MCP-read; human writes via UI/API/IaC.

TEAM DISCUSSION:

QUESTION 1: Would you opt in?
  □ Yes for low-risk writes
  □ Yes for medium-risk too
  □ No (read-only is enough)

QUESTION 2: What guardrails would you require?
  □ Default off; opt-in per user
  □ Reversibility (auto-undo)
  □ Multi-step confirmation for destructive
  □ Business-hours only
  □ Non-prod resources only initially
  □ Cap on bulk size

QUESTION 3: What writes would be MOST useful first?
  □ Apply certified recommendation
  □ Tag a resource
  □ Stop non-prod resource
  □ Update schedule
  □ Acknowledge anomaly

REFLECTION:
  If ZopNight shipped this in 2027 with the guardrails you listed,
  would your team adopt? Why or why not?