Perplexity has open-sourced Numbat, a tool that watches what AI coding agents actually do on a machine. The interesting part is not the announcement. It is that the project documents its own limits more clearly than most security tooling ever does, and those limits tell you exactly where it fits.
What it is
The repository describes Numbat as endpoint visibility into AI agent activity, with local detection, optional pre-action blocking, and forensic reconstruction.
The practical characteristics:
- a Go binary, built without cgo
- macOS, Linux and Windows, on amd64 or arm64
- Apache 2.0 licence
- designed for desktop, CLI, IDE and gateway agents, with Codex, Claude Code and OpenClaw named as examples
The design intent is to sit across agent harnesses rather than inside one of them, which is what makes it relevant whatever agent you happen to run.
The three ways it sees
Numbat observes through three mechanisms, and the distinction between them is worth holding onto:
Local hooks and plugins. Live. This is also where prevention happens, when it happens at all.
OTLP over HTTP logs. Live telemetry collected locally.
On-disk session artifacts. Retrospective. This is what lets it reconstruct what a session did after the fact, without having been attached while it ran.
That third mechanism is the one people underestimate. Most agent sessions are already writing artifacts to disk; reading them afterwards is a genuinely different capability from live monitoring.
The four limits the project states itself
This is the part worth reading twice, because it is unusually candid and it defines the tool's real scope.
Findings are rule matches, not proof of compromise. A detection tells you a rule fired. It does not tell you something bad happened. Treating matches as verdicts is how teams end up chasing noise and distrusting the tool.
Reconstruction cannot recover what was never persisted. The README is explicit that at-rest reconstruction is not disk or memory acquisition, and cannot recover activity an agent did not write down. If an agent did something without leaving an artifact, that action is invisible to this method.
Enforcement is limited to supported synchronous pre-action hooks. Blocking works where a hook exists and the call is synchronous. Elsewhere you get observation, not prevention. That is a meaningful difference if you were planning to rely on it as a control.
Records can retain sensitive context even after redaction. The project warns that its own output may keep sensitive endpoint and agent context after redaction. For a monitoring tool, that is an important admission: the logs themselves become something you have to protect.
Why this matters beyond one tool
The industry conversation about agent safety has mostly been about model behaviour. Numbat is an argument that some of it belongs at the system layer instead: on the endpoint, integrated with the harness, watching what the agent actually executes.
Whether or not you adopt this particular tool, the framing is useful. An agent that can run commands, edit files and reach the network is an ordinary endpoint security problem wearing new clothes. Visibility into what it did is a reasonable thing to want, and until recently there was not much tooling that gave it.
What to take from it
If you run coding agents on machines that matter, three practical points:
Session artifacts are already there. Even without adopting Numbat, knowing that agent sessions persist artifacts you can inspect afterwards is worth acting on. Retrospective review costs nothing to try.
Do not confuse visibility with control. The blocking is real but bounded to specific hooks. Plan for a tool that mostly tells you what happened.
Treat the monitoring output as sensitive. By the project's own warning, redacted records can still carry endpoint and agent context. The logs need the same care as what they observe.
Details in this article, including the description of the tool, the three integration mechanisms, the licence and platform support, and the four stated limitations, are taken from the official Numbat repository as published by Perplexity and checked on 31 July 2026. Open-source projects change quickly; verify against the repository before relying on a specific behaviour. This article describes the tool from its documentation and is not based on first-hand deployment.
