Model Context Protocol (MCP)

What Is Model Context Protocol (MCP)?

Model Context Protocol (MCP) is the protocol FireMon's MCP Server uses to connect customer-managed AI applications to FireMon's policy data and supported operations. The external application calls FireMon-supplied tools, such as searching records or preparing a Policy Plan change, while access stays limited to the FireMon user's existing permissions.

Key takeaways

• The FireMon MCP Server uses Model Context Protocol (MCP) to bring selected FireMon policy data and supported operations into customer-managed AI applications.
• The initial tool catalog includes 16 tools spanning search, discovery, recommendations, change preparation, and authorized saving.
• Access follows the FireMon user's Personal Access Token, which carries that user's role and device-group permissions and has no independent scope.
• MCP isn't read-only and has no direct firewall-deployment operation; saving a prepared change to Policy Planner isn't the same as deploying it.

Why Model Context Protocol Matters for Network Security Teams

Security teams increasingly build or use AI applications outside FireMon, from incident-response tools to internal assistants, that need network security context to be useful. Without a controlled way to supply that context, someone has to gather policy records and transfer them manually into those workflows, one request at a time. That manual step slows investigations and makes it easy for incomplete context to lead to missed dependencies or unnecessary access.

MCP addresses that gap. It's the protocol the FireMon MCP Server uses to expose selected, governed policy data and supported operations to a customer-managed AI application, so that application's own model can work with current policy evidence instead of a manual export.

How FireMon's MCP Server Works

The external AI application works with its own model and invokes FireMon's tools through a compatible MCP client. FireMon supplies the endpoints, the tools, and the authorization behind them. At launch, the tool catalog includes 16 tools covering search, discovery, recommendations, change preparation, and authorized saving, including tools such as Execute SiQL Search and Save Policy Plan Change.

Access doesn't come from the application or its model. It follows the identity of the FireMon user whose Personal Access Token the application uses. MCP applies the same underlying permission checks as FireMon's REST APIs, including applicable role and device-group restrictions, and a token carries no independent scope of its own. A dedicated account without change-writing permissions can therefore restrict an external workflow to authorized analysis only. Insights is required to configure MCP for Security Manager and Workflow, and Policy Planner is required for any change workflow.

A Realistic Example

Consider a security incident investigation running in an external, customer-managed AI tool. That tool can combine its own alert information with policy records retrieved through Execute SiQL Search over MCP, bringing network security evidence directly into the investigation instead of requiring someone to collect and paste in each record by hand. The returned records support the analysis; they don't, by themselves, establish the full scope of the incident. A practitioner still has to interpret what the evidence shows.

The Operational Consequence

Because MCP operates under delegated permissions rather than a single universal review gate, what it's allowed to do depends entirely on how a customer configures access. An access workflow can convert selected recommendations into staged Policy Plan changes, and with the right permissions, Save Policy Plan Change persists that work into Policy Planner. That's a save, not a deployment: the catalog exposes no operation that pushes a change directly to a firewall. Teams get real capacity back from not having to hand-carry policy evidence between systems, but they still own the decision about what gets written and what doesn't.

Key Components and Best Practices

• Personal Access Token (PAT): Each MCP request runs as the FireMon user who owns the token, inheriting that user's role and device-group permissions.
• Scoped accounts: Provisioning a dedicated account without change-writing permissions limits an external workflow to authorized analysis.
• Insights and Policy Planner: Insights is required to configure MCP for Security Manager and Workflow; Policy Planner is required for any workflow that prepares or saves changes.
• Tool catalog: FireMon adds new tools to the MCP catalog on a regular basis, expanding what external workflows can search, analyze, and prepare over time.

Common Challenges

Teams sometimes assume MCP is read-only, but it isn't: with the right permissions, it can prepare and save Policy Plan changes. Others assume the review-before-save sequence built into the pre-built Policy Change Designer workflow applies automatically to every MCP operation; it doesn't, which is why customers need to define their own permissions and workflow controls for each intended use. It's also worth remembering that model choice and scoped access don't by themselves establish data residency, retention terms, or regulatory compliance.

How MCP Connects to Network Security Policy Management and FireMon

MCP is one of three ways FireMon customers can put agentic AI to work on policy, alongside using supplied agents and building custom agents in Agent Builder. Where those two options run inside FireMon, MCP is the path for connecting external, customer-managed AI applications to the same governed policy data and tools. FireMon, the founder of NSPM, built MCP as an extension of that governance model, so policy evidence can reach outside workflows without giving up the role-based permissions and workflow controls that keep policy changes under practitioner control.