Policy Evaluations
The Policy Evaluations tab is an audit log of every package request that flowed through Secure Registry, across all supported ecosystems, with the evaluation result for each enabled control. Use it to confirm that requests are flowing through Secure Registry, to investigate why a specific install was blocked or modified, and to trace a request back to the developer machine or CI run that made it.
Filters
Filters at the top of the page let you narrow the log:
Status: filter by evaluation result (Allowed, Modified, Blocked).
Ecosystem: filter by ecosystem
Type: request type (Metadata, Tarball Download).
Source: filter by where the request originated (Developer Machine or GitHub Actions).
Package: exact package name (e.g.,
lodash).Versions: comma-separated versions (e.g.,
4.17.21,4.17.20).Identifier: filter by a specific source identifier.
Date range: narrow to a specific time window.
Statuses
Allowed
The request matched no blocking controls and was served as-is.
Modified
One or more controls filtered the response. Most commonly, Cooldown removed one or more recent versions before returning metadata, so the client sees only versions older than the cooldown window.
Blocked
A control blocked the request. The package version was not served. This is the result when Compromised Packages, Typosquatting Protection, or a Tarball Download inside the cooldown window matches the request.
Skipped (per-control)
The control was not evaluated for this request, either because it is disabled in the Policy tab or because it is not yet available.
Modified vs Blocked example
The difference comes down to which request the control acts on.
When a client installs a package (for example, npm install axios), it first requests the package's metadata, which lists every published version. Secure Registry filters that response before returning it, removing any versions that are inside the cooldown window or flagged as compromised. Because the response was changed rather than refused, the evaluation is logged as Modified. From the client's perspective the filtered versions simply don't exist, so it resolves to the latest safe version and the install proceeds normally.
If a client directly requests a disallowed version (for example, npm install axios@<version> where that version is in cooldown or compromised), or downloads its tarball, there is nothing to filter because the request itself targets a disallowed version. Secure Registry refuses to serve it and the evaluation is logged as Blocked.
Request types
Metadata: a request for package metadata (for example,
npm view, or dependency resolution during install).Tarball Download: a request for the actual package tarball during install.
Source attribution
The Source and Source Identifier columns show where each request originated, so you can trace any evaluation back to the developer machine or CI run that made it. This requires the source identifier to be configured in your client setup; see Setting up source attribution on the Setup Guide. Requests from clients that do not send an identifier still appear in the log but are not attributed to a specific device or workflow run.
Developer Machine
The device page for that machine, filtered to its Device ID. From there you can inspect the device's installed IDE extensions, AI agents, MCP servers, OSS packages, and suspicious files.
GitHub Actions
The Harden-Runner workflow run that made the request, where you can review its outbound network destinations, file write events, and detections.
Clicking a Source Identifier value opens the linked page, which lets you pivot directly from a blocked or modified install to the full context of the machine or workflow run behind it. For example, if a developer machine triggered a blocked install of a compromised package, you can open its device page to see what else is running on that machine.
Follow this interactive demo to see how it works in practice:
Per-control breakdown
Click any row to expand the per-control breakdown. For a Modified request, the breakdown shows which control modified the response and the reason (for example, "2 version(s) filtered by cooldown period"). For a Blocked request, the breakdown shows which control blocked it and why.
Last updated
Was this helpful?