You installed a package. Here is what its code did, signed and tied to the run that installed it.

What a receipt is, and what made it

gVisor is a kernel written as an ordinary program: the code in the pod talks to it instead of to the machine's own kernel. Every system call (INTERNAL · glossary →) the code makes, such as opening a file, starting a program or opening a connection, is answered by gVisor. Started with its --strace option, gVisor's runsc (INTERNAL · glossary →) also writes every such call to a log file on the node (gVisor's debugging guide (EXTERNAL · official docs ↗)). The node is the machine that runs the pod, and the log file is outside the pod, where the code inside cannot write. Reading package behavior from that log is also the approach of package-analysis, the Open Source Security Foundation's tool for watching what published packages do (EXTERNAL · source repo ↗).

The receipt is what examples/dependency-receipt reads from one such log: the processes and the programs started in them, every file written, and every open for writing, file change and network call, each with its outcome. It is signed as an in-toto (INTERNAL · glossary →) statement (the Statement specification (EXTERNAL · source repo ↗)) in a DSSE (INTERNAL · glossary →) envelope, the same envelope plimsoll signs its run records (INTERNAL · glossary →) in. A run record is plimsoll's statement of one run: what was sent, what came back, and which sandbox ran it. The receipt names the log by its digest (INTERNAL · glossary →) and the run record by its digest, so it is about exactly one log and one run.

These runs used plimsoll's agent-sandbox (INTERNAL · glossary →) provider: Kubernetes, a system that runs containers across machines, keeps a warm pool of ready pods (a pod is Kubernetes' unit of one or more containers run together; Kubernetes' pods page (EXTERNAL · official docs ↗)), and each run claims one, uses it once, and deletes it. The pods ran under the RuntimeClass (INTERNAL · glossary →) gvisor-receipt, whose handler runsc-receipt is gVisor with the system-call log turned on; plimsolld, the plimsoll server, was told that handler is gVisor and held every pod to gVisor's boot line before sending it any code. All of it ran on a local kind (EXTERNAL · official docs ↗) cluster on 2026-10-29; nothing was paid for.

The three installs

Each run sent one package's files as a project and ran two steps in its pod: an offline npm install of the package from its directory (--install-links copies it into node_modules as an install from a tarball would, and runs its install script), then a node command that imports it. The packages are the fixtures beside the receipt code; none comes from the public registry, and plimsoll sends no run to a pod unless a network policy denies the pod's traffic out.

Tier is the isolation tier (INTERNAL · glossary →) the run record states: kernel means gVisor stood between the code and the node's kernel. Every request asked for at least kernel, and the daemon was set to refuse any run below it. Each run record's start and end are 6.9 s (quiet), 7.2 s (network) and 6.8 s (canary) apart. The log sizes are as runsc wrote them; the published copies are gzip-compressed.

What each package's install script does, from its source in examples/dependency-receipt/fixtures/packages: quiet has none. network starts a TCP connection (the kind a web request uses) to 203.0.113.7 port 443, looks up the name canary.example (a DNS lookup, which turns a name into an address), and sends a UDP datagram (one packet, sent with no connection) to 198.51.100.9 port 53. Both addresses are reserved for documentation, so no real host has them (RFC 5737 (EXTERNAL · standard ↗)). canary first writes /root/.canary; if that works it goes on to write through a symlink into /etc, rename and remove a file, and write to /proc. Here its first write was refused, so its script stopped and npm failed:

$ npm install --offline --no-audit --no-fund --foreground-scripts --install-links ./packages/canary

> plimsoll-fixture-canary@1.0.0 postinstall
> node install.js

node:fs:2430
    return binding.writeFileUtf8(
                   ^

Error: EACCES: permission denied, open '/root/.canary'
    at Object.writeFileSync (node:fs:2430:20)
    at Object.<anonymous> (/work/project/node_modules/plimsoll-fixture-canary/install.js:4:4)
    at Module._compile (node:internal/modules/cjs/loader:1781:14)
    at Object..js (node:internal/modules/cjs/loader:1913:10)
    at Module.load (node:internal/modules/cjs/loader:1505:32)
    at Function._load (node:internal/modules/cjs/loader:1309:12)
    at wrapModuleLoad (node:internal/modules/cjs/loader:254:19)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
    at node:internal/main/run_main_module:36:49 {
  errno: -13,
  code: 'EACCES',
  syscall: 'open',
  path: '/root/.canary'
}

Node.js v22.23.4
npm error code 1
npm error path /work/project/node_modules/plimsoll-fixture-canary
npm error command failed
npm error command sh -c node install.js
npm error A complete log of this run can be found in: /work/.npm/_logs/2026-10-29T18_14_18_523Z-debug-0.log

Who did what in each pod

A receipt covers the pod's whole life, not only the package: sandboxd (agent-sandbox's daemon in the pod, which starts each command plimsoll sends), plimsoll's own check of the pod, plimsoll's runner, npm, and the package. The receipt lists every process by its PID (process ID), the programs started in it, and which process made each call. This page groups the processes by the command that started them: a step's shell is matched to the step's exact text in the signed request, and an install script's shell to the script's exact text in the package.json the run sent. The grouping is the page's reading; the receipt itself lists every process and call ungrouped.

effected the call returned success, attempted it returned an error, undetermined the log does not show its outcome (the next section says more), written files written. For the package's own groups (amber) every call is listed; for the others, every call that did not succeed and every network call other than opening a new socket.

Most of what the receipts list is npm, not the package. npm turns on node's compile cache (node's module documentation (EXTERNAL · official docs ↗)), and in the quiet run 552 of the 560 files npm wrote are that cache. A package's own groups are short by comparison: that is what grouping by process is for.

The receipt's three sides, in plain words

Every open for writing, file change and network call in a receipt sits on exactly one of three sides, decided by what the call returned in the log.

Which run it was

plimsoll reads each claimed pod back from Kubernetes before it sends any code, and the run record names the pod by its UID, the unique ID the API server gave it when it was made. Kubernetes never gives that UID to another object in the cluster's history. runsc logs each container's spec when the pod starts, before any program in it runs, and the spec names the same UID. The receipt command verifies the run record's signature in the bundle (the harness (INTERNAL · glossary →)'s signed file of run records, one per line), requires the two UIDs to be equal, and names the record by its digest as the receipt's second subject.

$ dependency-receipt -log logs/network.boot.json.gz -key secrets/harness.key -out tampered/never-written.intoto.json -bundle bundle.jsonl -line 1 
dependency-receipt: receipt: refused: the run record names instance "k8s-pod-uid:fcbbc735-79ae-4871-b08f-3a8dab68675f", the log names "k8s-pod-uid:6ff9c6f1-4b63-40a0-af88-869b1a087a1b"
exit 1

Changing a receipt or its log fails the check

The check opens a receipt under the signer's public key, rebuilds the whole claim from the log and the run record it names, and requires the two to be identical, byte for byte. Each receipt above checked. Two changed inputs, on the network run:

$ dependency-receipt -check tampered/network-connection-deleted.intoto.json -pub harness.pub -log logs/network.boot.json.gz -bundle bundle.jsonl -line 2 
dependency-receipt: receipt: the signed receipt is not what its evidence rebuilds: the log shows something other than the receipt states
exit 1

$ dependency-receipt -check receipts/network.intoto.json -pub harness.pub -log tampered/network-one-byte.boot.json -bundle bundle.jsonl -line 2 
dependency-receipt: receipt: the signed receipt is not what its evidence rebuilds: the receipt is about log 98f9a3e05af99afbd6e853613b30757033376c58946b36ee9b846ca4899a65e0, the log given is a8ce7729abe09505e8b2e1ea24bf3988acd1a8df008a0ef65cc15d30d1d0b109
exit 1

What the log cannot show

A receipt is exactly as good as the log under it. These are its limits, stated in the receipt code's README; nothing on this page gets around them.

• The log is the signer's word. Whoever runs the node holds the log. The check proves the receipt says exactly what this log shows and names this run; it cannot prove runsc wrote this log for that pod.
• Behavior the package keeps for later. One install and one import is one observation. Code that waits, or checks whether it is watched, shows nothing.
• Names looked up in DNS show as datagrams to port 53, not the names.
• The destination of a datagram sent with sendmsg, which node's UDP sockets use: the network script's datagram to 198.51.100.9 is in its receipt as one send with no destination.
• Writes through shared memory mappings, sendfile, splice, copy_file_range and fallocate are outside the calls the log keeps, so an open for writing can appear with no write after it.
• Paths of calls that take no descriptor (mkdir, rename, unlink, open) are read from the program's memory before the call reads them, so a second thread can change them in between, and a symlink in a folder of the path can make the call land elsewhere. Files written are named from descriptors and are not affected.
• Starting a new program can close descriptors silently, so after one the reader leaves a descriptor's name unresolved rather than give it a new file's name.
• io_uring, Linux's interface for queued file and network work, which runsc leaves off unless started with --iouring; the receipt is refused for a log made with it on.
• Anything outside gVisor. plimsoll's providers that run each sandbox in a small virtual machine of its own (Kata Containers, E2B, Docker Cloud) have no such log, so no receipt.
• The whole pod is one observation. sandboxd, plimsoll's check, the runner and npm are in every receipt with the package; this page's grouping is a reading of the process tree, not part of the signed claim.
• This cluster is a local test setup. The pod network between plimsolld and sandboxd is kind's default, which is not encrypted, so these runs show the receipt, not a protected channel (plimsoll's agent-sandbox guide (EXTERNAL · source repo ↗)). The daemon was not in hardened mode (INTERNAL · glossary →), and the image is named by tag; each run's record states the image's digest as the node reported it.

Every receipt also signs this list of what it cannot see, so its limits travel with it:

• behavior the package keeps for later: one install and one import is one observation, and code that waits, or checks whether it is watched, shows nothing
• names looked up in DNS: a lookup shows as a datagram to port 53, not the name
• the destination of a datagram sent with sendmsg
• writes through shared memory mappings, sendfile, splice, copy_file_range and fallocate
• paths of calls that take no descriptor are copied from the program's memory before the call reads them, so a second thread can change them in between; files written are named from descriptors and are not affected
• the pod's whole life is one observation: a pod that served several calls shows all of them
• anything outside gVisor

How it ran, and how to check it

plimsolld's settings

Besides these, the daemon read its secrets from files: the API server's certificate authority, a service-account token, sandboxd's token and the caller registry. plimsolld ran in a container on kind's network with a route to the pods, since it reaches each pod's sandboxd at the pod's address.

Files

• evidence.json: every number on this page
• quiet: receipts/quiet.intoto.json.gz (44 KB), logs/quiet.boot.json.gz (244 KB)
• network: receipts/network.intoto.json.gz (44 KB), logs/network.boot.json.gz (256 KB)
• canary: receipts/canary.intoto.json.gz (44 KB), logs/canary.boot.json.gz (250 KB)
• the receipt with a connection deleted: tampered/network-connection-deleted.intoto.json.gz

The receipts and logs are gzip-compressed. The receipt command reads a log either way and a receipt only as written. From the repository root:

go run ./examples/dependency-receipt/live -verify     # this page's files, offline: starts nothing
gunzip -k docs/examples/dependency-receipt/receipts/network.intoto.json.gz
go run ./examples/dependency-receipt -check docs/examples/dependency-receipt/receipts/network.intoto.json \
    -pub docs/examples/dependency-receipt/harness.pub -log docs/examples/dependency-receipt/logs/network.boot.json.gz \
    -bundle docs/examples/dependency-receipt/bundle.jsonl -line 2

-verify checks the bundle's signatures and chain, checks every receipt against its log and record, requires both changed inputs and the wrong record to be refused, and requires this page to be exactly what evidence.json renders. Running everything again needs a kind cluster with agent-sandbox and the gvisor-receipt runtime class: go run ./examples/dependency-receipt/live makes a Kubernetes namespace (a named group of the cluster's objects) of its own and deletes it after.