What Leaves the Computer

1. The Short Version

• Each computer talks to one Vigilance host: check.vigihq.com, on port 443.
• Most lookups send a 4-character code, not a package name. Dozens of package names share each code. A bucket is the signed file that lists every public package name with one code, and the verdicts we hold for them.
• Our library is the list of verdicts we hold about public package versions. Each edition of it has a number.
• The first look is a single read of the package lists in your code folders, at install. It counts the packages that were already on the computer.
• A package name and version leave the computer only when the package is public and nobody has checked that version yet.
• Each computer has a random device id and a two-word name, such as "blue otter". Its credential goes with three kinds of request only: a daily check of your plan, the counts, and a same-day event.
• The counts arrive for each computer. Your report shows each computer by its two-word name. No request names a person, an app or a project.
• Different packages are counted with count codes. A count code is made from a secret for your company, so we can count different packages without knowing their names. We do not look at the codes. Every use of that secret writes an audit record.
• We write no log line with your IP address or a device credential.

2. The One Host

Vigilance on each computer talks to one Vigilance address: check.vigihq.com, TCP port 443, over HTTPS. Requests go to Amazon CloudFront, and from there to our servers in AWS Canada (Central).

Vigilance never opens a port to the network. It listens on the computer's own loopback address, 127.0.0.1, so npm, pnpm, yarn, bun, pip and uv on that computer can use it.

The computer still talks to the package registries, as it did before Vigilance: registry.npmjs.org, pypi.org and files.pythonhosted.org, or your company's own registry. Package files come from those registries unchanged. Vigilance does not host or change package files.

If an install command names another package server, Vigilance sends that command through its check too, with that server as the source. Nothing is stopped. The address of that server stays on the computer.

Only with the optional Claude plugin: Claude Code fetches the Vigilance plugin from check.vigihq.com too, as it fetches any Claude Code plugin (request 9).

5. The Whole-Computer Watch

On Done For You, Vigilance also checks the apps installed on each computer. This is the one place where an app name leaves the computer. The counts payload then fills the whole_computer field:

Sample. The numbers and names are made up.

"whole_computer": {
  "apps_seen": 212,
  "apps_checked": 198,
  "flagged": [
    {"app": "Example Editor", "version": "4.2.1", "powers": ["fetch", "shell-pipe"]}
  ]
}

apps_seen and apps_checked are numbers. flagged holds at most 50 items, one for each app whose update gained a power. An item holds the app's public product name, its version and the powers it gained. No file name, no path and no other app name leaves the computer.

We keep the two numbers and the flagged items for each computer, under its two-word name. Your report shows them for each computer.

6. What Never Leaves

Vigilance never sends:

• Code.
• Files.
• File names.
• Paths.
• Project names.
• Folder names.
• App names, except the flagged apps of section 5.
• Staff names.
• User names.
• Host names and machine names.
• Hardware ids.
• Install ids.
• Lockfiles. The first look reads them on the computer and sends only public package names and versions.
• Private package names.
• Error reports.
• The address of any package server that Vigilance routes through its check.
• The program version, except in the counts and the join.
• The name of any AI tool that is not on the fixed list of section 4.

Each computer sends a random device id in place of an install id. It names no person and no machine. The two-word computer name is made by our server. The computer never sends it.

Nothing outside the table in section 3 leaves the computer. That includes your prompts and the answers of your AI tools.

8. Where the Data Lives

• Every store is in AWS Canada (Central), region ca-central-1.
• Amazon CloudFront serves the host from locations around the world. It passes requests through and keeps copies of the signed public files, which are the same for everyone. Its access logs are off.
• The rate-limit rules run at the edge. They keep no record.
• Server logs hold the request id, the route, the status, the time taken and the error type. A version-check log line also holds the public package name and version. A plan-check or counts line holds your company id only when our server fails with a 5xx error. Logs are kept 14 days.
• An AI model never reads anything from your computers. The verdict each computer reads comes from our own checks, run on the public package files.
• Requests pass through Amazon CloudFront servers in other countries, mostly the United States, on their way to Canada. Payments run on Stripe, in the United States and other countries. Email runs on Google, in the United States and other countries. The authorities of those countries can have access to data held there.

9. Check It Yourself

You do not need to trust this page. Three ways to check it:

1. Watch the wire. On a computer with Vigilance on, run:

vigi-seat wire

It prints each request to check.vigihq.com before it goes, until you press Ctrl-C. Install a package in another window and read what it prints. To see the requests of one command only, run:

vigi-seat --show-wire npm install lodash

The device credential shows as dots and its last 4 characters.

2. Test the network path. Run:

vigi-seat netcheck

The last line says PASS when the computer reaches check.vigihq.com on port 443 and gets signed answers back. Otherwise it says FAIL and names the step that failed. The installer result screen runs the same check.

3. Read your firewall log. The only Vigilance host in it is check.vigihq.com.

10. What Vigilance Cannot See

Vigilance does not see everything. We list the gaps on every readout and receipt.

• Apps built only in a cloud workspace, such as cloud agents.
• Apps built on personal AI accounts on computers that did not join.
• Computers that did not join. The readout lists each joined computer by name, so a missing one stands out.
• Package versions with no verdict yet. The readout counts them as unchecked.
• Package managers it does not cover: 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.
• Linux computers. Vigilance runs on Mac and Windows.
• Who installed a package, and in which app. We cannot tell you, because we never get that data.

When a gap opens on a computer, we email you the same day. A computer that stops checking for 3 days gets an email too.

On a readout, no report means we do not know. A report with zero events means none were seen. Repeated package events are not different packages.

11. Changes to This Page

A new field needs a new version of our public request format and a new version of this page, first. We change this page before any computer sends the new field. Each version keeps its date. We keep every old version. Email support@vigihq.com for a copy.

For the rest of our security work, read Security at Vigilance. For what the website collects, read the Privacy Policy.

Modul4r Solutions, 18207 61 Ave NW, Edmonton, AB T6M 1T6, Canada