We Empowered AI Agents With 'Hands,' Now We Require Kernel-Level Vision to Monitor Them

The cybersecurity industry has been looking at large language models (LLMs) for the past few years as a scary librarian who can be slightly dangerous. We feared that they might read the wrong book (training data leakage) or express something offensive (hallucinations). Yet primarily, these models remained static, locked behind a chat interface, and invulnerable to the outside world.

However, with the introduction of the Model Context Protocol (MCP), the AI has effectively been given "hands." We are connecting LLMs to our filesystems, our databases, and our command lines so that they can take action on our behalf. This is a new era of technology, but it also comes with a new danger: agentic AI that could unintentionally run system commands, exfiltrate PII, or bring supply chain attacks by using compromised tools. The issue is that our existing monitoring tools are focusing on the wrong layer. Agentic AI security is not about looking at API logs; it is about looking at the kernel. What we need is eBPF.

Unrecognized Agent Protocol Blind Spot

The Model Context Protocol (MCP) has become the quintessential "language" to interconnect artificial intelligence solutions with other systems. It performs according to the model of the client-host-server; the Host AI application uses the MCP Client to negotiate capabilities with the MCP Server (tool or data sources).

The problem of transport security is a major risk. These communications are mostly made through JSON-RPC 2.0 over the input/output (stdio) for local tools, or over HTTPS for remote connections. Let's take, for instance, a case when an engineer uses a super-advanced AI IDE. The AI prompts them to change the code a little bit. With this background, the MCP client may ask the file to read, spawn a subprocess to run a test, or query a local database. But if this agent has been prompt-injected to exfiltrate credentials or the "tool" it resorts to is malicious, a traditional firewall may not catch the traffic because it is happening over local pipes or encrypted channels. This creates an architectural blind spot. Because standard security information and event management (SIEM) tools operate at the application layer, they only parse what the MCP framework explicitly chooses to log. If an exploit bypasses the application’s built-in telemetry, or if a compromised server runs an oblique execve call, the entire security perimeter remains blissfully unaware.

If you wait for the LLM to tell you what it "saw" to know what actions it has taken, it means you have already lost. You need a truthful source that the AI agent cannot mislabel or change.

Why eBPF is the "Body Cam" for AI Agents

The Extended Berkeley Packet Filter (eBPF) transforms from being a mere performance optimization tool into a security one, and in this respect becomes the very fabric of security. eBPF allows the running of sandboxed programs in the Linux kernel context, attaching to the hooks triggered by system calls, function entries, and network events.

Since eBPF operates at the kernel layer, it views everything the operating system can see, whereas the application cannot necessarily claim the same. It offers us the opportunity to watch the agent's actions "thinking" in real time.

For complete MCP monitoring, we need to extract data from three specific points:

• Process execution: By attaching probes to the execve system calls, we can determine when an MCP server launches a new subprocess. For instance, if a text-summarisation tool suddenly tries to run curl or chmod, eBPF flags it instantly.
• File operations: We can use virtual file system (VFS) read/write functions and thus examine exactly which files an agent has read and written. For example, if an agent who is only authorized for "project_docs" tries to read other directories, the kernel probes will consider it offensive and will catch the violation.
• Encrypted traffic interception: eBPF also helps us capture JSON-RPC messages in plaintext before they are encrypted or after they are decrypted using userspace probes. By attaching user-space probes (uprobes) or user return probes (uretprobes) directly onto OpenSSL or Go's crypto libraries, eBPF intercepts the payload buffers before they undergo cryptographic transformation. This lets security teams audit the raw JSON-RPC strings, verifying if an agent is secretly transmitting sensitive proprietary code snippet architectures or access tokens under the guise of regular health checks and catching if personal data is leaked.

Practical Visibility: The "MCPSpy" Strategy

To demonstrate that this is not just a theory, we can examine open-source implementations such as "MCPSpy." By using eBPF maps (specifically ring buffers) to collect events from kernel to user space, security teams can build a real-time feed of agent behavior. Such granularity is unattainable with conventional application logs, since the application does not always "know" the semantic weight of the data it processes. The kernel, on the other hand, processes the raw bytes. Consequently, tools like "MCPSpy" act as an unalterable audit trail. Because the eBPF bytecode runs inside the kernel space, even a fully compromised AI application with root privileges at the user layer cannot manipulate, delete, or obscure the ring buffer events being shipped off-node to the security engineers.

The Road Ahead

Incorporating AI agents into our development and production processes means that we are, in effect, airlifting the trusted computing base to include partially probable models. We cannot just rely on them to function correctly.

We have to be wary of the processes being hijacked, tools being misused, and data being mishandled. By leveraging eBPF, we can monitor AI operations at the kernel layer, where the actual working system exists. It is high time we stopped asking the AI what it is doing and started observing the system calls it produces.