Agentic AI Attack Surface: 3 Findings from Our First TraceCtrl Workshop

What 16 developers learned about agent topology, OWASP-listed vulnerabilities, and the parts of AI agent observability they had not yet thought about.

We recently ran our first TraceCtrl workshop with the LorongAI community in Singapore, and the format was deliberately stripped back: 16 developers, varying levels of coding comfort, all working on or curious about agentic AI. People were invited to bring their own agents, or set up OpenClaw, then install TraceCtrl, run a scan, and see what came up.

What came out of the room was sharper than we expected, and it ran in three different directions. Each one says something specific about the agentic AI attack surface that most builders are not yet equipped to see.

1. Even simple AI agents create a complex attack surface

Several attendees brought their own agents to scan, and most were not exotic builds — a single agent with a handful of tool calls and a few skills, the kind of setup you would expect to be straightforward to reason about.

The topology maps told a different story. Once you trace every interaction end to end, even one agent with a few tools and skills opens a surprising number of distinct data flow routes. Tool calls become potential data egress points, skills can serve as injection vectors, and every handoff between components introduces another control boundary that must hold. Multiply those across a real workflow and the attack surface ends up several layers deeper than the agent code suggests.

This is the gap between how developers think about their agents and what the agents actually do at runtime. You build a logical workflow, but the system executes a graph, and the two are not the same shape, which is where most agentic AI security problems live.

2. Most developers are unaware of the vulnerabilities specific to AI agents

The second pattern was harder to miss once we started talking through scan results. Many participants were not aware of the specific risks that agentic AI introduces, and that is partly because traditional application security categories don’t capture those risks cleanly.

The OWASP Top 10 for Agentic Applications 2026, published by the OWASP GenAI Security Project in late 2025, names them directly: goal hijacking, privilege abuse, memory poisoning, insecure inter-agent communication, rogue agent behaviour, and several more. These are not theoretical concerns — they are the failure modes that production agent deployments are running into right now.

“It is a good tool to check vulnerability.”

What stood out in the room was not that developers dismissed these risks, but that several were encountering the categories for the first time. They had built agents and shipped agents, yet they had not yet been given a vocabulary or a framework for the specific things that can go wrong with them. AI agent observability tools that surface these risks in context, against a real workflow, tend to close that gap faster than any checklist can.

3. There is a vocabulary gap between agent builders and agent security

The most revealing reaction in the room wasn’t about a finding at all. It was about a concept:

“Agent sandbox mode - I didn’t even know that’s a thing.”

Sandboxed execution, agent isolation, runtime guardrails, control planes — these are basic vocabulary in agentic AI security circles, but they are not yet basic vocabulary among the developers actually building agents. That asymmetry is one of the structural problems with how agentic AI is being adopted: the people shipping agents and the people thinking about agent risk are often working from different word lists, and sometimes from different rooms entirely.

Closing this gap is not really a documentation problem; it’s a tooling problem. A developer can read about “privilege escalation through inherited tool permissions” and have the words slide off, because the concept is too abstract to stick. That same developer can run a scan, see their own agent reaching a data source they did not intend, and the concept becomes concrete in seconds. That is what hands-on AI agent observability is good for: it teaches the vocabulary by showing the thing.

What this means for teams shipping agents

Three findings, but one underlying point: the gap between what developers build and what they understand about it is real, and it is wider than the industry conversation suggests. Simple agents have non-obvious attack surfaces, most builders have not yet internalised the OWASP-listed agentic risks, and a fair amount of the security vocabulary is still genuinely new to the people putting agents into production.

None of this is fixable by reading a blog post. It is fixable by instrumenting an agent you have built and looking at what shows up.

Try it on your own agent

TraceCtrl is open source and OTEL-native, so you can install it, point it at an agent built on OpenClaw, AWS Strands, or any OTEL-compatible framework, and have a topology map and an attack surface analysis in minutes.

👉🏻 See the project on GitHub

👉🏻 Read the documentation