Org-level MCP toggle · ZopDev University

Outcome

By the end of this lesson, you will be able to use the org-level MCP toggle as a central kill switch, execute a deliberate MCP rollout pattern, and explain the four-layer compliance posture to a CISO.


Prerequisites	M6.3.L1 (PAT basics)
Time	9 minutes

1. Concept

Nobody’s token works until the organisation switches MCP on. That switch is off to begin with.

It is also the way to stop everything at once. One setting, and every assistant in the company loses access immediately.

That exists because a compliance team asking “how would you cut this off?” needs a better answer than “we would revoke everyone’s tokens individually”.

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

  ENABLED:  users can connect AI agents (OAuth or PAT)
  DISABLED: the gateway refuses every MCP call, OAuth or PAT

The toggle is per-org, not per-user. It’s the foundation; individual PATs are the next layer (M6.3.L1).

Where the toggle lives

ZopNight UI:
  Settings → Organization → MCP Server section

  Toggle: "MCP Server" (badge shows Active / Inactive)
  When on, the Server URL and the Write access picker appear
  Audit log shows when toggled and by whom

Default state

NEW ORGS: MCP disabled by default (opt-in)
  Exception: an org created while connecting an AI client
  through the OAuth sign-in flow starts with MCP on (its creator
  is its only admin, and asked for it)
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

Opt-in by default is the safer position for AI integration features. Customers turn it on when they’re ready.

Who can toggle

ROLES that can change the toggle:
  Any role holding organisation:update
  (of the system roles, only Admin)

ROLES that cannot:
  Editor, Viewer, custom roles without organisation:update

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

What disabling does

WHEN TOGGLED OFF:
  ✓ Existing PATs continue to work for non-MCP APIs
  ✓ Existing MCP connections get an error on their next call
  ✓ New MCP connections fail immediately
  ✓ Users see: "MCP server is not enabled for this organisation"
  ✓ Non-MCP API + UI calls continue normally

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

So if a security incident happens or compliance requests a halt, one click stops everything. Other ZopNight operations continue.

Audit trail of the toggle

EVERY toggle change is an organisation update, so it is logged
in the audit log:
  Timestamp
  Admin user who toggled
  The new value (settings.mcp_enabled: "true" or "false")

Sample audit entry:
  2026-05-21 14:32 UTC
  user: admin@acme.com
  request: PUT /organisation
           {settings: {mcp_enabled: "false"}}

The toggle has no reason field: record why in your incident
or change ticket, and link the two.

Recommended rollout pattern

1. INTERNAL DISCUSSION (FinOps + sec + eng leadership):
   Confirm the write tier (default none) 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
   Record it in your change log: "Initial MCP enablement, pilot rollout"

5. COMMUNICATE to team:
   "MCP enabled. Connect with OAuth, or create a PAT at
    Settings → API & MCP."
   "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.

The four-layer compliance posture

When the CISO asks “How is AI agent access to cost data controlled?”:

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

LAYER 2: Per-user credential (you provision)
  Each user connects with their own OAuth grant or PAT;
  revocable; PATs rotated quarterly.

LAYER 3: Org write tier (you control)
  Defaults to none, so agents read and cannot mutate
  until an admin raises it.

LAYER 4: Audit log on every MCP call
  Reads and writes logged; CSV export for your own retention.

Four independent controls; any one can be tightened or relaxed without the others. CISO conversations are easier when these layers are documented.

When to disable

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

Re-enabling

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

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

Cost

MCP toggle: free
PATs: free
Storage of PAT metadata: free
MCP server execution: free (hosted by ZopNight)
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.

Adoption isn’t gated by ZopNight pricing. The cost is in the AI tool’s per-token charges.

Multi-org accounts

For customers with multiple ZopNight orgs (e.g., one per BU after M&A):

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.

How the toggle layers with PAT limits

THERE IS NO ORG-WIDE PAT POLICY. Limits are set on each token
when it is minted (Settings → API & MCP):
    Which orgs it may act in
    When it expires
    Which permissions it carries (never more than its owner's)

  If MCP toggle is off: no PAT can reach MCP in this org
  If MCP toggle is on:  the toggle, the org's write tier and each
                        token's own limits are layered controls

Enforce a maximum token age or a rotation cadence through your own runbook (M6.3.L4), not a product setting.

2. Demo

A real incident-driven toggle disable + re-enable:

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

ADMIN ACTION:
  T+0:00   Open Settings → Organization → MCP Server
  T+0:30   Toggle off
  T+0:45   Note in the incident ticket: "Security investigation
                          2026-05-15-001; temporary MCP disable
                          pending forensics"

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 server is not enabled for this organisation"
  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    Incident ticket updated: "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

The toggle is designed for exactly this scenario.

3. Hands-on (5 min)

If you’re an Org Admin:

□ LOCATE the toggle in Settings → Organization → MCP Server
□ NOTE current state: Enabled / Disabled
□ REVIEW audit log for toggle history (if any)
□ IDENTIFY: who else can toggle (roles with organisation:update)
□ DOCUMENT: rollout pattern in your team wiki

If you’re not an Org Admin:

□ CHECK whether your org has MCP enabled
  (try connecting via M6.2; "MCP server is not enabled for this
   organisation" means the toggle is off)
□ IDENTIFY who in your org can enable
□ REQUEST enablement if appropriate (use M6.1 docs to justify)

For new MCP rollouts, follow the 7-step pattern in the lesson.

4. Knowledge check

Q1

MCP for a new ZopNight org:

A. Enabled by default: ready for agents
B. Always enabled (cannot disable)
C. Disabled by default
D. Enabled for Admins only until another admin widens it

Show answer

Correct: C. An admin turns it on deliberately, which avoids “we didn’t realise AI was on”. The one exception is an org created while connecting an AI client through OAuth sign-in, which starts with MCP on.

Q2

Disabling the org toggle:

A. Disrupts all non-MCP API calls too
B. Only affects MCP
C. Revokes every PAT the organisation has issued
D. Deletes all PATs

Show answer

Correct: B. Non-MCP API and UI calls continue normally. The toggle’s blast radius is bounded to MCP activity, which makes it safe to use as an emergency lever.

Q3

Who can toggle MCP access:

A. Any engineer holding a valid PAT
B. Anyone at all who holds a PAT
C. Roles holding organisation:update
D. The ZopNight support team only

Show answer

Correct: C. Of the system roles only Admin holds organisation:update; Editor and Viewer do not, nor does a custom role without it. Restricting the switch prevents unilateral enablement.

5. Apply

Org-level MCP toggle is the foundation. Default disabled; opt-in deliberately. Document the four-layer compliance posture for CISO conversations.

For incident scenarios: the toggle is the right emergency lever. 30-second disable; smooth re-enable.

Outcome

1. Concept

Where the toggle lives

Default state

Who can toggle

What disabling does

Audit trail of the toggle

Recommended rollout pattern

The four-layer compliance posture

When to disable

Re-enabling

Cost

Multi-org accounts

How the toggle layers with PAT limits

2. Demo

3. Hands-on (5 min)

4. Knowledge check

Q1

Q2

Q3

5. Apply

Related lessons

Start with the bill.