Skip to main content
Glama
fquiroga

Panorama MCP Server

by fquiroga

Panorama MCP Server

A read-only Model Context Protocol server for Palo Alto Panorama policy review.

The server is intentionally narrow:

  • reads security rules through the PAN-OS XML API;

  • normalizes rule fields into deterministic sets;

  • finds exact duplicates, broader coverage, conflicts, and partial overlaps;

  • returns evidence and a preclear decision;

  • never commits to Panorama or pushes to managed firewalls.

This is a companion implementation for the blog post Running Palo Alto Panorama MCP Servers. It is not an official Palo Alto Networks product.

Prerequisites

  • Python 3.11 or newer.

  • Network access from the server host to Panorama management HTTPS.

  • A dedicated read-only Panorama API administrator or service account.

  • An API key injected through a secret manager or a protected environment.

  • A lab or non-production device group for the first rollout.

Do not use a superuser key. Do not disable TLS verification in production.

Install

Using uv:

cd panorama-mcp-server
uv venv
source .venv/bin/activate
uv pip install -e '.[dev]'
cp .env.example .env

Using pip:

python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install -e '.[dev]'
cp .env.example .env

Set the required values in .env:

PANORAMA_URL=https://panorama.example.net
PANORAMA_API_KEY=the-read-only-key
PANORAMA_VERIFY_TLS=true
PANORAMA_DEVICE_GROUP=shared
PANORAMA_RULEBASE=pre-rulebase

The API key is passed only to the outbound Panorama request and is never included in tool results or application logs.

Run the server

For a local MCP client using stdio:

panorama-mcp

For a development Streamable HTTP endpoint:

panorama-mcp --http

The official MCP Python SDK serves Streamable HTTP at the SDK default endpoint. Confirm the exact endpoint and authentication requirements in the MCP host before exposing it beyond localhost. This project does not add HTTP authentication; put a remote deployment behind an authenticated gateway and network policy.

Example local client configuration:

{
  "mcpServers": {
    "panorama-readonly": {
      "command": "/absolute/path/to/panorama-mcp-server/.venv/bin/panorama-mcp",
      "env": {
        "PANORAMA_URL": "https://panorama.example.net",
        "PANORAMA_API_KEY": "injected-by-the-client-secret-manager"
      }
    }
  }
}

Do not put a real API key in a committed client configuration.

Available tools

list_device_groups

Lists the device groups visible to the configured API key.

get_security_rules

Reads and normalizes security rules from one device group and rulebase.

Arguments:

{
  "device_group": "shared",
  "rulebase": "pre-rulebase"
}

search_policy_coverage

Accepts a normalized request and returns exact duplicates, broader coverage, conflicts, and partial overlaps.

Example request:

{
  "device_group": "shared",
  "rulebase": "pre-rulebase",
  "source_zones": ["app"],
  "source_addresses": ["reporting-subnet"],
  "destination_zones": ["data"],
  "destination_addresses": ["postgres-prod"],
  "applications": ["postgresql"],
  "services": ["service-postgresql"],
  "action": "allow"
}

preclear_rule_request

Runs the deterministic policy comparison and returns:

  • blocked when an exact duplicate, broader same-action rule, or conflict is found;

  • review-required when there is only a partial overlap or no matching rule;

  • the matching rule, position, classification, and reason;

  • explicit unknowns for candidate changes, locks, and commit queue state.

The unknown operational checks are deliberate. This first version does not pretend that a read of the rulebase proves that no administrator is changing Panorama. Collect those checks through your approved change-management integration before allowing a write workflow.

Implementation steps

  1. Create a dedicated read-only Panorama account scoped to the device groups the agent needs.

  2. Generate the API key using the organization’s approved secret-management process.

  3. Deploy this server close to Panorama, with egress limited to the Panorama management URL.

  4. Run the tests and verify the server with MCP Inspector or your MCP host.

  5. Test duplicate, broader coverage, conflict, partial overlap, out-of-scope, and API failure cases against a lab.

  6. Add an audit sink that records request IDs, user identity, tool name, scope, result classification, and Panorama task IDs without secrets.

  7. Keep this server read-only while tuning false positives and false negatives.

  8. Add candidate writes only in a separate service, with separate credentials, human approval, change ID, preview, validation, commit, and push gates.

Security model

This project intentionally does not expose arbitrary XML, arbitrary XPath, commit, push, or delete tools.

Recommended production controls:

  • use a read-only API role and separate credentials for mutation;

  • keep TLS verification enabled;

  • pin dependencies and verify the container image;

  • run as a non-root user with a read-only filesystem;

  • restrict outbound network access to Panorama;

  • do not log API keys, authorization headers, cookies, or full XML that may contain sensitive data;

  • treat rule descriptions, tags, and object names as untrusted data;

  • require deterministic server-side checks before any future write;

  • keep candidate commit and firewall push as separate approved actions;

  • test rollback and audit procedures in a lab.

Docker

Build and run locally:

docker build -t panorama-mcp-server ./panorama-mcp-server
docker run --rm -i \
  --env-file panorama-mcp-server/.env \
  panorama-mcp-server

For a shared HTTP deployment, do not publish port 8000 directly to a management network. Use an authenticated reverse proxy, HTTPS, network policy, and short-lived credentials.

Test and lint

pytest -q
ruff check .

The tests are offline and do not contact Panorama. An integration test suite should use a disposable lab or a mocked HTTP transport with sanitized XML fixtures.

Limitations

  • The project supports PAN-OS XML API rule reads only.

  • The device-group XPath assumes a standard Panorama configuration tree.

  • Candidate changes, locks, and commit queue state are returned as explicit not-collected values.

  • No configuration mutation, commit, push, delete, or arbitrary command execution is exposed.

  • Object-group expansion is not performed by this version; unresolved object semantics must remain review-required.

References

  • Palo Alto Networks: Panorama Commit, Validation, and Preview Operations

  • Palo Alto Networks: About the PAN-OS API

  • Model Context Protocol: Security Best Practices

  • Model Context Protocol Python SDK