An Agent Hook Is Not a Security Boundary: Reading numbat's Coverage Matrix

The endpoint is part of the agent system

Coding agents can read a workspace, use local tools, and request network actions. Once that happens, a safety prompt is only one part of the picture. Teams also need to ask what was observed, what can be reconstructed later, and whether anything can intervene before an action happens.

numbat is an Apache-2.0 project that frames this as endpoint visibility for AI agents. Its public v0.1.1 release lists the current release, while its README describes inputs from local hooks or plugins, OTLP/HTTP logs, and supported on-disk session artifacts. The stated design normalizes those inputs into one event model and evaluates CEL rules.

Not tested or run: this is a reading of the repository and its public documentation, not an independent compatibility, detection-quality, or security evaluation.

Observation, reconstruction, and enforcement are different jobs

It is tempting to collapse all three into “agent protection.” That loses the important engineering distinctions:

• Observation means a host exposes a hook, plugin surface, log, or durable artifact worth collecting.
• Reconstruction means records retain enough source context to investigate without casually copying raw sensitive transcripts everywhere.
• Enforcement means a supported host invokes a synchronous pre-action callback that can request a denial before the host executes a tool action.

numbat's enforcement document makes the boundary unusually explicit. Monitoring is the default. An operator must opt in through an enforce-marked rule, and the agent host remains the enforcement point. The project returns a host-native deny request; it does not execute or cancel the tool itself.

That matters because a transcript found after the fact may help an investigation but cannot stop the original operation.

Read the coverage matrix before the command line

The most useful project page may be its agent coverage matrix. It separates durable artifacts, live capture, enforcement support, and host-specific limits. Some formats are deliberately marked deferred or unsupported rather than being silently treated as complete telemetry.

For an engineering rollout, that matrix suggests a practical checklist:

1. Identify the exact agent hosts and modes your team uses.
2. Decide whether the immediate need is auditability or pre-action intervention.
3. Check what happens on hook, parsing, or output failure. The documentation describes fail-open paths and host-specific behavior.
4. Keep separate controls for operating-system permissions, secret access, network egress, and code review.

Who should care?

This can be relevant for teams running several local coding agents and needing a consistent investigation layer. Normalizing supported inputs can be more useful than manually grepping unrelated logs when a review spans several tools.

It is not a replacement for endpoint controls. A host hook is not a complete policy boundary, and coverage is constrained by the hooks and artifact formats each upstream host actually publishes. For a one-off inspection of a single session, directly reading a file or using grep may still be the cheaper tool.

The conservative rollout is inventory first, monitoring second, and narrowly scoped enforcement only after the event quality, false positives, data retention, and host behavior are understood. The lesson is larger than one project: a security control earns trust by naming its blind spots.

Sources: repository README, coverage matrix, and enforcement model.