Technical Overview

1. The Short Version

• Vigilance is a small program on each computer. Package managers on that computer get their package lists through it, on the loopback address 127.0.0.1.
• For each package version, it asks our service for a verdict. A verdict is a fact about a public package version. It is the same for every customer.
• Our service compares each new version of a package with the version before. It looks for a file that gained a power. A power is something a file can do, such as reach the internet, run a program or read saved passwords.
• If a version gained a harmful power, the package manager does not see that version. It installs the last safe version. On a paid plan, Vigilance tests that version in the project first.
• Package files still come from npm, PyPI or your own registry, unchanged. Your code and files stay on the computer.

2. Where It Sits

Vigilance installs per user. It needs no admin rights, no kernel driver, no root certificate and no network proxy. It opens no port to the network.

• The local filter. A background program starts at login and listens on 127.0.0.1. It speaks the npm and PyPI registry formats.
• Routing. The installer points npm, pnpm, yarn, bun, pip and uv at the local filter, in each person's own settings files. It keeps a copy of each file it changes, so it can put the old settings back.
• AI tool hooks. The installer adds a hook to each AI coding tool it finds. The hook sees an install command before it runs. It sends commands that name another package server through the same check.
• The watchdog. A second small program checks the filter every minute. If the filter stops, the watchdog puts the old package settings back within about 2 minutes.

Each computer talks to one Vigilance host: check.vigihq.com, TCP port 443, over HTTPS. Your IT provider can test the path with netcheck. Our ready email for IT providers is on Email for Your IT Provider.

3. What Happens on an Install

1. A person or an AI tool runs an install, for example npm install express.
2. The package manager asks the local filter for the version list of each package. That includes the dependencies of dependencies.
3. The filter gets the list from the real registry. It looks up the verdicts for that package. It sends a 4-character code, not the package name. Dozens of names share each code. The answer is a signed file of verdicts for all of those names.
4. If a version has a harmful verdict, the filter removes it from the list and moves the "latest" tag. The package manager then picks the newest safe version on its own.
5. If a public version has no verdict yet, the filter sends its name and version to our service and waits for the check. The service checks each version once, for every customer.
6. The package manager downloads the files from the real registry, as it did before.

A package name that is not public, such as your company's own scoped package, never leaves the computer. The full list of fields and how long we keep each one is on What Leaves the Computer.

4. How a Version Is Judged

Our service fetches the new version and the version before from the public registry. It compares them file by file. It asks one question. Did a file gain a power that the version before did not have?

• It looks at what a file does, not at words it contains. A file that prints curl | sh in its help text gains no power. A file that starts a shell and connects it to the internet does.
• Most updates gain no power. Those versions are safe, and Vigilance stays quiet.
• An update that gains a power is not always bad. A finding we are unsure of is held and reported. It is never cleared on a guess.
• The check needs no advisory, no CVE and no known bad file. That is how we flagged @apexacc/cli the day it shipped, when 0 of 63 virus scanners flagged its helper file.

We do not publish the list of powers, the rules that find them or how we keep false alarms down. That work is patent pending.

5. Why We Find What Others Miss

Most tools ask one question: is this version known to be bad? Vigilance asks a different one: which powers does this version have that the version before did not have?

Lists find an attack only after someone reports it

CVE scanners, advisory feeds, threat feeds and antivirus all match a version or a file against a list. A hijacked update is new on the day it ships, so no list has it yet. Every install before the report passes the check. Vigilance needs no list, so it can flag the update on its first day.

A package checked alone is either noisy or blind

A scanner that reads one version by itself sees every power the package has. A real HTTP client reaches the internet in every release. A real build tool runs programs in every release. The scanner must flag those packages every time or tune the rule down until it misses the attack. Vigilance compares each version with the version before. A power the package always had is not news. Only a power it gained counts.

A trusted name is not a safe version

Many attacks ship from a real maintainer's account after it was stolen. Download counts, account age, stars and a known publisher all look normal. Vigilance does not use any of them. It judges each version from its files alone, so a hijacked release from a trusted name gets the same check as a release from a stranger.

One finding, only when it is real

A tool that alerts on every update gets ignored. Vigilance stays quiet on updates that gained no power, which is most of them. It points to the one file that gained a power and names that power. A false alarm is a bug that we fix in the rules, for every customer at once.

The proof

@apexacc/cli 1.5.122 went live on npm on 17 September 2026. It turned off Windows Defender and ran commands from a server. Vigilance flagged it eleven hours later, before any advisory existed. When we checked, 0 of 63 virus scanners flagged its helper file. Read advisory VIGI-001-2026 and the comparisons with other tools.

6. Swaps and Blocks

A swap moves a project to the last safe version of the same package. It never moves to a different package without a yes.

• On a new install, the package manager never sees the bad version, so it installs the last safe one.
• When a lockfile pins the bad version, the download gets an HTTP 403 with one plain sentence. The sentence names the safe version. npm, pnpm, pip and uv show it word for word, so an AI tool can read it and act on it.
• On Done With You and Done For You, Vigilance writes the change, runs a smoke test of the project and keeps the change only if the test passes. No person approves each swap. The builder gets one line.
• On Do It Yourself and in the free watch, Vigilance makes no swaps. It checks, counts and explains.

When a package has no version older than 90 days, Vigilance can suggest an established package that does the same job. A suggestion takes effect only after a yes.

7. Packages Already Installed

At install, Vigilance reads the lockfiles in each code folder once. It counts the packages that were already on the computer. This is the first look.

It keeps that list on the computer. When a version on the list turns bad later, Vigilance warns you on a paid plan.

8. What the Service Learns

• Most lookups send a 4-character code, not a package name.
• A public name and version leave the computer only when nobody has checked that version yet. That request carries no credential.
• Counts of different packages use count codes. A count code is made from a secret for your company, so we can count packages without knowing their names.
• Each computer has a random device id and a two-word name. No request names a person, an app or a project.
• We write no log line with an IP address or a device credential.

A test in our code fails the build if a request gets a field that is not on What Leaves the Computer. Our server refuses any request with a field it does not know.

9. Signed Records

• Every verdict file, control file and plan answer is signed with Ed25519. Vigilance checks each signature before it uses the record.
• The online signing keys stay inside AWS KMS. A root key signs the list of online keys. It stays in a separate AWS account that runs nothing else.
• Each program update is signed. Vigilance checks the signature and the file hash before it runs an update.
• Each readout carries the hash of the one before it. Anyone can check a readout with our public keys at check.vigihq.com/v1/keys.

10. When Something Fails

• If our host does not answer within about 1 second, Vigilance uses its last saved verdicts. It uses them for up to 7 days after its last signed control file expired.
• With no saved verdicts, or after those 7 days, the install goes ahead. Vigilance counts it as unchecked.
• If a signature check fails, Vigilance treats it as no answer.
• If the program on a computer stops, the watchdog puts the old settings back within about 2 minutes. We email you the same day.
• We can pause every change, or let every install run unchecked, within about 6 minutes, for every company at once. We can roll the verdict library back one edition in the same time.

The full list is on Security at Vigilance.

12. What It Does Not Cover

• Apps built only in a cloud workspace, such as cloud agents.
• Computers that did not join, and Linux computers.
• cargo, go, gem, Homebrew, conda and Poetry, and scripts piped to a shell. These installs pass unchecked.
• Project or environment settings that point a package manager away from Vigilance.
• Your own code. Vigilance checks public packages, not the code your staff write.

We list these gaps on every readout. When a gap opens on a computer, we email you the same day.

Questions from an engineer or an IT provider go to support@vigihq.com. A person reads every one.