Org-level MCP toggle

ORG SETTING (ZopNight admin only):
  MCP Access: ENABLED  |  DISABLED

  ENABLED:  users can create PATs and connect AI agents
  DISABLED: PATs reject all MCP connection attempts

ZopNight UI:
  Settings → Organization → Access → MCP

  Toggle: "Allow MCP connections"
  Audit log shows when toggled and by whom
  Required reason field for audit trail

NEW ORGS: MCP disabled by default (opt-in)
EXISTING orgs at time of MCP rollout: opt-in via the toggle

WHY OPT-IN by default:
  Don't surprise compliance / security teams
  Force a deliberate decision before AI access exists
  Customer can read the docs (M6.1, M6.2), discuss internally, enable
  Reduces "we didn't realize AI was on" scenarios

ROLES that can change the toggle:
  Organization Admin
  Owner

ROLES that cannot:
  Member, Viewer, custom roles without org:update policy

This prevents an engineer from unilaterally enabling. The decision
is intentionally restricted to org-level admins.

WHEN TOGGLED OFF:
  ✓ Existing PATs continue to work for non-MCP APIs
  ✓ Existing MCP connections receive "MCP_DISABLED" error on next call
  ✓ New MCP connections fail immediately
  ✓ Users see clear error: "MCP is disabled by org admin"
  ✓ Non-MCP API + UI calls continue normally

EFFECT: ALL MCP activity stops within ~30 seconds of toggle.

EVERY toggle change is logged in the audit log:
  Timestamp
  Admin user who toggled
  Old state → new state
  Reason (recommended; optional but expected)

Sample audit entry:
  2026-05-21 14:32 UTC
  user: admin@acme.com
  org: org_acme123
  action: mcp.toggle_disabled
  reason: "Security investigation 2026-05-15-001"

Visible in audit log; surfaces in compliance reports.

1. INTERNAL DISCUSSION (FinOps + sec + eng leadership):
   Confirm read-only architecture is acceptable
   Review M6.1, M6.2, M6.3
   Identify pilot users

2. READ MCP DOCS thoroughly (this module + the docs site)

3. CONFIRM READ-ONLY CONTRACT with security team:
   Walk through M6.1.L2
   Address CISO concerns

4. ENABLE MCP at org level
   Reason field: "Initial MCP enablement, pilot rollout"

5. COMMUNICATE to team:
   "MCP enabled. Generate PATs at Settings → PATs."
   "Read M6.2 for your AI tool's setup."
   "Pilot users: <list>"

6. PILOT with 3-5 engineers for 2-4 weeks
   Collect feedback
   Refine rollout patterns

7. EXPAND to broader team
   Document common workflows
   Save them as team skills (M6.4)
   Train new engineers in onboarding

DON'T enable silently. The deliberate process is the point.

LAYER 1: Org-level toggle (you control)
  Can be disabled with one click; we control the lever.

LAYER 2: Per-user PAT (you provision)
  Each user has their own PAT; rotated quarterly; revocable.

LAYER 3: Read-only by design (ZopNight contract)
  Architectural: agents cannot mutate; no tool exists to do so.

LAYER 4: Audit log on all PAT issuance + MCP calls
  Every action logged; SIEM export for long retention.

TEMPORARILY:
  Active security investigation (suspected breach)
  Compliance audit ongoing (auditor wants no AI access during)
  Migration / maintenance window (system instability)
  Pre-renewal review (vendor change consideration)

PERMANENTLY:
  Org policy decision against AI agents
  Customer chose not to adopt
  Regulatory requirement prohibits agent access

TOGGLE BACK ON:
  ✓ Existing PATs immediately work again
  ✓ No re-provisioning needed
  ✓ Audit log records the re-enable + reason

Smooth re-enable means temporary disables don't disrupt
workflows long-term. Engineers' AI tools reconnect on next call.

MCP toggle: free
PATs: free
Storage of PAT metadata: free
MCP server execution: free (runs on customer's machine for local mode;
                              ZopNight infra for hosted)
ZopNight side: zero charge per MCP call

LLM INFERENCE COST: paid by the AI tool (Claude / Cursor / Codex / etc.)
                    Customer's contract with their AI tool provider
                    Independent of ZopNight pricing.

EACH ORG has its own toggle.
TOGGLE STATE is per-org.

EXAMPLE:
  acme-prod-org:   MCP enabled
  acme-staging:    MCP enabled
  acme-acquired:   MCP disabled (pending compliance review)

A user with PATs across multiple orgs sees different behavior
per org based on each org's toggle.

ORG-LEVEL toggle interacts with PAT policy (Settings → Org → API):

  PAT POLICY can require:
    Max PAT age (e.g., 90 days)
    Manager approval for new PATs
    Forced rotation cadence
    Restricted PAT scopes

  If MCP toggle is off: PAT policy doesn't apply (no MCP usage)
  If MCP toggle is on: PAT policy + MCP toggle are layered controls

SCENARIO: Acme Corp's CISO asks to disable MCP during a sec
          investigation triggered by unrelated incident.

ADMIN ACTION:
  T+0:00   Open Settings → Org → Access → MCP
  T+0:30   Toggle off
  T+0:45   Reason field: "Security investigation 2026-05-15-001;
                          temporary disable pending forensics"
  T+1:00   Save

EFFECT:
  T+0:30   Audit log entry created
  T+0:45   All MCP connections drop within 30 seconds
  T+1:00   Engineers see in their AI tools:
            "MCP_DISABLED: ZopNight MCP is disabled by org admin"
  T+1:00   Non-MCP API + UI calls continue normally

INVESTIGATION proceeds for 2 days; no findings related to MCP.

ADMIN ACTION (resolution):
  T+48h    Toggle MCP back on
  T+48h    Reason field: "Security investigation closed (2026-05-15-001);
                          no MCP-related findings; re-enabling"
  T+48h    All previously-connected agents reconnect
  T+48h    Audit log records re-enable

TOTAL DISRUPTION:
  Agent workflow paused for 2 days
  Non-agent operations: unaffected
  Engineers reverted to dashboard during the window
  Re-enable: smooth; no PAT regeneration needed

□ LOCATE the toggle in Settings → Organization → Access → MCP
□ NOTE current state: Enabled / Disabled
□ REVIEW audit log for toggle history (if any)
□ IDENTIFY: who else can toggle (Admins / Owners list)
□ DOCUMENT: rollout pattern in your team wiki

□ CHECK whether your org has MCP enabled
  (try connecting via M6.2; if "MCP_DISABLED" → toggle is off)
□ IDENTIFY who in your org can enable
□ REQUEST enablement if appropriate (use M6.1 docs to justify)