MCP for Cyber Incident Response

Why MCP matters in cyber-IR. Incident response teams use many AI assistants in parallel: the analyst's personal copilot, the platform's agents, counsel's research tool. MCP lets all of them read the same incident facts and draft outputs through a standard interface, without bespoke integration. Capability scoping at the tool layer is what keeps the architecture defensible.

What MCP is

MCP defines three primitives. Tools are actions an AI client can request (read the incident ledger, draft a regulator notification). Resources are data the AI client can subscribe to (the live incident state, the regulatory clock countdowns). Prompts are reusable templates the server exposes for common workflows. An MCP server publishes these primitives; an MCP client discovers and uses them.

The protocol carries the request-response pattern over stdio (for local processes) or HTTP with Streamable HTTP transport (for remote services). Authentication, capability negotiation, and discovery are part of the protocol. The result: an AI assistant connecting to a new MCP server can introspect capabilities and use them under capability scoping, without the assistant author having written code for that specific server.

The IR-OS MCP server

The IR-OS MCP server exposes incident-handling capabilities to AI clients under three control layers: tenant isolation, role-based access, and incident-scoped capability boundaries. Every MCP credential carries the user identity, the role assigned in the current incident, and the incident scope. The server enforces the boundaries at the tool layer.

Tool	Type	Purpose
incident.get	Read	Return current incident metadata
ledger.read	Read	Return ledger entries scoped to incident and role
plan.read	Read	Return the IR plan applicable to the incident
template.list	Read	Return holding statement and notification templates
clock.status	Read	Return current state of the 8 regulatory clocks
notification.draft	Draft	Produce a draft regulator notification from a template
statement.draft	Draft	Produce a draft public or customer statement
brief.draft	Draft	Produce a draft executive or board brief
approval.request	Approval	Request human approval on a draft output
approval.status	Read	Check approval state on a previously requested draft

Note what is not on the list: send_email, post_to_social, file_regulator_notification, authorize_payment, close_incident. None of these tools are exposed by the MCP server. They cannot be called by any AI client under any circumstance. External actions are always human-only and bound to the approval ledger.

Prompt injection defense

An AI assistant that ingests untrusted content (incoming emails, supplier disclosures, attacker-controlled documents) faces the risk that injected instructions hijack the AI's behavior. The IR-OS MCP server treats this as a tool-layer problem, not a prompt-layer problem, because prompt-layer defenses are bypassable.

Three defenses operate in parallel. Input segregation: every retrieved content has a source tag (trusted-internal, untrusted-external, attacker-controlled). The AI client must respect the tag, but even if it does not, the server is protected. Capability scoping at the tool layer: even if injected instructions tell the AI to send an email or file with a regulator, the MCP server does not expose those tools. The action cannot happen. Approval bindings: every release-level draft requires a named human approver. A compromised AI client cannot bypass the approval step.

An MCP session in practice

A representative incident-response interaction looks like this. The analyst opens an AI assistant that supports MCP. The assistant connects to the IR-OS MCP server with the analyst's scoped credential. The assistant calls incident.get and ledger.read to load context. The analyst asks "draft the GDPR 33 notification." The assistant calls notification.draft with template id "gdpr-art33." The server returns a draft. The assistant displays the draft. The analyst reviews and asks the assistant to call approval.request. Counsel receives the approval request via the platform. Counsel approves. The approval is recorded in the ledger and bound to the draft hash. The draft is ready for transmission to the supervisory authority through a separate, human-only channel.

At no point in this flow does the AI assistant transmit anything to a regulator. The AI drafts. Humans approve. Humans transmit. The MCP server is the mediation layer.

Multi-assistant cyber-IR

A real incident response team uses more than one AI assistant. The analyst has a personal assistant for daily work. The platform runs its own agents (see the 7-agent architecture). Counsel has a legal research assistant. The board liaison has an executive briefing tool. Each of them needs to read the same incident facts and produce drafts.

Without MCP, each integration is bespoke. With MCP, every assistant connects to the same IR-OS MCP server with a scoped credential. The incident record is the single source of truth. Every AI assistant's tool calls are recorded in the same hash-chained ledger. The defensible record is complete regardless of how many AI tools touched the incident.

Provenance for every MCP call

Every MCP tool call against the IR-OS server is recorded in the ledger as an entry with: the calling identity (user, role, AI client identifier), the tool name, the input hash, the output hash, the timestamp, and any associated approval signature. Read calls are recorded for completeness. Draft calls produce ledger entries that link to the draft text. Approval calls bind a named human signature to an output hash.

The result is a complete provenance record. When a regulator, counsel, or insurer asks "which AI tools touched this incident, what did they read, what did they produce, who approved each draft" the answer is in the ledger. The ledger is hash-chained at SHA-256 granularity. The chain root is published to app.ir-os.com/verify so the AI activity record is independently verifiable.

MCP and NIST AI Risk Management Framework

MCP supports NIST AI Risk Management Framework 1.0 (AI 100-1, January 2023) by making AI tool use visible and bounded. GOVERN is supported by the capability scoping policy enforced by the server. MAP is supported by the tool catalog and source-tagging of inputs. MEASURE is supported by ledger-recorded tool call rates and approval times. MANAGE is supported by the hash-chained provenance and the public verifier.

The Generative AI Profile (NIST AI 600-1, July 2024) raises specific concerns about generative AI: confabulation, data privacy, content integrity. The IR-OS MCP design responds to each: confabulation is mitigated by source-grounded retrieval and approval-bound outputs; data privacy is enforced by tenant isolation and incident scoping; content integrity is preserved by the hash-chained ledger.

Frequently Asked Questions