AI + Network Visibility

What Your AI Assistant Can't See (And How to Fix It)

When your Stripe integration fails at 2am, Claude or Copilot can read your SDK calls, trace your error handling logic, and even suggest fixes based on the documentation. What it can't do is see the 401 Unauthorized response that Stripe is actually returning, or notice that you're accidentally sending the test API key to production.

This blind spot is a data access problem. Your AI assistant lives in a world of static code and documentation. The live network traffic that would tell it exactly what's going wrong? Invisible.

Until you give it eyes.

The Debugging Gap

Consider a typical debugging session with an AI assistant:

You: "My payment integration is failing. Here's the code."

AI: reads your code "Your implementation looks correct. The error handling follows best practices. Have you verified your API keys are set correctly? Here are some things to check..."

This is helpful, but it's educated guessing. The AI is reasoning from code structure and documentation, disconnected from what's actually happening when your code runs.

Now imagine the same session with network visibility:

You: "My payment integration is failing."

AI: captures live traffic "I can see the issue. Your app is sending POST /v1/charges to Stripe, but getting back 402 Payment Required with the response: {error: {code: 'card_declined', decline_code: 'insufficient_funds'}}. The test card you're using simulates a declined payment. Try card number 4242424242424242 instead."

Same question. Radically different answer. The difference is access to ground truth.

Giving AI Eyes on the Network

Qpoint builds tools for network visibility. Our open-source agent, Qtap, uses eBPF to capture HTTP traffic directly from the Linux kernel, before TLS encryption happens. No proxies to configure, no certificates to manage, no code changes required. You run Qtap on a host, and it sees every HTTP request and response made by every process on that machine.

Qtap DevTools is a feature we built for real-time debugging: a browser-based interface showing live HTTP traffic as it flows, complete with headers, bodies, timing, and the exact process or container that made each request. Think Chrome DevTools for your server's network activity.

DevTools also exposes a streaming API. Any tool that can consume Server-Sent Events can subscribe to the traffic stream and build on top of it. Which brings us to MCP.

Connecting AI to Live Traffic with MCP

The Model Context Protocol (MCP) is an open standard that lets AI assistants connect to external data sources through defined tool interfaces. Instead of just reading files, an AI with MCP can query databases, call APIs, or subscribe to event streams.

We built an MCP server that connects AI assistants to DevTools. When you wire it up to Claude Code, Codex CLI, or ChatGPT, your AI gains the ability to capture and analyze live network traffic on demand.

Here's what that looks like in practice:

You: "What external APIs is my app calling?"

Claude: [Calling get_hosts tool...]
"Your application is connecting to 16 external services:
- api.stripe.com (23 requests, all 200s)
- api.openai.com (12 requests, 3 returned 429 rate limit errors)
- hooks.slack.com (8 requests)
- api.segment.io (47 requests)
..."

The AI watched your actual traffic and reported exactly what's happening, including the rate limit errors you didn't know about.

Making It Fast Enough for Production

The naive approach to AI traffic analysis would be: capture everything, send it all to the AI, let it figure out what's relevant.

This works fine in a demo. In production, it falls apart.

A busy microservices environment generates thousands of HTTP transactions per minute. Streaming all of that to an MCP server means bandwidth overload, context window limits, and latency that defeats the purpose during an active incident.

The solution is server-side filtering. Instead of capturing everything and filtering later, you tell Qtap exactly what you want at the kernel level:

# Without server-side filtering
DevTools API → All Events (1000s) → MCP Server → Filter → AI
                                     (decode all)  (discard most)

# With server-side filtering
DevTools API + Filter → Matching Events (10s) → MCP Server → AI
                          (pre-filtered)          (decode matches)

When you ask "What errors are happening in the payment service?", the MCP server sends this filter expression to Qtap:

res.status >= 400 AND container.name == "payment-service"

Qtap applies this filter at the kernel level, before events ever leave the host. Your AI receives only the matching transactions, typically dozens when you might otherwise have thousands. The response comes back in seconds.

The filter language supports the fields you'd expect: HTTP method, status code, host, path, request direction, plus process and container metadata. You can combine conditions with AND/OR logic. A few examples:

This filtering happens before the data hits your MCP server, which means you can run AI-assisted debugging against high-traffic production systems without drowning in data.

Building Blocks for Different Problems

The combination of DevTools, MCP, and server-side filtering gives you building blocks that can be assembled for different use cases.

Real-time debugging is the most obvious. When something breaks, you ask your AI what's happening, it captures filtered traffic, and tells you what it sees. No log correlation, no manual inspection, no context switching.

Security auditing becomes conversational. Instead of writing scripts to scan for credential leakage, you ask: "Are we sending any sensitive data to external services?" The MCP server captures traffic, scans for patterns like API keys, passwords, and tokens, and reports what it finds along with which process sent it and where it went.

Incident response gets faster. During an outage, you can ask "What changed in the last hour?" and get a comparison of traffic patterns, new error types, or API endpoints that started failing. The AI has access to the same ground truth your network has, so it can give you specific, actionable answers.

Dependency discovery happens automatically. "What external services does this container talk to?" becomes a question you can answer in seconds, with actual traffic data backing up the answer.

What This Looks Like in Practice

Let's walk through a concrete example. Your on-call engineer gets paged: payment failures are spiking.

Traditional approach: SSH into the box, tail logs, grep for errors, correlate timestamps, manually inspect payloads, form hypotheses, repeat.

With AI-assisted debugging:

You: "What's failing in the payment service right now?"

Claude: [Calling get_errors_by_container("payment-service")]
"Found 47 errors in payment-service over the last 60 seconds:

1. POST /v1/charges → 500 Internal Server Error (31 occurrences)
   Response: {"error": {"type": "api_error", "message": "Request timed out"}}

2. POST /v1/charges → 402 Payment Required (12 occurrences)
   Response: {"error": {"code": "card_declined"}}

3. GET /v1/customers/cus_xxx → 404 Not Found (4 occurrences)

The 500s suggest Stripe is experiencing latency—checking their status page
would confirm. The 402s are expected business logic (declined cards).
The 404s might indicate stale customer IDs in your cache."

Time to diagnosis: under a minute. The AI captured the relevant traffic, categorized the errors, showed you the actual response bodies, and offered reasonable hypotheses.

Another scenario: your security team wants to audit what sensitive data is being sent to external APIs.

You: "Check for sensitive data in our external API calls"

Claude: [Calling check_sensitive_data()]
"Found 3 requests with potentially sensitive data:

1. POST api.analytics.io/v1/track
   - 'password' field in request body containing cleartext password
   - Source: container 'user-service', process '/app/server'

2. POST api.openai.com/v1/chat/completions
   - API key pattern detected in prompt text: 'sk-proj-xxxxx'
   - Source: container 'ai-assistant', process 'python3'

3. GET legacy-api.internal/users
   - SSN pattern in response body: '123-45-6789'
   - Source: container 'reporting-service'

Recommendations:
- #1: Your analytics tracking is capturing user passwords—audit what fields you're sending
- #2: An API key is being included in prompts to OpenAI—check your prompt construction
- #3: The legacy API is returning unmasked SSNs—consider data masking"

The AI captured external traffic, scanned for sensitive patterns, identified the source containers, and explained the implications. An expert analyst who can see inside encrypted traffic, understands what patterns matter, and works on demand.

The Technical Foundation

All of this relies on eBPF-based traffic capture. Qtap instruments the Linux kernel to observe network traffic before TLS encryption, which means:

Complete visibility: The AI sees every HTTP transaction, including ones that never make it to your application logs. Failed requests, timeouts, malformed responses—everything.

Process attribution: Every request is tagged with the exact process, container, and pod that made it. When the AI reports an issue, it can tell you exactly which component is responsible.

Zero overhead: eBPF runs in a kernel sandbox with strict safety guarantees. The Linux kernel verifies every eBPF program before execution, ensuring it can't crash your system or access unauthorized memory. Safe to run during production incidents.

No blind spots: Works for any language, any framework, any HTTP client library. If it makes an HTTP request on that host, Qtap sees it.

When you combine kernel-level visibility with server-side filtering and AI analysis, you get conversational debugging of live production traffic.

Getting Started

The setup takes about 10 minutes.

1. Install Qtap with DevTools enabled:

curl -s https://get.qpoint.io/install | sudo sh
sudo qtap --enable-dev-tools

2. Verify DevTools is running:

# You should see a stream of events
curl -sN http://localhost:10001/devtools/api/events | head -5

# Or open the browser UI
open http://localhost:10001/devtools

3. Set up the MCP server (full code in our DevTools MCP guide):

pip install mcp httpx
# Download devtools_mcp.py from the guide
chmod +x devtools_mcp.py

4. Connect to your AI assistant:

# Claude Code
claude mcp add devtools -- python3 /path/to/devtools_mcp.py

# Codex CLI
codex mcp add devtools -- python3 /path/to/devtools_mcp.py

5. Start debugging:

You: "What's happening with my network traffic?"

For high-traffic environments, use our enhanced MCP server with server-side filtering. For local-only setups without external API dependencies, we have a guide for running with Ollama and local models like Qwen.

Closing the Gap

AI coding assistants are getting remarkably good at understanding and generating code. But code understanding is only half the picture. The other half is runtime understanding: knowing what your code is actually doing when it runs.

Logs capture what your application decides to record. Metrics capture what you decide to measure. Network traffic captures everything, whether you planned for it or not.

By giving AI assistants access to that traffic, filtered efficiently and analyzed intelligently, we move from educated guessing to actual understanding. The gap between "your code looks correct" and "I can see exactly what's failing" is the gap between a suggestion and a solution.

Qpoint builds tools for network visibility. Qtap is our open-source eBPF agent for capturing HTTP traffic. DevTools is included in Qtap for real-time debugging. Get started in 5 minutes.