Your Prompt Leaves the Building: A 20-Minute Egress Trace Before You Trust Free Hosted AI

Last Tuesday, I ran a packet capture on our dev network and watched a teammate's prompt leave the building. It took about ninety seconds to see the first TLS handshake. The destination was not the one I expected.

That's the moment "free hosted AI" stops being a pricing question and becomes a network question. Where does your code go before it comes back as a suggestion? Most teams answer that with a vendor's privacy page. I'd rather answer it with a packet trace.

MonkeyCode is an open-source AI coding tool that offers a free model tier and a free hosted server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I'm not going to tell you whether that free server is trustworthy. I'm going to show you how to check it yourself in about twenty minutes. Open source gives you that option. Most teams never use it.

Why egress is the real free-tier question

A free hosted server is still a server. It has neighbors, it has logs, and it sits somewhere you can't see. The cost model says $0. The network model says: your prompts travel over the public internet to infrastructure you don't control.

Three things can go wrong, and only one of them is malicious:

1. The documented API endpoint is fine, but the client also phones home to a telemetry domain. This is common, and it's not always disclosed on the marketing page.
2. The endpoint is a proxy, not the final destination. Your prompt may be forwarded to a model provider you didn't research.
3. The client updates silently. What was true last month may not be true after today's auto-update.

You can't fix these with a scorecard. You fix them by looking at the traffic.

The 20-minute egress trace

You need a machine where the AI client runs, plus sudo or admin rights. That's it.

Step 1: Find the client's live connections

Run the client, generate a prompt, and watch which sockets open:

sudo lsof -i -n -P | grep -E "node|python|monkey" | grep ESTABLISHED

On Linux, ss -tunap works too. The output gives you IPs and ports. The port will be 443. The IPs are where your code is going.

Step 2: Resolve the hostnames

dig +short 203.0.113.7
# or
nslookup 203.0.113.7

Write down every hostname. This is your observed egress list.

Step 3: Inspect the TLS certificate

openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Check the subject. Check the issuer. Check the validity dates. A cert that expired last week is a signal, not a dealbreaker — but it's a signal.

Step 4: Capture a real session

sudo tcpdump -i any -n host 192.0.2.10 and port 443 -w ai-traffic.pcap

Generate five or six prompts, then stop the capture. Extract the Server Name Indication (SNI) from the TLS handshakes:

tshark -r ai-traffic.pcap -Y "tls.handshake.extensions_server_name" \
  -T fields -e tls.handshake.extensions_server_name | sort | uniq -c

SNI is the hostname the client asks for during the handshake. It's the ground truth of where your traffic is addressed.

Step 5: Compare against the source code

This is the step that makes open source valuable. Clone the client repository and grep for every URL it references:

git clone https://github.com/your-tool/repo.git
grep -rEo "https?://[a-zA-Z0-9.-]+" src/ | sort -u

Now you have two lists. The source-declared endpoints and the runtime-observed endpoints. Diff them.

comm -3 <(sort observed.txt) <(sort source.txt)

Any hostname that appears in the traffic but not in the source deserves a closer look. Any hostname in the source that never appears in traffic is either unused or lazy-loaded.

What I look for in the results

The checklist I use, which you can copy:

• [ ] Every observed hostname is documented in the project's README or source.
• [ ] No hostname belongs to a third-party analytics or advertising domain.
• [ ] TLS certificates are valid and match their hostnames.
• [ ] The diff between observed and source-declared endpoints is empty.
• [ ] The egress firewall allows only the documented hostnames.

When I ran this on our setup, the API endpoint behaved. The surprise was in the diff — a telemetry domain that appeared in the traffic but not in the obvious config files. It was in the source, but buried in a dependency. That's the kind of finding that never shows up in a vendor's compliance questionnaire.

What this audit does not tell you

Be honest about the limits. A packet capture on your side ends at the server's front door. It cannot tell you:

• What the server logs after TLS termination.
• How long prompts are retained.
• Whether a human reviews them.
• Whether the free tier is subsidized by training on your prompts.

For those questions, you need the project's terms and a legal review, not tcpdump. The trace answers "where does this go?" It does not answer "what happens there?"

Who should skip this approach

• Teams without packet capture rights. If you can't get sudo on a dev machine, use a logging HTTP proxy like mitmproxy or a corporate egress log. Same question, different tool.
• Regulated environments. If your policy forbids external egress for code, the audit result is predetermined. Self-host and skip the trace.
• Teams that can't read the client source. Then the runtime trace is all you have — run it, and treat any undocumented hostname as a blocker.

The takeaway

Free hosted AI is a capacity decision, but it's also a routing decision. The price is $0. The path is whatever the packets say it is. Those two things are easy to confuse, and the confusion usually surfaces at the worst time — during a security review, or after a compliance incident.

So here's my question: when was the last time you traced where your prompts actually go? Not where the docs say they go. Where the packets say they go. If you run this trace this week — against MonkeyCode's free server or any other tool — I'd like to know what your SNI list showed. The first surprise is usually not the main API endpoint. It's the third domain you didn't expect.