The CISO's MCP Field Guide v2: From Inventory to Runtime Governance

v2 note. This guide supersedes our January 2026 MCP Server Security: A 2026 Field Guide and consolidates lessons from six months of enterprise deployments. The earlier guide focused on threats; this version covers the operational program a CISO actually runs.

Answer box

Six months ago, MCP was a developer curiosity. Today it is the default integration layer between LLMs and enterprise systems — and almost every Fortune 1000 has shipped MCP into production without an explicit governance program. This field guide is the v2 enterprise reading: the four-pillar program (inventory, governance, runtime control, incident response), the policy artifacts you need on file, the board-reporting framework, and the OWASP and ISO 42001 control mappings auditors will ask for next quarter.

What changed in six months

Three things, all material:

1. MCP is now embedded in every major coding agent and AI assistant. Claude Code, Cursor, Cline, Codex CLI, Continue, Aider, GitHub Copilot Chat — all now ship MCP support. Where six months ago you could say "we don't use MCP," that is no longer plausible at most enterprises.

2. OWASP catalogued the risk. The OWASP Top 10 for Agentic Applications 2026 elevated MCP-related risks to first-class entries — ASI04 (Supply Chain), ASI02 (Tool Misuse), ASI07 (Inter-Agent), ASI06 (Memory Poisoning). This gives CISOs the shared vocabulary the category had been missing.

3. The first major public MCP-adjacent incident landed. The CISA GitHub configuration leak gave the world a preview of what credential and configuration exposure looks like at MCP scale. It will not be the last.

The result: MCP governance moved from "we should think about this" to "the auditor will ask in three months." This guide is what to have ready.

The four-pillar MCP program

Every working MCP governance program we have seen runs four pillars in parallel:

The rest of this guide is the operational detail under each pillar. For the step-by-step inventory mechanics specifically, see our companion piece: MCP Server Security: The Enterprise Inventory Playbook.

Pillar 1 — Inventory (the foundation)

The single most common failure mode in MCP programs is treating inventory as a one-time exercise. MCP servers turn over weekly. New ones ship inside every IDE update. The inventory has to be continuous.

What "good" looks like:

• Continuous discovery combining network egress logs, workstation child-process enumeration, and a scan of well-known config files (claude_desktop_config.json, mcp.json, .vscode/mcp.json, etc.).
• Risk-scored catalog — every server scored on data sensitivity, backend reach, auth model, supply-chain origin, and egress profile.
• Named ownership — every server has an individual accountable owner. No orphans. The orphan-decommission cycle is uncomfortable and removes 20-40% of the inventory in week one without complaints.
• Live agent-to-server graph — for every agent, which servers does it call. For every server, which agents call it. The many-to-one nodes are your highest-blast-radius assets.

The full mechanics are in the enterprise inventory playbook.

Pillar 2 — Governance (the policy spine)

Six policy artifacts every CISO should have on file by the next audit:

1. MCP Acceptable Use Policy

A 1-2 page document covering: - Who may install MCP servers (engineering, data, AI teams — typically all of them). - Where MCP servers may run (corporate-managed workstations only; not personal devices). - Which sources are approved (signed registry; vetted vendor bundles; first-party servers). - What is prohibited (unsigned community servers in production paths; servers with arbitrary network egress). - Mandatory disclosure — every server installed gets inventoried within 24 hours.

2. AI Bill of Materials (AIBOM) Standard

The AIBOM is to AI what SBOM is to software. The standard defines: - What is captured (model weights, datasets, MCP servers, plugins, agents, prompts). - How versions are pinned (commit hashes, package versions, model release IDs). - Update cadence (weekly automated; ad hoc on incidents). - Retention (the AIBOM at every release is an audit artifact, retained per record-retention schedule).

Procurement will ask for an AIBOM from your AI vendors within six months. Have your own first.

3. MCP Risk-Scoring Rubric

The 5-dimension, 0-15 scale from our inventory playbook. Codify it. Apply it consistently. Servers above defined thresholds escalate, pause, or decommission per a written workflow.

4. Change Control Workflow for MCP

New servers, new versions of existing servers, and new tool descriptors all enter a review queue. The workflow defines: - Who reviews (named security architect + product owner). - SLAs (typically 48-72 hours for non-emergency). - Emergency-path exceptions and post-hoc review requirements. - Auto-approve criteria (signed by an approved publisher; on the registry; no new tool capabilities introduced).

5. Decommissioning Standard

Every server in the inventory has an expected end-of-life date. The standard covers: - Default lifetimes (90 days for low-risk; 30 days for high-risk pilots). - Renewal review process. - Credential and token revocation at decommission. - Audit log retention post-decommission.

6. Vendor Disclosure Requirements

Any vendor product shipping with MCP capabilities must disclose: - Which MCP servers it bundles. - Auto-update behavior. - Tool descriptors and capabilities. - Backend systems it can reach.

This becomes a clause in your AI procurement contracts. Most vendors will not have ready answers. Make their answers a requirement.

Pillar 3 — Runtime (the technical control plane)

Eight controls that make the policy real. These run inline, in production, on every agent/MCP interaction.

1. Tool allowlisting. Agents may only call tools in a signed registry. New tools require change-control approval.
2. Tool-description inspection. Every tool description the model reads is inspected for prompt-injection patterns, imperative role-shift language, and known-bad signatures.
3. Tool-response inspection. Responses from MCP servers are inspected before the agent ingests them. PII, credentials, embedded prompt-injection — detected and redacted.
4. Capability-scoped tokens. No long-lived credentials. Every tool call receives a short-lived, scope-bounded token, issued per task.
5. Egress policy on the agent runtime. Allowlist outbound destinations. Deny by default. The cheapest control and the most universally skipped.
6. Provenance logging. Every tool call logged with user, agent identity, server + version, tool + version, arguments, response hash, decision rationale.
7. Rate and cost caps. Per agent identity, per tool, per hour. Catches Variant 2 tool misuse (recursive loops, runaway processes) before the bill arrives.
8. Per-server kill switches. Disabling a server or a tool descriptor takes seconds, not change windows. This is a tabletop drill, not a tech feature.

In an AccuroAI deployment these run on the Govern + Protect layers as configuration. Without AccuroAI, you can stand each up against your existing CASB + secrets manager + WAF + SIEM — at the cost of integrating four systems and accepting that each runs a different policy engine.

Pillar 4 — Incident response (the operational closure)

The first 60 minutes of an MCP incident matter more than the next six hours. Pre-stage:

Detection signals

• New, unapproved tool descriptors appearing on registered MCP servers.
• Anomalous tool-call rates from a single agent identity.
• Response patterns containing prompt-injection signatures.
• Egress from agent runtime to new external hosts.
• Sudden expansion in the agent-to-server graph.

These have to be wired into your SIEM. Most are not collected today because the events have not been modeled.

Runbook for the four most likely incident classes

1. Compromised MCP server. Kill switch the server. Snapshot last N tool calls. Identify dependent agents. Roll forward to a vetted version or to a fallback server. Notify the server's owner and the publisher.
2. Poisoned tool description. Disable the offending tool descriptor. Inspect logs for agents that already called the tool during the window. Review their actions for follow-on impact. Push an inline inspection rule to detect the signature going forward.
3. Credential exfiltration via tool. Revoke the token. Rotate the underlying credential. Audit downstream system access for activity matching the token's scope during the exposure window.
4. Inter-agent injection cascading from MCP response. Halt the multi-agent workflow. Snapshot the message bus. Trace the injection back to the originating MCP response. Apply tool-response inspection rules to prevent re-trigger.

Tabletop drill

Run one in the first 30 days of program standup. Most enterprises discover their "kill switch" requires a config-file edit, redeploy, and IDE restart per developer. That is not a kill switch. The drill is what surfaces the gap.

Communication tree

Who gets paged for which class. CISO office briefing template. Customer / regulator notification thresholds. None of this is MCP-specific in form; all of it is MCP-specific in content because the runbook differs from a traditional endpoint incident.

Mapping the program to OWASP, NIST, and ISO 42001

Auditors will eventually map this for you. Do it yourself first.

When the EU AI Act high-risk obligations land in full (currently scheduled for Dec 2027 per the May 2026 Digital Omnibus), Article 9's risk management obligations will require demonstrable evidence in most of these cells. Producing that evidence is straightforward if the program above is in place. It is brutally hard if it isn't.

A board-reporting framework

What to bring to the AI risk committee every quarter. Six slides:

1. MCP inventory delta. Servers added, decommissioned, deferred. The trend line that matters is "servers per developer workstation" — the leading indicator for shadow IT regrowth.
2. High-risk catalog. Servers scoring 10+ on the rubric. By name, by owner, by mitigation status.
3. Agent-to-server graph. Visualized. Most discussed slide every meeting.
4. Tool-response inspection metrics. Detections per million tool calls, by category (PII, credentials, prompt-injection). Trend over time.
5. Incident tabletop status. Drills completed, time-to-kill measurements, gaps surfaced.
6. Policy and audit posture. Which artifacts are current, which are due for refresh, audit findings outstanding.

This is the dashboard your board chair, audit committee, and external auditors will all converge on within a year. Build it once.

Common failure modes

We have seen each of these multiple times. None is theoretical.

• "We don't use MCP." You do. Run discovery (Pillar 1) and tell us how that statement holds up.
• "Our CASB covers it." Your CASB sees SaaS traffic. Most MCP runs locally. Coverage is partial at best.
• "The dev team is handling it." They are not. They are shipping the integration; you are shipping the control plane. These are different jobs.
• "We'll roll our own proxy." Many enterprises have started this. Most have not finished. The reason is the same as why nobody rolled their own EDR: the policy engine, telemetry pipeline, and rule library together are a product, not a project.
• "We'll wait for the OWASP / NIST / ISO framework to mature." OWASP shipped in December 2025. NIST AI RMF is current. ISO 42001 is current. The frameworks are not the blocker.

What to do in the next 30 days

1. Stand up Pillar 1 — the inventory — using the enterprise playbook. This is the foundation; nothing else works without it.
2. Draft the six policy artifacts from Pillar 2. Have them through GRC review in the same 30 days.
3. Deploy three Pillar 3 controls against your highest-blast-radius MCP servers — tool allowlisting, tool-response inspection, provenance logging. The rest follow.
4. Run a Pillar 4 tabletop. Time-to-kill in minutes, not hours. Gap log feeds next-month roadmap.
5. Prepare the board deck for the next quarterly AI risk committee. Use the six-slide framework above.

If you want help running this — particularly the Pillar 3 runtime layer, which is the most expensive to build internally — book a 30-minute demo and we will run the inventory against your environment as part of the pilot.

FAQ

Does AccuroAI replace the need for an MCP governance program? No. The program is yours. AccuroAI is the platform that makes Pillar 3 (runtime) and large parts of Pillar 1 (inventory) and Pillar 4 (incident response) operational. Pillar 2 (policy and governance) is yours regardless.

How does this guide differ from the v1 published in January 2026? v1 focused on the MCP threat landscape — what attacks look like. v2 covers the full operational program a CISO actually runs day-to-day, with the artifacts and dashboards we have seen work across deployments.

Do I need an AIBOM right now? Yes. Procurement and auditors will both ask within six months. Producing one retroactively is expensive; running one continuously is mechanical once the inventory is live.

How does this relate to the OWASP Top 10 for Agentic Applications? Directly. MCP risks are catalogued under ASI02, ASI04, ASI06, and ASI07. The program above is the operational implementation of the controls those entries call for. See our annotated OWASP guide.

What's the single highest-leverage control if I can only do one? Tool-response inspection. It is the structural defense against the entire class of indirect prompt-injection and tool-poisoning attacks coming through MCP responses, and it is the control most often missing.

Sources: OWASP Top 10 for Agentic Applications 2026 · Qualys — MCP Servers as Shadow IT · Cloud Security Alliance — Shadow AI Agents (May 2026) · Nightfall on CISA GitHub leak.

Related: OWASP Top 10 for Agentic Applications 2026, Annotated for Enterprises · MCP Server Security: The Enterprise Inventory Playbook · Tool Poisoning: The Supply Chain Attack Coming for Your AI Agents.