Skip to main content
Glama
Infraveil MCP server

Infraveil MCP server

Official
by infraveilhq

Infraveil MCP server

A hardened, self-hosted Model Context Protocol server that lets your own AI agent query and govern your Infraveil control plane in-loop — read the governed state of your backend, and file deploy and remediation requests that always pass through human approval.

It is built on the same principle as the rest of Infraveil: trust by inspection, not assertion. This server adds no new authority and no new auth surface. It signs every request with the token your agent already holds, and it verifies the control plane's signed responses in return — so neither side can be forged on the wire. You can read every line here and diff the signing code against the published agent source; they are the same scheme.

Why this exists

The MCP ecosystem's security is, bluntly, bad — most public MCP servers require no auth at all. An MCP server that hands an AI agent operational reach into your backend is exactly the thing that should not be unauthenticated. This one:

  • Signs both directions (HMAC-SHA256 over a canonical request/response, keyed by your per-agent token; nonce + timestamp replay protection).

  • Cannot apply a change by itself. request_deploy and remediate enqueue a request into the control plane's human-approval queue and return the approval URL. There is no code path here that mutates your infrastructure.

  • Is least-privilege. The token is scoped to one client/agent; tenancy is enforced by the control plane. This process holds no more authority than the agent already running on the host.

Related MCP server: ops-copilot-mcp

Install

pip install infraveil-mcp

Configure

The server reuses your existing Infraveil agent identity — it never mints credentials. Either set the environment variables:

export INFRAVEIL_BASE_URL=https://api.infraveil.com
export INFRAVEIL_CLIENT_ID=...
export INFRAVEIL_AGENT_ID=...
export INFRAVEIL_AGENT_TOKEN=...        # your agent's existing token

…or point it at your rendered agent source and let it read the ids and token straight out of the file you can already inspect:

export INFRAVEIL_AGENT_FILE=/opt/infraveil/agent.py

Claude Desktop / Claude Code

{
  "mcpServers": {
    "infraveil": {
      "command": "infraveil-mcp",
      "env": {
        "INFRAVEIL_BASE_URL": "https://api.infraveil.com",
        "INFRAVEIL_CLIENT_ID": "...",
        "INFRAVEIL_AGENT_ID": "...",
        "INFRAVEIL_AGENT_TOKEN": "..."
      }
    }
  }
}

Tools

Read (no side effects):

Tool

What it returns

get_agent_status

Fleet/agent state: online/offline, heartbeats, CPU/mem/disk, deploy state

get_security_findings

Active security policy + recent security events

get_request_trace

Recent request/operation traces and outcomes

query_runtime_truth_graph

Authoritative host ↔ agent ↔ service ↔ policy snapshot

Governed (enqueue for human approval — never auto-applied):

Tool

What it does

evaluate_deploy_gate

Reports whether a proposed change would pass policy. Read-only.

request_deploy

Files a deploy request into the approval queue; returns request id + approval URL

remediate

Files a remediation proposal (respects your blocked categories); returns id + approval URL

Verify it yourself

  1. Read infraveil_mcp/client.py. The request-signing and response-verification code is plain stdlib hmac/hashlib.

  2. Diff it against the published Infraveil agent source (_signed_headers, verify_response_signature). They implement the same protocol.

  3. Run the test suite: pytest tests/. It transcribes the server's verifier and asserts this client's signatures are accepted and tampering is rejected.

License

AGPL-3.0-or-later. The control plane (central authority graph, multi-tenant policy, audit/evidence store) is the commercial product; the code that runs on your machine is open because you should never have to trust code you can't read.

Available Tools

7 tools
evaluate_deploy_gateA

Evaluate the deploy gate WITHOUT requesting a deploy: returns whether a proposed change would pass policy, and which checks gate it. Read-only — use this to reason before calling request_deploy.

summary: optional human description of the intended change.

Inputs: summary. Returns: result

get_agent_statusA

Current runtime status of this client's fleet: agents, launcher hosts, online/offline state, recent heartbeats, CPU/memory/disk, and deploy state. Read-only.

Inputs: no named parameters. Returns: result

get_request_traceA

Recent request/operation traces the control plane recorded for this client's agents — what was proxied, what was acted on, and the outcome. Read-only.

limit: max number of trace entries (1-200).

Inputs: limit. Returns: result

get_security_findingsA

Active security policy plus the most recent security events (blocked IPs, threat scores, pipeline findings) for this client. Read-only.

limit: max number of recent events to return (1-500).

Inputs: limit. Returns: result

query_runtime_truth_graphA

A snapshot of the runtime truth graph: the authoritative relationships between hosts, agents, deployed services, and the policies governing them. This is the governed reality your agent should reason about before acting. Read-only.

Inputs: no named parameters. Returns: result

remediateA

Request remediation of a security finding or incident. Respects the client's blocked_categories and is human-approval-gated: it enqueues a remediation proposal, never auto-applies. Returns the proposal id and approval URL.

finding: id or description of what to remediate (required). action: 'propose' (default) to queue a proposal for approval.

Inputs: finding (required), action. Returns: result

request_deployA

Request a deploy. This does NOT deploy — it enqueues a deploy request into the control plane's human-approval queue and returns a request id plus the approval URL a human must visit to approve. This server cannot apply a deploy on its own.

summary: short description of what to deploy / why (required). details: optional longer context for the human approver.

Inputs: summary (required), details. Returns: result

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.4/5.0

    Scored across 7 tools

    Disambiguation5/5

    Each tool has a distinct purpose: policy evaluation, fleet status, trace retrieval, security events, truth graph, remediation proposal, and deploy request. No overlap in functionality.

    Naming Consistency5/5

    All tool names follow a consistent verb_noun pattern in snake_case, such as evaluate_deploy_gate, get_agent_status, and request_deploy.

    Tool Count5/5

    With 7 tools, the server is well-scoped for infrastructure management, covering monitoring, policy evaluation, and gated actions without being excessive.

    Completeness4/5

    The tools cover core workflows: status queries, policy checks, security findings, and action requests. Minor gaps exist (e.g., no cancel or direct management), but the set is comprehensive for a control plane.

    Maintenance

    ActivityNo data
    ResponsivenessSyncing

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      An MCP server that enforces runtime governance on AI agent actions — file access, command execution, delegation chains, and permission escalation.
      MIT
    • F
      license
      A
      quality
      D
      maintenance
      A self-hosted MCP server providing a governed interface for AI agents to interact with local Docker infrastructure, featuring a two-phase confirm protocol for state-changing operations and append-only audit logging.
      4
      -
    • A
      license
      C
      quality
      D
      maintenance
      A policy-aware MCP server for GitHub and GitHub Actions that enables safe AI-assisted infrastructure workflows—inspecting repositories, preparing branches and pull requests, and constrained remote mutations behind explicit preview-bound approval tokens.
      18
      MIT