Syscon: Kernel-Level Syscall Monitoring for AI Agent Control in Sandboxed Environments

The idea is brilliant and needed. A high-level monitor that keeps track of the broader network and reports to trusted monitors. I would encourage the team to look at entrepreneurial funding if anyone on the team is keen. I think it would be plausible to fairly quickly raise large amounts of funding to have this scaled to production. See https://www.aisafety.com/funding for some ideas here (especially the for-profit sections).

The conceptual motivation for the idea is strong - it's easy to hide simple malicious commands in complex chunks of code. It could be harder to hide the network level outcomes.

The clear display of the negative results was great - and bode's well for the team's honesty. The findings were easy to interpret, and they used multiple model families as attackers. I would not be surprised that gemini-2.5 flash (with no reasoning) is just incapable of incorporating this information into its decision. I'd be excited for the team to try this with more capable monitor models (ideally with reasoning).

Overall, I'm thoroughly impressed with the project, and excited for this team to continue working in this area. Great work.

Congrats on your project!

Impact & Innovation: Giving the trusted monitor access to ground-truth OS telemetry is an interesting concept that exploits an already desirable situation in containerized agents. The underlying mechanisms are well-established in container security, and recent industry work aligns with your vision. Your project could be a meaningful building block for the field if kernel monitoring can be effectively leveraged.

Execution Quality: The experiment design is sound but I believe there could have been deeper analysis without requiring additional compute. Some considerations for strengthening the evaluation:

- Detection curves (Figure 2) are shown at absolute suspicion thresholds, but ideally should be reported at false-positive rates. However, your honest trajectory sample is too small to properly estimate FPR thresholds, so a more extensive honest study would be needed to support this analysis.

- Trajectory-level monitoring may not be realistic for very long trajectories. Reporting the performance of each monitor type individually, in addition to the aggregation, would give a clearer picture of where receipts help. Furthermore, it would be interesting to see the monitor's performance when given only the receipt with no tool call text. This would isolate the signal contribution of the syscall channel.

- The null detection result is honestly reported and well-diagnosed. A natural follow-up question: does receipt effectiveness vary by attack vector? In particular, receipts should be especially valuable when the attacker is tampering with action-level logs or output, since kernel-level telemetry is the only reliable channel in that case.

Presentation & Clarity: The paper is well-structured and reads clearly. The threat model is thorough and I appreciate the honest framing of the detection results. The example receipt in Appendix A is very helpful. A few notes: Figure 1 is too small to read at the rendered size, and Figures 2 and 3 are missing error bars or confidence intervals.