Lockfiles tell you what landed, not who installed it

A common first question about Koban: "Can it tell me whether Cursor or a human ran npm install?"

The honest answer is no. Koban does not hook process execution or attribute installs to a parent binary. It reads what is on disk (lockfiles, receipts, MCP configs) and diffs snapshots over time.

Why we chose disk over process

Process attribution on macOS without EndpointSecurity entitlements is either incomplete or invasive. Heavy EDR agents can attribute execution; Koban deliberately is not one.

The question we optimize for is different:

Did a new package or MCP server appear since the last heartbeat?

That question is answerable from inventory alone. It is also the question supply chain incidents actually require: knowing what changed, not reconstructing who typed the command.

What lockfiles actually capture

When an agent runs npm install lodash@4.17.21, the result is visible in:

• package-lock.json or pnpm-lock.yaml (exact resolved versions)
• node_modules/ (on-disk artifacts; Koban focuses on lockfiles for consistency)
• Git history (if the agent committed, which often it does not)

The install happened whether or not you have process logs. The lockfile is the artifact of record.

Fleet rules work on artifacts

YAML policy rules in Koban Fleet evaluate inventory fields: package names, version ranges, MCP server commands, Homebrew casks. They do not need a process tree.

Example intent:

• Alert when any Mac adds an MCP server not on the allowlist
• Flag npm packages matching a denylist published after a registry incident
• Report drift between two engineers who should share a baseline

When you need attribution

If your threat model requires knowing which binary invoked npm, you need an EDR or ES client, with the entitlements, agent footprint, and privacy tradeoffs that implies.

Koban sits beside that stack as the inventory and drift layer for packages and AI tooling configs. Together, they answer different parts of the same incident.