Network-Level Characteristics of LLM-based AI Agents

This repository contains the code, scripts, and analysis pipeline for studying the network-level behavior of LLM-based AI agents. The project accompanies the paper:

📄 Network-Level Characteristics of LLM-based AI Agents: A Traffic Analysis Study

MAGIC 2026 · Management of Agentic Interaction and Communication CNSM 2026 Workshop — Alcalá de Henares (Madrid), Spain · 26–30 October, 2026

The goal of this work is to understand how different Large Language Model (LLM)-based agents behave on the network when they execute realistic tasks. We analyze traffic generated by both single-agent and multi-agent workflows across different LLM backends, tasks, and reasoning styles.

The study focuses on encrypted traffic metadata only. No application payload inspection is required.

Overview

LLM-based AI agents increasingly perform multi-step reasoning, invoke external tools, and interact with remote APIs. These interactions generate network traffic that may reveal information about the agent backend, task type, and execution mode.

This repository provides a reproducible framework for:

Running LLM-based AI agents with different model backends.
Capturing packet-level network traffic during agent execution.
Storing traffic traces as PCAP files.
Extracting packet-, flow-, and burst-level features.
Comparing traffic behavior across tasks, models, and agent architectures.
Training machine learning classifiers to identify the backend model and execution type from encrypted traffic metadata.

Code Structure and Execution

The repository is organized into four main directories, reflecting the pipeline from agent execution to traffic analysis to ML classification:

agents/         Agent implementations (single-agent ReAct, multi-agent planner/executor), Dockerfile
analysis/       PCAP parsing, feature extraction, and traffic visualization
experiements/   Scripts that orchestrate repeated/systematic agent runs
ml/             Feature-matrix conversion, Random Forest model, training/testing

`agents/`

react_agent.py — single-agent ReAct (Thought → Action → Observation → Answer) implementation. Supports OpenAI, Gemini, DeepSeek, and Ollama (Llama/Qwen/Mistral) backends, a weather_now tool (Open-Meteo), optional Google/SerpAPI search, and a "no-tools" mode. Captures all traffic generated during execution with scapy and writes it to a .pcap file, alongside events.jsonl / summary.jsonl logs.
planner_executor_agent.py — multi-agent implementation decomposed into Planner, Executor, and Synthesizer roles (built on langchain.agents.create_agent), used to study coordination overhead versus the single-agent case. Also captures traffic with scapy.
Dockerfile / requirements.txt — package an agent into a container so that only its own traffic is captured, isolated from unrelated host traffic.

`analysis/`

pcap_tools.py — shared helpers (built on scapy and pyshark) for parsing .pcap files into packet/flow tuples, separating inbound vs. outbound traffic by client IP, and computing burst statistics.
pcap_analysis.py — CLI script that reads a .pcap file and produces packet-count burst plots and transfer-volume plots, given a --client-ip.
pcap_clean.ipynb, traffic_analysis.ipynb, band_plot.ipynb — exploratory/descriptive analysis notebooks over captured traces.
pcap2mtam.ipynb — converts cleaned .pcap traces into the traffic-matrix (TAM) .npz arrays consumed by the ML pipeline in ml/datasets.

`experiements/`

Scripts named run{ID_or_name}.py (e.g. run1.py, run_random_prompt_120.py, run_research_agent_100.py, run_weather_agent_100.py, run_no-tools_agent_100.py, run_random_planner.py) each launch the react-agent (or planner/executor) Docker container repeatedly across backends/prompts to build up a labeled traffic dataset.
prompts.json — prompt sets driving the runs above.
error_detector.ipynb — checks run outputs/logs for failures.
Produces pcap/run{ID_or_name}/ and output/run{ID_or_name}/ subdirectories (created automatically) holding the raw traces and container outputs for each batch.

`ml/`

Adapted from Robust Fingerprinting and adjusted to this project's six-class problem (single-/multi-agent × OpenAI/Gemini/DeepSeek).

const_rf.py — shared constants (paths, class counts, TAM matrix length).
train.py / test.py — train and evaluate the Random Forest classifier (PyTorch) on the .npz datasets.
pre_recall.py — precision/recall/weighted-accuracy reporting.
models/RF.py — the RF model architecture; models/RandomForest_classifier*.ipynb — notebook variants (binary and multi-class).
datasets/ — pre-generated .npz train/test splits (no-tools_random_*, random_prompt_*, research_agent_*, research_random_*).

End-to-End Execution

Build the agent image (from agents/):
```
docker build -t react-agent .
```
Run an agent while capturing traffic:
```
docker run --rm -e GEMINI_API_KEY=<key> -v "$(pwd)/pcap:/app/pcap" react-agent \
  --prompt="What is the weather forecast in London, UK?" --backend=gemini
```
For systematic/batch data collection instead of a single run, use or adapt a script in experiements/ (see that directory's README).

Inspect a single trace (from analysis/):

python pcap_analysis.py ./pcap/react/openai-gpt-4o-mini-20251125-123406.pcap --client-ip=10.47.9.55

Build ML datasets: run analysis/pcap2mtam.ipynb to convert collected .pcap traces into the .npz TAM arrays under ml/datasets/.
Train / evaluate the classifier (from ml/):
```
python train.py
python test.py
```

Research Questions

This project investigates the following questions:

Do LLM-based AI agents produce measurable and reproducible network traffic signatures?
How do task type, tool usage, and reasoning style affect traffic volume, latency, burstiness, and flow behavior?
How does multi-agent coordination change the network footprint compared with single-agent execution?
Can encrypted traffic metadata be used to identify the underlying LLM backend and execution type?

Methodology

The methodology consists of five main stages:

Agent execution
Network traffic capture
PCAP trace storage
Feature extraction and traffic analysis
Machine learning-based model identification

1. Agent Architectures

The experiments evaluate two execution paradigms.

Single-Agent Architecture

In the single-agent setting, one LLM-based agent is responsible for:

Understanding the user prompt
Reasoning about the task
Invoking tools when needed
Producing the final response

This architecture represents a standard tool-using AI agent workflow.

Multi-Agent Architecture

In the multi-agent setting, the workflow is decomposed into multiple coordinated roles:

Planner: decomposes the task into structured subtasks.
Executor: performs each subtask and invokes external tools when needed.
Synthesizer: aggregates intermediate results and generates the final answer.

This architecture allows us to study how coordination between multiple LLM-based components affects network behavior.

Supported LLM Backends

The experimental framework supports multiple LLM providers, including:

OpenAI
Google Gemini
DeepSeek

The main paper evaluates representative models from OpenAI, Gemini, and DeepSeek under comparable task settings.

Task Configurations

The experiments use three representative task categories.

1. Weather Agent

A tool-dependent task that retrieves real-time weather information and generates recommendations based on the result.

Example prompt:

Get the current weather for London and recommend activities based on the conditions.

2. No-Tools Agent

A reasoning-only task where the model is restricted from using external tools. This configuration isolates the traffic generated mainly by LLM inference calls.

3. Research Assistant Agent

A tool-intensive task involving structured research search and abstract retrieval. This configuration uses external APIs such as the SCOPUS / Elsevier API and produces richer multi-step interaction patterns.

Example prompt:

What is the most cited machine learning paper in 2020?

Network Traffic Capture

Traffic is captured passively during each agent execution.

The capture process records all packets generated by the agent container, including:

Agent-to-LLM API traffic
Agent-to-tool API traffic
Responses from remote services
Traffic generated during multi-agent coordination

Packet capture is performed using Python-based tooling such as scapy and stored in standard .pcap format.

To improve isolation, the agents can be executed inside a Docker container. This reduces interference from unrelated host traffic and makes the generated traces easier to analyze.

Traffic Analysis Pipeline

After execution, the generated PCAP traces are processed offline.

The analysis pipeline extracts traffic features such as:

Total packet count
Total bytes sent
Total bytes received
Inbound and outbound traffic ratios
Execution duration / latency
TCP stream count
Packet rate statistics
Burst size
Burst duration
Temporal traffic structure

A traffic burst is defined as a period of network activity separated by at least 0.5 seconds of inactivity.

These features are used for both descriptive traffic analysis and supervised machine learning experiments.

Machine Learning Classification

The project evaluates whether encrypted network metadata can be used to identify:

The LLM backend The execution type: single-agent or multi-agent

This is formulated as a six-class classification problem:

Single-agent OpenAI Single-agent Gemini Single-agent DeepSeek Multi-agent OpenAI Multi-agent Gemini Multi-agent DeepSeek

A Random Forest classifier is used because it is robust for tabular network traffic features and can capture nonlinear relationships between packet-level, flow-level, and burst-level metrics.

The paper reports high classification accuracy across tasks, showing that LLM-based agents produce identifiable network signatures even when payloads are encrypted.

Key Findings

The study shows that:

LLM-based agents generate structured and measurable network traffic patterns. Task type strongly affects traffic volume and temporal behavior. Tool-augmented and research-assistant tasks produce more complex traffic than no-tools tasks. Multi-agent workflows introduce longer burst durations, higher variability, and more interleaved flows. Backend-specific traffic signatures remain visible across both single-agent and multi-agent executions. Encrypted traffic metadata can be used to identify both backend model and execution mode with high accuracy.

These findings have implications for:

Network monitoring AI traffic characterization Infrastructure provisioning Traffic engineering Privacy-preserving AI agent design Traffic fingerprinting defenses

Navigation Menu

Repository files navigation

Network-Level Characteristics of LLM-based AI Agents