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 4, 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

Npm lifecycle code silently drops, registers, or rewrites a broad or foreign AI-agent control surface. This block category does not require classic credential theft when the delivery is install-time and unconsented.

// 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.

// 04

AI-agent control surfaces

Agent-control files can grant tools, instructions, permissions, network access, or autonomous actions to an AI system. LPM treats install-time mutation of those surfaces as a separate product-security boundary.

Block

Foreign or broad agent surface

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

Block

Standing agent capability

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

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: foreign or broad unconsented lifecycle mutation blocks. First-party package-owned extension setup warns unless the source proves stronger malicious behavior.

// 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.
// 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 policy is operational, but these external sources inform the trust and consent boundaries used here.

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.