Firewall for npm

LPM Firewall checks selected public npm package versions with firewall.lpm.dev before LPM CLI materializes package bytes. Metadata and tarballs still come from the normal npm registry path; the firewall request only asks for a package-version verdict.

The hosted verdict service is an LPM.dev Registry Pro/Org feature. Active modes send LPM.dev Registry auth; run lpm login locally or provide LPM_TOKEN in CI.

Quickstart

lpm login
lpm config firewall --set monitor  # show would-block / warn verdicts
lpm config firewall --set enforce  # block according to the recommended policy profile

off is the default. monitor prints verdicts and lets installs continue. enforce blocks packages whose effective firewall action is block. The legacy string report is still accepted as an alias for monitor, but new config should use monitor.

For guided setup, run the wizard without --set:

lpm config firewall

What gets checked

The firewall runs for eligible public npm package-version rows used by:

• lpm install
• lpm install -g
• lpm fetch
• lpm download
• the source-package download step of lpm add

Private/custom registry packages and LPM.dev Registry packages are not sent to the LPM Firewall verdict API. Integrity-specific evidence can be attached to a verdict, but the fast product path is the package-version lookup.

Modes

When a human-output materialization command has eligible packages to check, its progress line shows 🔥 LPM Firewall active.

CI usage

Firewall checks run for lpm install, lpm ci, lpm fetch, lpm download, and the source-package download step of lpm add. Because the verdict check calls firewall.lpm.dev, an active firewall check cannot run under --offline.

CI can enable the firewall for one command with LPM_NPM_FIREWALL and a Registry token:

- run: LPM_NPM_FIREWALL=enforce lpm ci --strict-integrity
  env:
    LPM_TOKEN: ${{ secrets.LPM_TOKEN }}

For offline replay workflows, run the firewall during the online fetch step instead:

- run: LPM_NPM_FIREWALL=enforce lpm fetch
- run: lpm ci --offline --strict-integrity

Policy groups

LPM CLI receives a default verdict from LPM Firewall, then sends your configured policy profile with the request. LPM Firewall evaluates the profile server-side and returns the user-effective action for each decision.

Choosing enforce in the interactive wizard opens a single policy review screen. Press Enter to accept the recommended profile, or use the arrow keys to change individual groups before saving.

  current: enforce
◇  How should LPM CLI handle LPM Firewall verdicts for npm packages?
│  enforce
│
◆  Review npm firewall enforcement policy
│  Use ↑/↓ to move, ←/→ to change, Enter to save, Esc to cancel.
│
│  › Trusted public malicious advisories
│    OSV / OpenSSF / GHSA
│    ● Block  ○ Warn only  ○ Allow
│
│    LPM Firewall AI-confirmed malware
│    Credential/data exfiltration, RCE, remote payload execution, persistence, dependency confusion
│    ● Block  ○ Warn only  ○ Allow
│
│    LPM Firewall AI-agent control-surface policy
│    Silent install-lifecycle writes into foreign or broad AI-agent control surfaces
│    ○ Block  ● Warn only  ○ Allow
│
│    Critical vulnerabilities
│    Legitimate package risk without malicious author intent
│    ○ Block  ● Warn only  ○ Allow
│
│    Static-only suspicious signals
│    No AI or trusted advisory confirmation yet
│    ● Warn only  ○ Allow
└

The equivalent config lives in ~/.lpm/config.toml:

[firewall]
mode = "enforce"

[firewall.npm.policies]
trusted_public_malicious_advisories = "block"
lpm_ai_confirmed_malware = "block"
lpm_ai_agent_control_surface = "warn"
critical_vulnerability = "warn"
lpm_ai_suspicious = "warn"

If lpm_ai_suspicious is absent, LPM CLI accepts the legacy static_only_suspicious key. The firewall editor writes the canonical lpm_ai_suspicious key.

Use lpm config firewall in an interactive terminal to choose:

• Off
• Monitor only
• Enforce, then review the policy profile

The wizard writes the policy table only when the chosen profile differs from the default profile, or when an existing policy table needs to be updated.

AI-agent control-surface policy

LPM Firewall flags silent install-lifecycle writes into foreign or broad AI-agent control surfaces because a transitive npm install should not mutate another agent's skills, commands, hooks, MCP config, or startup surface without an explicit user command. The recommended profile warns by default; teams that want stricter containment can set this group to block.

This policy is version-scoped and remediable. A package can move setup into an explicit command such as <tool> setup or <tool> init, then the changed version can be evaluated under a weaker action. See firewall.lpm.dev/policy for the public policy text.

Monitor and JSON output

In monitor mode, LPM CLI never blocks installs. If LPM Firewall returns an effective block, human output says it would block and the command continues.

When JSON output includes firewall decisions, each decision can include optional policy and authority metadata:

{
  "action": "block",
  "verdict": "malicious",
  "policy": {
    "group": "lpm_ai_agent_control_surface",
    "key": "ai_agent_control_surface",
    "intent": "dangerous_capability",
    "default_action": "warn"
  },
  "authority": {
    "source": "lpm_ai",
    "source_type": "lpm",
    "external_intel": false
  }
}

Older firewall records can omit policy and authority. Those records fall back to the plain verdict behavior.

See also

• lpm config — interactive and non-interactive setup
• CI/CD setup — token example
• ~/.lpm/config.toml — exact config keys
• lpm install — install-time behavior
• Public firewall policy