Your Security Scanner Was the Attack: What Syscall-Level Monitoring Reveals About Agent Runtime

On March 19, someone pushed a backdoored version of Trivy to Docker Hub. Trivy is Aqua Security’s open-source vulnerability scanner — the tool organizations use to find compromised dependencies. For four days, the security scanner itself was the attack vector. The payload: an infostealer targeting CI/CD secrets, cloud credentials, SSH keys, and Docker configs.

The same week, Sysdig’s Threat Research Team published a syscall-level analysis of AI coding agents. They attached eBPF probes to Claude Code, Gemini CLI, and Codex CLI and watched what happens at the operating system level. The numbers: 5 agentic loop iterations in 10 seconds. 64 execve events per session. Multiple outbound HTTPS connections per iteration. Disposable bash shells spawning and dying faster than any human could type.

These two events are connected in a way the industry has not yet grasped.

The layer nobody is watching

We have covered agent security at the application layer. McKinsey’s SQL injection incident demonstrated that agents executing generated code create attack surfaces that traditional security models do not anticipate. OpenAI’s session monitoring research showed that watching agent behavior at the application level reveals systematic misalignment patterns. Clinejection mapped how prompt injection propagates through the supply chain.

All of those analyses share a blind spot. They operate above the kernel.

Sysdig’s contribution is not another application-level security framework. It is visibility into what agents actually do on the machine. Every file read. Every process spawned. Every network connection opened. Every credential file touched. The operating system sees all of it, whether the agent’s sandbox permits it or not.

Here is what they found: AI coding agents behave like no software that came before them. Traditional development tools open a terminal, execute commands sequentially, maintain state. AI agents spawn disposable shells at machine speed. Each shell executes a single command, returns the result, and dies. The parent process immediately spawns another. Five loops in ten seconds, each loop potentially touching the filesystem, network, and process table.

Application-level sandboxes see the agent process. They do not see the 64 child processes it spawned, the files those children read, or the connections they opened.

Trivy proves the attack model

Consider the Trivy compromise through Sysdig’s lens.

An organization installs Trivy to scan container images for vulnerabilities. Trivy runs in CI/CD pipelines — environments with access to deployment credentials, cloud tokens, and SSH keys. The backdoored version harvested exactly those assets.

Now add AI agents to the picture. An agent running in a development environment might invoke Trivy as part of a security check. The agent does not know Trivy is compromised. The application-level sandbox does not know either — Trivy is an approved tool in the pipeline. The agent’s permission model says “allowed to run security scanners.” The scanner is the malware.

Syscall-level monitoring would see it. The legitimate Trivy binary reads container image layers and writes scan reports. The backdoored Trivy binary reads container image layers, writes scan reports, and also reads ~/.ssh/, ~/.docker/config.json, and ~/.aws/credentials, then opens outbound connections to IP addresses that have nothing to do with vulnerability databases. That behavioral difference is invisible at the application layer. It is obvious at the syscall layer.

Docker’s CISO Mark Lechner confirmed the compromise was active for four days. Four days during which every CI/CD pipeline running the compromised image was exfiltrating credentials. Application-level security had no signal. The tool was “working correctly” from the application’s perspective.

The agent config problem

Sysdig’s research identifies a specific vulnerability that has received insufficient attention: agent configuration files stored at predictable paths.

Claude Code stores its configuration at ~/.claude/. Gemini CLI at ~/.gemini/. Codex CLI at ~/.codex/. These files contain API keys, model preferences, tool permissions, and system prompts. Any process on the machine can read them.

This is not theoretical. Sysdig mapped this to MITRE ATT&CK T1552.001 (Credentials in Files) and ATLAS AML.T0056 (LLM Prompt Extraction). A compromised dependency — like a backdoored Trivy — running in the same user context as an AI agent can read the agent’s configuration, extract its API keys, and modify its system prompt. The agent continues operating normally. The application-level sandbox reports no anomaly.

The SesameOp attack (documented by Microsoft DART) and the Cursor IDE exploitation both followed this pattern. The compromise did not happen through the agent’s API. It happened through the filesystem, at a layer the agent’s own security model cannot observe.

Why application sandboxes are insufficient

Claude Code runs with a permission model. You approve tool access. You can restrict file system paths. Codex CLI has similar controls. These are useful and necessary.

They are also insufficient. Here is why.

Application-level sandboxes enforce policy on the agent’s actions. The agent asks to read a file; the sandbox checks if that file is in an allowed path. The agent asks to execute a command; the sandbox checks if that command is permitted. This works when the agent is the actor.

It does not work when the threat operates within the agent’s process. A prompt injection that causes the agent to exfiltrate data uses the agent’s own approved permissions. A compromised tool that the agent invokes runs with the agent’s credentials. The sandbox sees an approved agent running an approved tool accessing an approved path. Everything is permitted. Everything is malicious.

Syscall-level monitoring does not care about permissions. It cares about behavior. The question is not “is this agent allowed to read ~/.ssh/?” The question is “has this agent ever read ~/.ssh/ before? Is this pattern consistent with its normal operation? Is this outbound connection expected?”

Behavioral baselines at the kernel level detect what permission models cannot.

The governance gap

Sysdig maps their findings to four frameworks simultaneously: MITRE ATLAS, MITRE ATT&CK, OWASP LLM Top 10, and Google SAIF. This multi-framework mapping reveals something important: no single security framework covers the full attack surface of AI coding agents.

ATLAS covers AI-specific attacks (prompt injection, model extraction) but not infrastructure compromise. ATT&CK covers infrastructure attacks but not AI-specific vectors. OWASP LLM Top 10 covers application-level vulnerabilities but not OS-level behavior. Google SAIF provides architectural principles but not detection signatures.

The governance gap is the space between these frameworks. An attack that combines prompt injection (ATLAS) with credential theft (ATT&CK) through a compromised supply chain dependency (OWASP) requires detection at every layer simultaneously.

Application-level monitoring covers the ATLAS and OWASP layers. Syscall-level monitoring covers the ATT&CK layer. You need both. Most organizations have only the first — if they have anything at all.

What runtime governance actually requires

Sysdig’s eBPF approach points toward a specific architecture for agent runtime governance. Five components.

Syscall baselining. Profile each agent’s normal behavior at the kernel level. How many processes does it spawn per iteration? Which files does it read? Which network endpoints does it contact? Deviations from the baseline are signals, not noise.

Tool chain integrity. Every binary the agent invokes needs verification. Not just at install time — at execution time. The Trivy compromise was in the container image, not the source code. Static analysis of the source repo would have found nothing. Runtime hash verification of the executing binary would have caught it immediately.

Credential isolation. Agent configs and credentials should not be readable by arbitrary processes in the same user context. This means moving beyond file permissions toward process-level isolation — namespaces, seccomp profiles, or dedicated credential stores that require explicit agent authentication.

Cross-layer correlation. An application-level trace showing “agent invoked security scanner” combined with a syscall-level trace showing “security scanner read SSH keys and opened unexpected outbound connection” creates a detection signal that neither layer produces alone.

Framework-spanning policy. Security policy for AI agents must reference ATLAS, ATT&CK, and OWASP simultaneously. A policy that only addresses prompt injection misses credential theft. A policy that only addresses infrastructure security misses AI-specific attacks. The Sysdig research demonstrates that real-world agent behavior maps across all frameworks concurrently.

The 64 execve problem

Sixty-four process executions in a single agent session. That number should reframe how organizations think about agent monitoring.

Traditional endpoint detection and response (EDR) tools are calibrated for human-speed activity. A developer might execute a dozen commands in a terminal session over an hour. An AI agent executes 64 in seconds. The signal-to-noise ratio inverts. What looks like a burst of suspicious activity is normal agent operation. What looks like normal operation might be a compromised tool hiding in the noise.

EDR tools tuned for human behavior will either generate continuous false positives on normal agent activity or miss real threats buried in the volume. Neither outcome is acceptable.

This is the core argument for agent-specific syscall monitoring. Not general-purpose endpoint security applied to agents. Purpose-built behavioral analysis that understands the agent’s execution pattern: rapid shell spawning, single-command execution, immediate termination, repeat.

The convergence

Two trends are meeting.

Supply chain attacks are moving up the stack — from compromised libraries to compromised security tools. The Trivy incident is not the first and will not be the last. When the scanner is the malware, application-level security creates a perfect blind spot.

AI agents are moving down the stack — from high-level API calls to direct OS interaction through spawned processes and file system operations. The 64 execve events are not an implementation detail. They are the fundamental execution model.

The intersection of these trends is the governance challenge for 2026. Your agents operate at machine speed below your security tools. Your security tools can be compromised above your agents. The layer that can see both — the kernel — is the layer almost nobody is monitoring.

Sysdig has demonstrated that the monitoring is technically feasible. The question is whether organizations will implement it before the next Trivy-scale compromise targets an AI agent’s runtime environment.

The scanner was the attack. The sandbox did not see it. The kernel did.

---

This analysis synthesizes Sysdig’s syscall-level detection research (March 2026) and Docker’s Trivy supply chain compromise disclosure (March 2026).

Victorino Group helps enterprises build runtime governance for AI agent fleets. Let’s talk.