v0.22.1 - a process we cannot name is not one running itself

The Agentic AI page went live against findings already in the log store, so it read months of DNS telemetry through a lens written for something else. It reported dozens of things running unsupervised. They were Office, the Linux stub resolver, and browser helper subprocesses.

Four separate faults, stacked. None of the fixes needs new signal.

The allowlist matched nothing on Windows

is_allowed_process was an exact lowercase set lookup against a list written in mac and Linux spelling:

onedrive.exe   -> allowed=False     the list has "OneDrive"
outlook.exe    -> allowed=False     the list has "Outlook"
chrome.exe     -> allowed=False     the list has "chrome"
powerpoint.exe -> allowed=False     never on the list at all

So on a Windows endpoint it matched nothing. Two consequences, and the second is the one nobody had noticed: the Microsoft-noise filter never fired there, and the bridge scan has been raising a high-risk finding on every browser that resolved api.github.com.

Names now normalise before matching — lowercased, path and .exe stripped, a macOS X Helper (Role) reduced to X — so one entry covers every shape a platform reports it in. The allowlist gains the Office binaries it never had.

A resolver names nothing, and the code already knew that

is_unattributable held the right idea and too narrow a list. A stub resolver is the querying process for every lookup its machine makes, so naming it says "this device resolved it" and nothing about what wanted the name — the same non-answer as the agent version string it already refused.

systemd-resolved, systemd-executor, mDNSResponder, svchost and the rest join it. Absolutely, not scoped to the Microsoft domains — that scoping was exactly why the Linux resolver survived on every other domain there is.

Half the registry was being read

The portal read cli.binaries and called that "a tool the registry knows". allowed_processes — the browsers, desktop apps and daemons the scanner already declines to raise findings about — was sitting unread in the file the portal loads, so every desktop application in the estate arrived as a mystery process with nobody behind it.

This is the half that matters for an existing deployment: it applies retroactively to findings already stored, so the page corrects on refresh rather than waiting out the lookback window.

The counter contradicted its own docstring

agentic_from documents at length that a blank identity must not be read as a machine identity, because doing so would manufacture the finding the page exists to report. The field obeyed. The counter did not — accountable is identity == "person", so silence fell into unaccountable and the headline said "answer to nobody" about every row where nobody had established anything either way.

The same headline then folded two claims of different strength into one sentence: a thing that reported running unattended, and a process reaching a model that says nothing about who started it. On an estate whose collectors predate mode, the second is every row — so the page asserted autonomy from evidence that never mentioned it.

They are counted apart now, and the weaker claim gets weaker words. authority is three states and unknown is one of them.

One found on the way

_VIA is bounded by ")", so it truncates (via Google Chrome Helper (Renderer)) at the inner bracket and delivers a role that never closes. The suffix match allows for that.

Checked

Replaying the observed process names plus one genuinely scheduled job through the real registry.yaml:

before:  11 things run without being asked. 11 answer to nobody.
after:    1 thing runs without being asked. 1 answers to nobody.
          1 more process reached a model without being a browser
          or a tool the registry knows.

Only curl survives as unrecognised, which is correct — that is the script-with-a-key case the branch exists to catch.

Verified in the running portal against seeded data, not just at the derive layer: headline, chain rows and the overview tile, no console errors. Suites green: portal 603, scanner 198, registry 22.

is_allowed_process had no test of any kind before this; it has 34 now.

This is 0.22.1

Not a choice so much as a consequence. The chart ships the built registry, so widening allowed_processes moves a file under charts/, and CI requires Chart.yaml to move with it — otherwise a repo index carries the change without offering it as an upgrade. The two guards are in the same job, so there is no version of this PR that changes the allowlist and leaves the chart alone.

The usual five, matching the release: 0.22.0 commit exactly: version and appVersion in Chart.yaml, the two receiver image tags in the Kubernetes deployment doc, and the one in receiver/deploy. The receiver:0.22.1 images do not exist until this is tagged.

Deploying

The two halves land differently. The portal fix ships with the chart and takes effect retroactively. The scanner fix does not — there are no CronJob templates in the chart, so the scanner and discovery image tags still need bumping by hand or new findings keep being written with (via onedrive.exe).