Supply-Chain Guard package registry interception workflow
Agentic DLP

Supply-Chain Guard: DLP for the package install

The same endpoint that protects prompts and files has to protect package installs. A malicious package can read secrets, call home, and poison CI before a ticket exists. Supply-Chain Guard stops the risky version in flight and records what postinstall scripts do next.

RRR Security Team May 22, 2026 8 min read

Package managers used to feel like developer plumbing. They are now an enforcement point. A compromised maintainer account, a typo-squatted package, or a fresh dependency with a hostile postinstall script can move faster than advisory scanners, ticket queues, and manual approval workflows.

That is why Supply-Chain Guard is one of RRR's Agentic DLP proof pillars. DLP cannot stop at browser prompts. AI coding agents, CI runners, local CLIs, package managers, and model installers all move data and credentials. The control has to live where the install happens.

The short version: RRR intercepts npm and PyPI registry traffic through the local OS agent, checks signed malicious-version verdicts, applies org policy, and correlates package fetches with postinstall child processes, network egress, and sensitive file reads.

Why advisory-only controls miss the window

Traditional dependency security tools are useful, but most are advisory. They scan after a lockfile changes, after a pull request opens, or after a database learns about an incident. That leaves a gap during the exact moment attackers care about: the first install of the bad version on a developer laptop or build runner.

Modern install paths also bypass the clean boundaries older tools assume. A package install may be triggered by a human, an AI coding assistant, a bootstrap script, a GitHub Action, or a transient CI container. If a postinstall script reads ~/.npmrc, touches cloud credentials, or opens a network connection, the package registry proxy alone cannot tell you which process did it.

What Supply-Chain Guard adds

Inline verdicts

Registry requests are normalized to package and version before bytes hit disk.

Process provenance

Package-manager roots and descendants are tied to install sessions.

CI identity

Runner telemetry uses repository, workflow, run, job, commit, and ref context.

The agent does not host a private registry mirror and it does not rewrite lockfiles. It uses the local TLS inspection path already present in the OS agent. That means the control can ship without a new proxy fleet, hosts-file rewrites, or package-manager-specific network configuration.

The decision path

Every package fetch is reduced to a canonical identity. npm scoped packages keep their @scope/name form. PyPI names follow normalized package-name semantics. Private registries are represented by configured aliases, not full private URLs.

package request -> canonical ecosystem/name/version -> signed package verdict snapshot -> org policy and allowlist -> monitor, warn, block, or allow telemetry

Known malicious versions come from server-side verdict snapshots. The agent rejects missing or invalid signatures and follows fail-open defaults for monitor mode, stale caches, parser failures, and unavailable attribution. Block mode is reserved for high-confidence verdicts or explicit org policy matches.

The part a proxy cannot do

Registry gating is only half of the problem. The more important question is what happens after install. Supply-Chain Guard tags package-manager sessions and applies elevated scrutiny to descendants during the risky postinstall window.

v1 is intentionally conservative. It records suspicious postinstall behavior and does not run uninstall or rollback commands. Platform-level kill or deny is enabled only when the platform adapter can prove a safe enforcement primitive.

Monitor first, then enforce

Supply-chain controls need a rollout path. RRR starts in monitor mode so teams can build an observed package inventory, learn private registry aliases, and tune allowlists before blocking. Business-tier organizations can move to warn or block. Free and Professional organizations stay monitor-only; Free package telemetry is retained for 7 days.

That split is deliberate. Everyone should be able to see package risk. Enforcement should be turned on only when the organization is ready to own bypass workflows, incident review, and CI build-failure behavior.

Why this belongs in Agentic DLP

Agentic DLP is not just "DLP with an AI label." It is the control plane for humans, non-human identities, local agents, SaaS accounts, and package installers. Supply-Chain Guard closes a path legacy DLP rarely sees: a trusted developer tool pulling a hostile artifact from a legitimate registry.

The practical win is simple. Security sees the package, version, decision, endpoint, runner, process, and postinstall behavior in one place. Developers get a readable block reason and a bypass path when policy allows it. CI gets repository-native attribution instead of a fake developer user.

See the architecture

The implementation guide covers policy sync, verdict snapshots, CI runner mode, privacy boundaries, and the current platform capability matrix.

Read the Supply-Chain Guard docs