What AgentSight network target counts actually measure

Short answer: a destination summary over normalized events

The v1.0.35 projection calls network_target_from_event for each canonical event. An event without a nonempty host yields no target; an event with a host contributes one row with count = 1, optional process ID and command, optional path, and its observation timestamp. This step runs before the more specific LLM request/response correlation. Consequently, a captured request and a captured response can both contribute to the same destination summary. One row is not a packet trace or a flow record.

This is a source-level interpretation of the published AgentSight v1.0.35 tree at commit c1574366122a90c451bca6a84713e28813ab95e2, not a new measured dataset or a promise about every runtime and capture mode.

The exact grouping rule and what it discards

The materialized-view key is (pid.unwrap_or_default(), host, path.unwrap_or_default()). Rows with that key share a counter even if their command names differ. For an existing key, the view adds count and error_count, keeps the earliest first timestamp and latest last timestamp, and leaves the original command name in place. The SQLite sink independently implements the same PID, host and path grouping with a stable length-delimited ID.

Important null boundary: a missing PID uses zero for grouping, but a missing PID in the exported row still means unknown identity. A missing path and an empty path likewise share the key. Host text is taken from normalized capture evidence; the grouping key does not include TCP port, transport protocol, HTTP method, request ID, connection ID or stream ID. Do not retrofit those dimensions into the count.

A live snapshot sorts target rows by descending count, then host and path. A large count therefore brings a destination to the top of the list; it is not a bandwidth ranking or an indication of relative risk.

What does the error counter mean?

The projector sets error_count = 1 when the normalized event kind is LlmError or the event has an HTTP status code of at least 400. Otherwise it contributes zero. That logic is applied independently for each event that has a host. It does not inspect socket return codes, verify whether a TLS connection completed, or determine if an agent task failed. For a correlated HTTP exchange, refer to the HTTP request/response pairing analysisbefore interpreting any per-call failure.

For example, an aggregate of 12 contributions with 3 classified errors is not sufficient evidence of a 25% HTTP request failure rate. To calculate that rate, first establish a denominator of unique requests, define the failure outcome, and account for missing or duplicated observations.

Ten evidence decisions for a security or reliability review

Observation	Supported conclusion	Not established
Two normalized events share pid, host and path	The materialized view adds both count values to one network target.	Two distinct TCP connections, or even two unique HTTP requests.
A request and its response both carry the same host and path	Both can enter the aggregation because the projector checks every normalized event with a nonempty host.	A one-to-one relationship between a row count and completed request/response pairs.
An event has HTTP status 429	That event contributes one to error_count because status is at least 400.	A socket error, TLS handshake failure, or confirmed failed connection.
The event kind is LlmError without a status code	It contributes one to error_count if it has a nonempty host.	A specific HTTP status or known root cause.
A network event has no host value	The network-target projection skips it.	No packet, connection, DNS lookup, or network side effect occurred.
pid is null in two otherwise identical rows	The aggregation uses a fallback zero in its key; these rows can combine.	A real process with PID 0, or independently attributable agent processes.
The command name changes but pid, host and path do not	comm is not part of the aggregation key; the existing row retains its previous comm.	The displayed command necessarily names every process observed in that aggregate.
count is 12 and error_count is 3	The view summed 12 event contributions and classified 3 of those contributions as errors.	A 25% failure rate for individual user requests, sockets, or agent tasks.
first and last timestamps are one minute apart	They are the minimum and maximum observed event timestamps in that group.	A minute-long network session or a measurement of connection latency.
path contains a URL token or private identifier	The field may preserve a raw observed request path.	That exporting or publishing network target rows is automatically safe.

Inspect a saved snapshot without leaking observed paths

A reproducible review starts with an authorized, already-recorded local session. Export and inspect only numeric fields; do not paste raw hosts, paths or captured HTTP payloads into a public issue or CI log. These commands are a proposed source-backed inspection procedure, not an executed capture experiment.

agentsight report export --db ./agentsight-run.db -o snapshot.json
jq '{schema: .schema_version, groups: (.network_targets | length), counts: ([.network_targets[] | .count] | add // 0), classified_errors: ([.network_targets[] | .error_count] | add // 0)}' snapshot.json
jq '[.network_targets[] | {pid_known: (.pid != null), path_present: (.path != null), count, error_count, first_timestamp_ms, last_timestamp_ms}][:10]' snapshot.json

To validate the implementation without private trace data, check out the release and inspect the exact projection, grouping key, and SQLite upsert:

git checkout v1.0.35
rg -n "network_target_from_event|error_count" ext/analysis/src/view/projection.rs
rg -n "upsert_network_target|network_target_key" ext/analysis/src/view/mod.rs
rg -n "network_target_id|INSERT INTO network_targets" ext/analysis/src/sinks/sqlite.rs

The next step for a real investigation is to cross-check any suspicious destination against independently attributable process events and exchange-level evidence. Neither a host name nor a raw request path by itself demonstrates what data was transmitted, who initiated it, or whether the destination received it. See the file-open evidence guidefor a separate filesystem boundary.

Absence, sensitivity and limits

A zero-length target array means the selected view has no projected rows with nonempty hosts. It does not prove absence of network activity: uninstrumented transports, incomplete captures, missing host extraction and lost events remain possible. The capture-loss guidecovers those evidence limits; the snapshot contractcovers export completeness and source selection.

Destination names and especially paths can contain sensitive project names, request identifiers or tokens. AgentSight documents raw paths as not generally normalized or redacted. Keep raw session databases and JSON snapshots local or apply a deliberate sanitization and access-control policy before sharing. Network summaries aid triage; they do not replace endpoint enforcement, packet-level forensics, or application-authenticated audit trails.

First-party references

The semantics above are pinned to the product source, not inferred from a screenshot.

Need command syntax and capture setup? Read the canonical AgentSight documentation. Review the site's data-handling guidance.