iron-sensor: An eBPF Security Camera for the Agentic Age
As AI coding agents gain ambient authority over our file systems, this lightweight monitor uses kernel-level hooks to track every autonomous intent.
- The sensor uses eBPF to track every child process spawned by an AI agent through kernel-level subtree monitoring.
- A Go-based classifier translates raw system calls into semantic security alerts like sensitive file reads or persistence attempts.
- The tool operates with zero instrumentation to provide a high-fidelity audit trail without the agent's knowledge or code modification.
- Kernel-space execution ensures nearly zero overhead for local developers compared to heavy sandboxing or virtual machines.
The Sudo Paradox
The "AI Agent" revolution has created a massive security blind spot. We are giving large language models ambient authority over our terminals, allowing them to execute code, modify files, and spawn processes, often hoping they don't hallucinate a destructive command. Traditional sandboxes like Docker or heavy virtual machines are often too cumbersome for daily local development, leaving developers in a precarious state of "YOLO" execution.
An eBPF-based behavioral monitor for AI coding agents. iron-sensor detects when AI agents like Claude Code, Codex, and OpenClaw are running on a Linux system, then monitors every process they spawn, every file they touch, and every persistence mechanism they attempt.
Identifying the Agent Subtree
The core innovation of iron-sensor is how it solves the identity problem. When a human and an AI share the same shell environment, distinguishing who did what becomes nearly impossible with standard logging. iron-sensor utilizes eBPF (Extended Berkeley Packet Filter) to hook directly into the Linux kernel's process lifecycle events.
By maintaining a BPF hash map of tracked process IDs (PIDs), the sensor implements subtree tracking. If it identifies a root process as an AI agent, every subsequent child process it forks is automatically tagged and tracked, preventing evasion even if the agent spawns complex, multi-layered shell scripts.
From Syscalls to Semantics
Raw system calls are too noisy for practical auditing. A single `npm install` generates thousands of file operations. The userspace component of iron-sensor, written in Go, acts as a semantic bridge. Its internal classifier engine evaluates these raw events against a set of declarative rules.
It is not enough to know a file was opened; security requires knowing intent. By combining the operation type with the target path and the process lineage, the classifier can escalate a generic file write into a critical alert, such as an attempt to modify a `.bashrc` file.
| Traditional Logging (strace) | iron-sensor Classification |
|---|---|
| openat(AT_FDCWD, "/home/user/.ssh/id_rsa", O_RDONLY) | {"intent": "sensitive_file_read", "severity": "CRITICAL"} |
| openat(AT_FDCWD, "/home/user/.bashrc", O_WRONLY) | {"intent": "shell_rc_write", "severity": "HIGH"} |
| execve("/bin/sh", ["sh", "-c", "curl http://x.com"], ...) | {"intent": "suspicious_network_exec", "severity": "MEDIUM"} |
The Lightweight Sentinel
Unlike heavy Host Intrusion Detection Systems (HIDS) designed for cloud perimeters, iron-sensor is built for the local developer machine. It operates with zero-instrumentation—the AI agent does not know it is being watched, and no modifications to the agent's code are required.
iron-sensor sits in the kernel via eBPF and watches what these agents actually do. Since it works in kernel-space, it is nearly zero overhead. It doesn't block anything. Rather, it emits structured events as NDJSON so you can see, alert on, and audit agent behavior.
By treating the agent as an untrusted black box and monitoring it strictly from the outside, iron-sensor provides a high-fidelity audit trail. In a future where human-in-the-loop development relies heavily on autonomous code writers, this kernel-level observability is the prerequisite for safe delegation.