“I Only Searched the Web.” The Packet Capture Tells Another Story.
Oliver Ripka
Your AI agent says it only searched the web.
The packet capture from its isolated environment shows connections to 17 remote IP addresses, 243 DNS queries, and 18 KB transmitted to one destination.
Those numbers are illustrative. They are not evidence of an attack. A browser can contact multiple services while opening a single page.
But they expose an important distinction: what an agent says it did and what its environment actually transmitted are different sources of evidence.
When an agent does something unexpected, ask it for an explanation. Then check the evidence.
A web page can become an instruction
An agent browsing the web encounters content written by other people. Some of that content may contain instructions intended to redirect its behavior.
Google identifies indirect prompt injection as a central threat to agentic browsers. Malicious instructions can appear in websites, third-party content, or user-generated material and cause unwanted actions, including the disclosure of sensitive information. Google’s agentic browser security analysis
The consequences depend on what the agent can access. Reading a hostile instruction is one thing. Having tools that can execute commands, access files, or communicate with external services makes the situation more consequential.
Microsoft’s research into AI agent frameworks documents vulnerability chains where prompt injection can lead to code execution. These are specific technical failures, not proof that every agent can escape its sandbox. They demonstrate why the permissions and tools surrounding a model matter. Microsoft’s research on agent frameworks
An agent’s final answer may not describe every connection, subprocess, redirect, or retry involved in completing its task. Its summary alone cannot establish what happened.
Give the investigation a second source of evidence
A packet capture records traffic visible at a particular observation point. Depending on the protocols, encryption, and capture quality, it can help answer:
| Investigation question | Potential packet evidence |
|---|---|
| Which destinations were contacted? | Remote IP addresses, ports, and visible hostname information |
| What happened first? | Packet timestamps and connection sequences |
| Which names were queried? | DNS requests and responses visible in the capture |
| How much traffic crossed the boundary? | Directional byte counts, with the counting method stated |
| Did a connection succeed? | Transport establishment, responses, resets, and timeouts |
| What application activity was visible? | Decoded requests and responses where available |
These observations help test the agent’s account.
If the task was to read a public documentation page, an additional connection deserves context. It might belong to a redirect, a content delivery network, an extension, or another legitimate dependency. It might also be unrelated to the requested work.
The useful question is what explains that connection, and what evidence supports the explanation?
Unexpected traffic is a lead, not a verdict
Imagine an agent fetching documentation and then establishing an encrypted connection to a destination absent from a comparison run.
A useful investigation would establish:
- when the connection began relative to the browsing activity;
- whether a visible DNS lookup preceded it;
- how much data flowed in each direction;
- whether the destination appeared in the retrieved content;
- whether endpoint or tool logs identify the process responsible.
That creates a specific lead for further investigation.
It does not yet establish that a secret was stolen, that prompt injection succeeded, or that the agent escaped a sandbox. An allowed outbound connection can occur without any sandbox escape.
The same discipline applies to byte counts. “18 KB sent” should identify whether it means captured frame bytes, transport payload, or another measurement. Retransmissions and protocol overhead can affect the total. Encrypted traffic volume does not reveal the contents of the transfer.
Precise observations make stronger investigations than dramatic labels.
Capture the agent’s environment, then establish attribution
A capture from your laptop may contain traffic from browsers, synchronization clients, update services, and other applications. Activity occurring while an agent runs is not automatically activity caused by that agent.
A dedicated container or virtual machine can make the observation boundary easier to understand. Capture its network traffic, record the task’s start and end times, and retain the agent’s tool history and relevant endpoint logs.
Even then, background processes inside that environment may communicate independently. Use process telemetry when you need to attribute a connection to a particular executable.
Keep the original capture and record the capture interface, filters, packet drops, and any packet slicing. Those details determine which conclusions the evidence can support.
A comparison run can also help distinguish ordinary startup traffic from activity specific to the task. Differences still need interpretation: web content and service infrastructure can change between runs.
What encryption leaves unanswered
An encrypted connection can reveal useful timing and transport behavior while hiding the application exchange.
A connection to an API endpoint does not, by itself, prove successful authentication. A burst of outbound traffic does not prove that a particular file was uploaded. A hostname may also be unavailable when name resolution or handshake information is encrypted.
Stronger conclusions may require application audit records, endpoint telemetry, agent tool logs, or authorized decryption material.
Packets are one part of the record. Their value comes from establishing what was observable and connecting it to the other evidence.
Where PacketSafari fits
PacketSafari helps investigate the captured network activity: identify relevant conversations, examine timing and protocol behavior, and connect an explanation to inspectable packet evidence.
The question can be concrete:
During this task, which external destinations did the captured environment contact, what traffic was exchanged, and which observations need further explanation?
A useful result distinguishes direct observations from hypotheses. It identifies supporting packets, explains capture limitations, and states what evidence would resolve the remaining uncertainty.
That is also how to evaluate the analysis itself. PacketSafari uses AI in its investigation workflow, so its conclusions deserve the same scrutiny as the agent’s original account. Confidence in the wording is not a substitute for supporting evidence.
The packet evidence verification guide explains what makes a conclusion reviewable.
Check the story against the traffic
As agents gain access to browsers, terminals, files, and APIs, their actions become harder to understand from a final chat message alone.
Network evidence provides another view. Combined with tool and endpoint logs, it can help establish what the environment contacted, what crossed the observed boundary, and where the explanation remains incomplete.
“I only searched the web” is a claim. A packet capture gives you something to check.
Talk to PacketSafari about investigating agent-generated traffic, with a workflow scoped to your capture environment, existing tools, and evidence requirements.