YAML policy rules for MCP and package drift

Inventory without policy is a log file. Koban Fleet closes the loop with YAML rules evaluated against each snapshot diff.

Rule categories that matter first

Most teams start with three rule types:

MCP allowlists

Flag any MCP server not on an approved list. After the Bitwarden CLI npm incident on April 22, 2026, which harvested Claude and MCP config files from infected hosts, this is often the first rule security teams ask for.

Package denylists

Match package names against a denylist updated after registry incidents. Examples from 2025-2026 include packages swept up by Shai-Hulud and the plain-crypto-js dependency from the March 2026 axios compromise.

Version drift

Alert when a pinned dependency jumps major versions without a corresponding ticket, or when @latest resolution appears in an MCP npx invocation.

How evaluation works

On each heartbeat:

1. The agent sends a signed snapshot of parsed inventory
2. Fleet diffs against the previous snapshot for that Mac
3. Rules run against new or changed entries (not the entire history every time)
4. Matches route to configured notification channels

Rules are plain YAML: readable in code review, version-controlled, and auditable.

Example intent (illustrative)

# Alert on MCP servers outside allowlist
mcp_servers:
  allow:
    - "@modelcontextprotocol/server-github"
    - "company-internal-mcp"
  on_violation: alert

# Deny known-bad npm package names
npm_packages:
  deny:
    - "plain-crypto-js"
  on_violation: alert

Exact schema and operators are documented in Fleet rules.

Start narrow

The mistake is writing fifty rules on day one. Start with MCP allowlists and one package denylist tied to a recent incident your team already cares about. Expand when alerts are actionable, not noisy.

Visibility plus policy beats visibility alone, and beats blocking that agents bypass anyway.