A research team tests whether operating-system evidence can help monitor AI agents
A new paper compares application logs with lower-level operating-system telemetry across simulated agent-security scenarios. Its findings point toward combining evidence sources, but the study is an evaluation—not a ready-made monitoring product.

A new paper compares application logs with lower-level operating-system telemetry across simulated agent-security scenarios. Its findings point toward combining evidence sources, but the study is an evaluation—not a ready-made monitoring product.
Monitoring an AI agent through its own application logs leaves a blind spot: the system can describe its intentions, but those descriptions do not necessarily prove what happened on the machine. A September 24 paper examines whether evidence from the operating system can provide a more discriminative view for retrospective detection tasks.
The authors of “On the Effectiveness of Kernel-Level Evidence for Agent Security” report evaluating 4,047 paired sessions across 17 threat models. Their setup used one Claude Haiku 4.5 agent in fresh Docker containers. They compared application traces and tool-call records with operating-system evidence collected using strace, then tested a combined view. In the authors’ experiments, the combined Cross-View approach produced the highest area-under-curve score for all ten detectors on in-distribution tests and seven of ten on held-out attack families. Those results describe the tested setup, not every production agent.
The rationale is straightforward. An application trace can record a model’s tool request or declared action. System-level evidence can reveal processes, files or network activity associated with what actually ran. When the two are compared, investigators may have a better chance of distinguishing an allowed operation from an unexpected side effect.
That is a promising direction for systems where agents can use terminals, browsers or software tools. It does not mean kernel telemetry can infer an agent’s intent, prevent every unsafe action or automatically establish responsibility. The conclusions remain bounded by the paper’s threat models, instrumentation and evaluation setup. A model that has not been tested against diverse real deployments may miss important failure modes.
The paper is a preprint, so its methods and results should be read as research claims awaiting review and independent replication. It also identifies gaps: some attack styles were invisible to both evidence layers, tool manifests were recorded only at session start, and attribution was at the session level rather than per tool call. The evaluation uses synthetic threat fixtures and one agent/runtime, so a broader deployment may expose failure modes not covered here. Organizations would also need to assess collection overhead, privacy implications, platform coverage, false positives and evidence retention. Detailed process monitoring can support investigations while also creating sensitive records of user and system activity.
The useful takeaway is a design principle rather than a product recommendation: assess agent behavior using evidence from more than the model’s self-report. Pairing logs at different layers may make investigations more grounded, provided the monitoring itself is proportionate and transparent. The next test is whether the approach works across real workloads without imposing unacceptable performance or privacy costs.


