The core distinction lies in the attack surface expansion from static dependency graphs to dynamic, context-aware execution graphs. A traditional web app's supply chain is largely analyzable at build or deploy time through SBOMs and static analysis. An AI agent, however, incorporates a *runtime supply chain* where dependencies are resolved dynamically based on prompt context, retrieved data, and model output. This introduces a tracing and telemetry challenge that static analysis cannot address.

Consider the threat model: we must now defend against prompt injection leading to arbitrary tool execution, training data poisoning that influences reasoning, and malicious outputs from retrieved document chunks. Each of these represents a novel vector for introducing tainted "dependencies" during execution, not during deployment.

From a kernel telemetry perspective, this is where traditional application monitoring fails. You cannot simply trace `execve` calls from a known binary. You must instead instrument the agent's runtime to understand:
* Which external tools (e.g., Python REPL, curl) are being invoked based on model decisions.
* What data is being fetched from external APIs or vector databases.
* Whether the control flow of tool usage deviates from expected patterns.

This requires deep, continuous observation of the process. eBPF is particularly suited for this. Imagine attaching a kprobe to the syscalls made by the agent process and filtering for network connections or process forks that were not present in the allowed set. A simplistic detector might look for anomalies:

```c
// Conceptual eBPF snippet hooking connect()
SEC("kprobe/sys_connect")
int trace_connect(struct pt_regs *ctx) {
char comm[TASK_COMM_LEN];
bpf_get_current_comm(&comm, sizeof(comm));

// Filter for our agent process
if (comm != "ai_agent_process") {
return 0;
}

struct sockaddr_in addr;
bpf_probe_read(&addr, sizeof(addr), (struct sockaddr_in *)PT_REGS_PARM2(ctx));

u32 dest_ip = ntohl(addr.sin_addr.s_addr);
u16 dest_port = ntohs(addr.sin_port);

// Check against a BPF map of allowed IP:port pairs
u64 *allowed = bpf_map_lookup_elem(&allowed_endpoints, &dest_ip);
if (allowed && (*allowed & (1 << dest_port))) {
return 0; // Allowed
}

// Log the violation to a ring buffer for userspace
bpf_printk("Blocked unexpected connection from agent to %pI4:%d", dest_ip, dest_port);
return -EPERM; // Deny the syscall
}
```

The hygiene difficulty compounds because:
* **Toolchain Proliferation:** An agent might be granted access to a package manager, a shell, or a code interpreter, effectively embedding entire software ecosystems within its runtime permissions.
* **Non-Deterministic Execution Paths:** The same agent with the same code may invoke different tools based on user input, making allow-listing based on static analysis insufficient.
* **Data as Code:** Retrieved documents or API responses can contain disguised instructions (e.g., "Ignore previous instructions..."), turning data retrieval into a code-fetching operation.

Therefore, securing an AI agent supply chain shifts the focus from securing the build pipeline to securing the *runtime inference loop*. It demands runtime instrumentation—like eBPF or ftrace—to establish a baseline of normal tool usage and detect deviations indicative of a compromised reasoning chain or injected tool call. Without this layer, you are blind to the live dependencies being fetched and executed during each inference.