Notes from someone who has been spending time with multi-agent systems in security contexts. No results, no architecture, no claims. Just the problems that keep showing up and the way a student can start a research paper in this space.
Coordinating Agents Across Security Tasks
Security work does not fit into a single agent. You have reconnaissance, analysis, exploitation, verification, and reporting, and each one is a different kind of task with different inputs and different success criteria. Splitting them across agents sounds clean on paper. It does not stay clean.
The first problem is boundaries. Where does one agent’s responsibility end and the next begin? If the recon agent produces output that the analysis agent cannot parse, the chain breaks and nothing happens. If the boundaries are too loose, agents start doing each other’s work and you get duplicated effort and conflicting results.
The second problem is failure propagation. If agent A fails, does agent B wait, retry, or proceed on stale data? In a security context, proceeding on stale data is worse than stopping, because you might act on information that is no longer true. But stopping means the whole chain halts, and you need someone to notice and intervene.
Tool Use
Agents need tools. In security, the tools are things like network scanners, packet analyzers, log parsers, and access to systems. Each tool has its own interface, its own error modes, and its own rate limits. An agent that has never seen a tool before needs to learn its interface at runtime, because the environment changes.
The hard part is not calling the tool. It is knowing when not to call it. An agent with access to a powerful tool and no judgment about when to use it will burn through rate limits, trigger alerts, and produce noise that makes the real signal harder to find. Giving agents more capability is not always helpful. Sometimes it is actively harmful.
State Management
Security tasks are stateful. You enumerate a target, then you act on what you found, then you verify what you did, and the verification depends on the enumeration being accurate and the action being complete. If state gets lost between steps, the whole chain becomes unreliable.
State has to be persisted somewhere that every agent can read. It has to be versioned, because stale state is worse than no state. And it has to be auditable, because in security you need to be able to reconstruct what happened and why. That is a lot of infrastructure to build correctly, and it is easy to underbuild it when you are focused on the agents themselves.
How a Student Starts a Research Paper in This Area
Picking a problem comes first. State the problem in one sentence, name three papers that got closest to solving it, and explain exactly why they fell short. Everything before that is reading, not writing.
Reading and organising existing work means building a spreadsheet or a graph of papers, their assumptions, their datasets, and their evaluation metrics. Tag each paper by the sub‑problem it addresses. The gaps in that map become candidate contributions.
Defining the contribution is the hardest part. It must be specific enough to be testable and general enough to matter. Write the contribution as a single claim you can prove or disprove with an experiment.
Planning the evaluation is a design decision, not an afterthought. Before any implementation write down the metrics that would convince a reviewer, the baselines you will compare against, the datasets you need access to, and the ablation studies that isolate each component’s effect. If any of those cannot be answered with a concrete plan, go back to the problem definition.
What I Have Learned So Far
The pattern I keep seeing is that the agents are the easy part. The infrastructure around them — coordination, state, tool interfaces, communication, evaluation — is the hard part. Those problems do not show up in a demo, but if any one of them is wrong the agents do not matter. I am still early in this work. I do not have answers yet. I have a clearer sense of which problems are worth spending time on, and that is something.