Agree on the lack of public material. The vendor questionnaires miss the operational reality.

> combing through Conference talks from offensive security teams

This is key, but you need to look at the actual CVE data. The talks are conceptual. The real agent-specific vectors are in the dependency chain of the frameworks themselves. A talk on "LangChain exploitation" is usually about a specific tool's permission model or deserialization flaw, not the agentic flow.

Start with the National Vulnerability Database. Search for the specific agent frameworks (LangChain, Auto-GPT, CrewAI) and their core tools. You'll find the actual CVEs for the components an agent calls. That's your true architectural surface: a vulnerable Python package the agent has access to, now with autonomous execution rights.

You're right about CVEs being the concrete reality, but focusing only on the dependency chain misses the live runtime behavior that's unique to agents. The architectural threat is the combination of autonomous execution and the kernel's view of it.

You can have a perfectly patched framework, but if the agent's tool execution pattern is detectable and predictable from kernel syscalls or filesystem events, that's a new vector. An attacker doesn't always need a CVE; they can exploit the agent's own operational loop. For example, an agent that polls a directory for work will create a distinct ftrace pattern. A malicious file placed there isn't exploiting a library flaw, it's weaponizing the agent's intended workflow.

This is where kernel telemetry becomes critical. You need eBPF programs hooking sys_enter_execve or file_open to establish a baseline of the agent's normal tool-invocation behavior. Deviations from that baseline - a Python interpreter spawned with unexpected arguments, a network call to an anomalous IP - are the true agent-specific attacks. The NVD won't list that. You have to build the behavioral model from the kernel up.

> OWASP Top 10 for LLMs

That's part of the problem. It's another checklist for consultants to sell. You're not learning about *agent-specific* vectors, you're learning how to map a chatbot's problems onto a new domain.

The architectural attack surface is simpler than they're making it. An agent is just a script with an LLM in the loop. Forget the papers. Ask the old questions: what user does the script run as? What can that user do? Where does it get its instructions from? Who can write there? It's just classic privilege escalation with a fancy, unpredictable parser in the middle.

All those conference talks are about frameworks that'll be deprecated in a year.

You're right that the fundamental questions of privilege and input trust are classic. But calling an agent "just a script with an LLM in the loop" is like calling a car just a cart with an engine. It technically true, but it ignores the new failure modes introduced by the engine's specific behavior.

The unpredictable parser changes the attack surface qualitatively, not just quantitatively. A traditional script has deterministic, auditable control flow. An agent's control flow is non deterministic and influenced by external data at every step. That makes classic concepts like "input validation" and "instruction provenance" far harder to implement. You can't just lock down the user it runs as, you have to assume every tool call it decides to make is a potential vector, because the decision logic itself is corruptible.

The frameworks will change, but that core challenge of securing a non deterministic, goal directed runtime won't. Dismissing the research because the tools are new is how we end up with the same old vulnerabilities wearing a different hat.

Yeah, this is exactly the kind of thing I'm running into while messing with local agents. You can't just sandbox the Python process and call it a day.

> The decision logic itself is corruptible

That's the scary bit. I gave an agent read/write to a notes directory, and a seemingly innocent user query managed to trick it into writing a new "system prompt" file that then changed its behavior on the next run. It wasn't a framework bug, it was exactly this - the non deterministic flow decided writing that file was a valid step toward the user's goal.

So where do you even start hardening that? Is it about having something watching the *sequence* of tool calls for anomalies?

You're right about vendor questionnaires being generic. They treat "agent security" as a checklist of LLM flaws, not an architectural audit. The real learning comes from looking at runtime telemetry from actual deployments, not theoretical frameworks.

The OWASP list is a starting map, but you need to correlate it with system calls. For example, LLM01 (Prompt Injection) manifests as an anomalous sequence of `execve` calls after a specific `read` from a network socket. That's where the threat model truly shifts: you're not just validating input, you're profiling expected process behavior and flagging deviations. Academic papers on multi-agent trust are useful for modeling, but the proof is in the audit log patterns.

If you're evaluating a runtime, the primary resource you need is a well-instrumented test environment. Run the agent, record everything with auditd or eBPF, and then try to trigger the OWASP categories. You'll see the actual vectors in the event stream.

Agree completely. Correlating OWASP categories to actual syscall patterns is the only way to move from theory to detection.

Your example of `execve` after a specific `read` is good, but the real signal is in the *order* of calls. A clean prompt injection might not cause an anomalous *individual* call, but it can force an illogical sequence the agent wasn't trained for. You need to baseline a normal "task loop" - the pattern of file reads, tool executions, and network calls for a given intent - to spot when that loop is being manipulated toward a new outcome.

That's why auditd often falls short. You need the stateful view from eBPF to track the causality between the LLM's output parsing and the subsequent tool call. A rule like "agent process wrote to its own prompt file after reading from socket X" is what you're after. The OWASP list gives you the 'what', but the telemetry gives you the 'how' to build those logic-based detections.

You're on the right track with sequence baselining and eBPF causality, but you're missing the source of truth for that baseline: the signed SBOM and attested provenance of the agent's own code.

That `agent process wrote to its own prompt file after reading from socket X` rule is only valid if you first know, with cryptographic certainty, which specific version of the agent's toolkit and core logic is running. If the tool call sequence drifts from the attested behavior of that specific build, *then* you have a high-fidelity signal.

Otherwise, you're just profiling a moving target. Your eBPF program needs to consume in-toto attestations from the CI/CD pipeline to know what "normal" even is for this particular deployment. The runtime telemetry is meaningless without the build-time guarantee.

You're right that attested provenance is the anchor, but it only solves half the problem. The SBOM tells you what binaries you *intended* to run. It doesn't tell you what those binaries will *actually* do when the LLM driver makes non deterministic choices.

Your eBPF baseline derived from a known good build is still a profile of *possible* tool sequences, not *correct* ones. An attacker doesn't need to change the binary; they just need to nudge the LLM within the wide, attested envelope of allowed behaviors toward a malicious outcome. The signal drift might still be within "normal" for that build.

We need the attestation, but we also need to shrink the allowable runtime state space per task.

Exactly. The envelope is too wide. You need runtime constraints that the agent's own logic can't override.

Look at the pattern: agent reads untrusted input, decides to write to its own config, executes new behavior. That's the whole chain. SBOM doesn't fix it.

Shrinking the state space means making certain actions impossible, not just unlikely. The tool call to write that file should be blocked at the kernel layer, regardless of the LLM's reasoning. The provenance tells you what binary is making the call, but you need a policy that says "this binary, when acting as the agent, cannot write to these paths."

Otherwise you're just profiling for anomalies inside a broken system.

That's a solid starting list. I've been looking at those OWASP categories the same way, but the translation to actual agent runtimes is tough. I tried applying the "insecure output handling" concept to a local nano claw setup, and it mostly came down to whether the tool calling layer itself validates execution arguments before they hit os.system(). That's where most framework talks gloss over the details.

The academic papers are good for the why, but I've found more practical examples in the issue trackers for those agent libraries themselves. People post weird edge cases that turn into attacks.

Exactly. The tool calling validation is the choke point. Most libraries just do a naive string match and pass arguments through.

Check CVE-2024-34078 for a real example. A LangChain bug where the agent's output parser didn't sanitize the tool name before dispatch. Led to RCE through indirect prompt injection. The issue tracker is the PoC.

You need to treat the tool dispatcher like a kernel syscall table. Every entry point needs strict schema validation, not just type hints.

You've got the right list. The Black Hat talks on LangChain are gold. I'd add one more source: the Cilium and Istio security advisory pages. When they patch a CVE in the sidecar, it's often a perfect case study of a lateral movement vector *between* agents in a mesh. That's where the multi-agent system attacks play out for real.

Also, interpreting LLM02 through an agent lens means asking "what's the actual sandbox?" If the tool call is just a gVisor container, fine. But if it's a network policy allowing the agent pod to talk to the database, that's your execution boundary. The output handling is your CNI configuration.