AgentSonar: Detecting Shadow AI Through Network Traffic Heuristics
Hook
Your developers are probably using Claude, ChatGPT, Cursor, or other AI tools right now—and your security team has no idea. Shadow AI isn’t a policy problem; it’s a visibility problem.
Context
The explosion of AI coding assistants and LLM-powered tools has created a new security blind spot. Developers install Cursor, sign up for Anthropic’s API, or run local AI agents without IT approval, exfiltrating code and proprietary data through channels that traditional DLP and CASB solutions never see. Unlike SaaS apps that route through known domains, AI tools span dozens of API endpoints, desktop applications, and browser extensions. Maintaining blocklists is futile—new tools launch weekly.
AgentSonar takes a different approach: instead of tracking which AI services exist, it detects the network signature of LLM communication itself. Built by Knostic, this open-source Go tool monitors outbound traffic, associates connections with local processes, and uses traffic-shape heuristics to identify AI API usage. It’s designed for security teams who need visibility into shadow AI without deploying enterprise-scale infrastructure, and for SOC analysts who want to triage suspicious network behavior on individual workstations.
Technical Insight
AgentSonar’s architecture centers on three components: packet capture via libpcap, socket-to-process association through the OS networking stack, and a heuristic classifier that scores traffic patterns. When you run agentsonar, it opens a packet capture handle on your network interface (defaulting to en0 on macOS) and starts listening for outbound TCP connections. For each connection, it extracts the destination domain from either TLS Server Name Indication (SNI) during the handshake or DNS queries. Simultaneously, it performs socket ownership lookups to determine which process initiated the connection.
The classifier analyzes traffic shape to identify LLM API communication rather than maintaining a list of known AI domains. The heuristic examines byte/packet ratios (LLM APIs typically show asymmetric traffic: small outbound prompts, large inbound completions), connection duration (streaming responses keep connections open longer than typical HTTP), packet size distribution (token-by-token streaming produces many small packets), and programmatic TLS characteristics. Each process-domain pair receives an AI score from 0 to 1, where high scores indicate likely LLM traffic.
Here’s how classify-only mode works when you want to analyze pre-captured traffic:
echo '{
"proc":"cursor",
"domain":"api.anthropic.com",
"source":"tls",
"extras":{
"bytes_in":"50000",
"bytes_out":"1000",
"packets_in":"300",
"packets_out":"10",
"duration_ms":"10000",
"programmatic":"true"
}
}' | agentsonar classifyThe classifier examines the asymmetry (50KB inbound vs 1KB outbound), the packet distribution (300 packets receiving vs 10 sending suggests streaming), and the duration (10 seconds indicates a long-lived connection). This pattern would likely score near 1.0. Contrast this with a typical REST API call: roughly symmetric bytes, fewer packets, sub-second duration.
The tool maintains three classification categories in its local database. Known agents are process-domain pairs you’ve explicitly defined (e.g., claude* → *.anthropic.com), which always score 1.0 and can be filtered in the UI. Noise domains are endpoints you’ve marked as non-AI (like google.com), which score 0 and get suppressed. Everything else flows through the heuristic classifier. The agentsonar triage command presents high-scoring unknowns for manual review, letting you build a personalized detection model:
agentsonar triage
# Shows: "copilot" -> "api.github.com" (score: 0.85)
# Options: [a]gent, [n]oise, [s]kipThis triage workflow is important because network heuristics are probabilistic. By labeling unknowns, you train the system to your environment. Classifications can be exported and shared via agentsonar export.
The --enable-pid0 flag addresses a key architectural limitation: process association fails in containerized environments, for proxied traffic, or when analyzing mirrored packets from a TAP port. With this flag enabled, AgentSonar captures all traffic regardless of whether it can determine the originating process, recording the domain with process marked as empty. This is essential for deployment scenarios like monitoring a corporate gateway or analyzing pcap files from another host. You sacrifice granularity (can’t tell which local process made the request) but gain coverage of traffic that would otherwise be invisible.
Gotcha
The privilege requirements are the first hurdle. AgentSonar needs CAP_NET_RAW and CAP_NET_ADMIN on Linux or BPF device access on macOS to capture packets. The agentsonar install command handles this by setting file capabilities or creating the access_bpf group, but enterprise security policies often restrict running privileged network capture tools on endpoints. You’re asking for the same permissions that tcpdump requires, which raises red flags in hardened environments. If your organization already blocks packet capture utilities, AgentSonar is a non-starter without policy exceptions.
Process association limitations create blind spots. In containerized environments, namespace isolation prevents the tool from resolving PIDs for traffic originating inside containers. If your developers run AI tools in containers, you’ll see the traffic but won’t know which container generated it unless you run AgentSonar inside each container—which defeats the purpose of host-based monitoring. Similarly, if traffic routes through a local proxy (common in enterprise networks), socket ownership lookups return the proxy process, not the originating application. The --enable-pid0 flag helps, but you lose the ability to attribute traffic to specific applications, reducing detection to domain-level visibility.
The heuristic classifier is probabilistic, not deterministic. Traffic that looks like an LLM API might be other types of streaming or long-lived connections. False positives require manual triage, which doesn’t scale beyond a limited number of workstations. Conversely, AI tools that use atypical traffic patterns might score low and slip through. The tool uses traffic shape heuristics, meaning it’s pattern-based analysis. You need to invest time in the triage workflow to tune it to your environment, and even then, determined users can evade detection by routing AI traffic through VPNs or using browser-based tools that blend with normal web traffic.
Verdict
Use AgentSonar if you need lightweight, host-based visibility into potential shadow AI usage without deploying enterprise DLP or CASB infrastructure. It’s ideal for security teams managing a limited number of developer workstations, SOC analysts investigating suspicious network behavior on individual machines, or smaller organizations that can tolerate manual triage of high-scoring traffic. The classify-only mode is particularly valuable for offline forensics—analyzing packet captures from incidents to determine if AI tools were involved. If you’re a security researcher building detection rules, the export/import workflow enables sharing classifications. Skip it if you require enterprise-scale deployment with centralized management and reporting, operate in environments with strict prohibitions on privileged network capture tools, or rely heavily on containerized workflows where process association fails. For production enterprise environments dealing with many endpoints, the limitations around manual triage, privilege requirements, and lack of centralized visibility may make the commercial Knostic platform a better fit. AgentSonar is a reconnaissance and detection tool—think of it as network-based threat hunting for AI usage, with the understanding that it identifies potential AI traffic rather than providing enforcement capabilities.
