Public policy

What LPM Firewall blocks, warns, and allows.

This page is the public contract for npm package verdicts. It separates classic malware from broader product-security boundaries, including AI-agent control-surface abuse.

Last reviewed July 12, 2026Product-default install policy
// 01

Verdict meanings

Verdicts describe the client-facing install action. They are not all claims of the same kind of malware intent.

Allow

No blocking evidence remains after static analysis, trusted-intel checks, and any required review.

Warn

The package has real risk or unresolved dangerous capability, but the evidence does not meet the default-block bar.

Block

The package version is blocked by default because trusted intel or review evidence crosses a product security boundary.

Manual review

The evidence is contradictory, incomplete, unavailable, or high-impact enough that the system should not finalize automatically.

// 02

Block policies

A block requires trusted malicious identity or concrete behavior that crosses a high-impact security boundary.

trusted_malicious_intel

Trusted malicious advisory

Exact OSV/OpenSSF malicious package identities become product-default block records. If later evidence disagrees, the safer path is a disagreement review rather than automatic clearing.

remote_payload_execution

Remote payload execution

Install or runtime code fetches JavaScript, shell commands, or process input from a remote endpoint and executes it without a package-aligned, user-controlled reason.

credential_or_data_theft

Credential or data exfiltration

The package collects tokens, environment variables, local credentials, source, private data, or cloud metadata and sends it to an unauthorized destination.

persistence_or_destructive_action

Persistence or destructive behavior

The package creates hidden startup hooks, VCS hooks, long-lived background processes, destructive file operations, or other persistence outside normal package behavior.

dependency_confusion_or_typosquat

Dependency confusion abuse

Evidence shows a package identity, version, maintainer, or source bridge is being used to impersonate, replace, or hijack another package.

ai_agent_control_hijack

AI-agent control-surface hijack

LPM Firewall classifies silent install-lifecycle writes into foreign or broad AI-agent control surfaces as a dangerous-capability policy block, not necessarily a malware-intent finding. LPM CLI defaults this Firewall policy to Warn only; users must choose Block when enabling or configuring Firewall to block installs for this finding type. Packages can remediate by moving setup into an explicit user command such as <tool> setup/init.

// 03

Warn policies

Warning keeps real risk visible without pretending every dangerous capability is author-intent malware.

agent_extension_lifecycle_risk

First-party agent extension lifecycle risk

A clearly agent-oriented package writes package-aligned skills, plugins, or handlers only inside its own platform namespace. Silent install-time setup is still risky, but it is warn-only unless stronger malicious behavior appears.

critical_vulnerability

Critical vulnerability without malicious author intent

A legitimate package exposes dangerous functionality such as unauthenticated remote command execution, but the author intent does not appear malicious.

staged_payload_carrier

Inert staged payload carrier

The package ships a suspicious encoded or high-entropy payload, but review does not find a loader or trigger path that executes it.

source_similarity_route

Source-similarity route

Similarity to known-malicious source creates deterministic friction and routes to source-aware review. Similarity alone is not direct block authority.

guarded_dangerous_capability

Guarded dangerous capability

The package has powerful behavior that is visible, documented, package-aligned, guarded, or user-invoked, without covert triggers or unauthorized data access.

uninstall_only_agent_surface

Uninstall-only agent config mutation

A package declares preuninstall, uninstall, or postuninstall scripts that would touch agent configuration, but no preinstall/install/postinstall trigger exists. Modern npm does not run uninstall lifecycle scripts, so this is warn-only unless another malicious chain is present.

// 04

AI-agent control surfaces

Agent-control files can grant tools, instructions, permissions, network access, or autonomous actions to an AI system. LPM Firewall treats preinstall, install, or postinstall mutation of foreign or broad agent surfaces as a dangerous-capability policy block, not necessarily a malware-intent finding.

Block

Foreign or broad agent surface

Preinstall, install, or postinstall code writes project/home/global Claude, Codex, Cursor, MCP, desktop-agent, or other agent-control files without explicit user action.

Block

Standing agent capability

Preinstall, install, or postinstall code registers remote MCPs, auto-@latest tools, long-poll listeners, permission-bypass launchers, or package-supplied instructions into another agent surface.

Warn

Uninstall-only script

Package.json preuninstall, uninstall, or postuninstall scripts are not treated as modern npm registry-install triggers. They warn unless another concrete malicious chain exists.

Warn

First-party extension namespace

The package is clearly an agent platform or extension and lifecycle setup only writes package-aligned files inside its own application namespace.

Allow or low warn

Explicit user command

Setup happens through a visible CLI command such as plugin install, mcp add, or a documented sync command, with no automatic lifecycle mutation.

The short version: LPM Firewall classifies silent install-lifecycle writes into foreign or broad AI-agent control surfaces as blocks, while LPM CLI defaults this Firewall policy to Warn only. Users who want these findings to stop installs must choose Block when enabling or configuring Firewall. Packages can remediate by moving setup into an explicit user command such as <tool> setup/init. First-party package-owned extension setup warns unless the source proves stronger malicious behavior. Uninstall-only scripts warn because modern npm does not run uninstall lifecycle hooks.

// 05

Not enough by itself

These signals may route to AI or create a warning, but they do not automatically become product-default blocks.

  • Native build scripts, prebuild installers, optional platform packages, or node-gyp usage.
  • A critical vulnerability in a legitimate package when author attack intent is not evidenced.
  • Package README, comments, or metadata claiming the package is safe or malicious.
  • Source similarity without a current trusted identity, confirmed payload path, or AI-confirmed block.
  • First-party package-owned agent extension setup inside the package platform contract.
  • Preuninstall, uninstall, or postuninstall scripts without a registry-install trigger or another malicious chain.
// 06

Evidence rules

The scanner should be fast, but the public decision has to preserve authority boundaries.

Static scan is triage

Static findings produce deterministic friction, warnings, and routing decisions. If a routed package needs review, static output does not get treated as source-aware proof by itself.

Trusted intel is sticky

A later static clean does not clear an OSV/OpenSSF or AI-confirmed block. A real disagreement becomes review work, not an automatic allow.

Source similarity routes

Source fingerprints and known-malicious signatures help decide what to inspect next. They do not directly block new package identities without trusted identity or reviewed payload evidence.

// 07

References

LPM Firewall policy is operational, but these external sources inform the trust and consent boundaries used here.

npm scripts: no uninstall lifecycle

Modern npm does not implement uninstall lifecycle scripts, so uninstall-only declarations are not registry-install triggers.

npm v12 install-script security changes

Dependency lifecycle scripts move toward explicit approval instead of automatic execution.

Model Context Protocol specification

MCP identifies explicit user consent, data control, and tool safety as core trust principles.

MCP security best practices

Local MCP configuration and privileged transports require consent, validation, and least privilege.

Claude Code permissions

Agent tooling should run under explicit permission modes, scoped rules, and user-controlled approvals.

OWASP LLM06: Excessive Agency

Agentic systems become risky when tools, permissions, or autonomy exceed the intended task boundary.