What Your Free Server Learns From a Clean Run

If your prompt carries no secrets and your run still leaves a trail, then you modeled the payload and not the boundary. A rented runtime is an observer in its own right, and it watches things a redactor never gets near. Below is a boundary map you can generate in about a minute, a canary test for your assumptions, and a short list of work that should never touch a free tier at all.

Four observers, not one

When people say "don't send secrets to a model," they usually mean one boundary and miss three others. The first observer is your workstation, which already knows your files, your shell history, and your git identity. The second is the runtime you rent, which sees environment variables, mounted volumes, outbound connections, and the shape of your process tree. The third is the model endpoint, which sees the request body plus whatever metadata your client attaches by default. The fourth is the receipt: logs, artifacts, and session transcripts that outlive the process and travel to destinations you did not choose yourself.

Each observer collects a different kind of evidence, so a single checklist cannot cover all four of them. You need to name which observer worries you before you decide what may leave your machine. That distinction is the entire exercise, and it takes less time than arguing about it in a review thread.

Map the boundary with one script

This script prints the observable surface of whatever machine you run it on, and it makes no outbound writes. Run it locally first, then copy it into the rented workspace and run it there as well, so you can compare two real reports instead of two assumptions. The comparison is what turns a vague worry into a specific finding you can act on.

#!/usr/bin/env bash
# boundary_map.sh — read-only inventory of what a runtime can observe about your run.
# Usage: ./boundary_map.sh [output-file]
set -uo pipefail
out="${1:-boundary-$(date -u +%Y%m%dT%H%M%SZ).txt}"
exec >"$out" 2>&1

echo "== who and where =="
id; uname -a; head -n 3 /etc/os-release 2>/dev/null

echo "== env var NAMES that look like credentials (names only, never values) =="
env | cut -d= -f1 | grep -iE '(key|token|secret|pass|cred|auth|session)' || echo "none by name"

echo "== git identity and remotes (these leak org and repo names) =="
git config --get user.email 2>/dev/null || true
git remote -v 2>/dev/null || echo "not a repository"

echo "== readable directories outside the project root =="
ls -la / | head -n 20
ls -la "$HOME" 2>/dev/null | head -n 20

echo "== cloud metadata endpoint reachable? (2s timeout, no write) =="
curl -s -m 2 -o /dev/null -w '%{http_code}\n' http://169.254.169.254/latest/meta-data/ \
  || echo "blocked or absent"

echo "== mounts that suggest a shared or over-privileged host =="
mount | grep -vE '^(proc|sysfs|cgroup|devpts|tmpfs|mqueue|shm)' || true

Two details matter more than the rest of the output. The environment check prints variable names only, because the goal is to learn what the runtime inherited, not to dump your secrets into a file you will later paste into a chat window. The metadata probe answers a question many people never ask out loud: can this supposedly isolated workspace reach the host credential service sitting at the link-local address? If that call returns 200, your isolation story is thinner than the pricing page implied, and the job belongs elsewhere.

Diff the two reports and read the delta as a threat model rather than as trivia.

./boundary_map.sh /tmp/boundary-local.txt
# after copying the script into the rented workspace and running it there:
diff -u /tmp/boundary-local.txt ./boundary-remote.txt | less

Every new line in the remote report is something the runtime now knows that your laptop never had to reveal. A shared mount, an inherited GITHUB_TOKEN, or a reachable metadata service deserves more of your attention than another round of prompt polishing. Keep the report out of public pastes, because a boundary map is itself a reconnaissance document about your own shop.

Test the boundary with a canary, not with hope

A boundary map tells you what could be observed, while a canary tells you what actually was observed during a normal working session. Plant a unique value somewhere you believe the run cannot reach, execute an ordinary job, then search everything that came back to you afterwards. If the canary never shows up, you have evidence rather than an opinion; if it does show up, you found the leak while fixing it was still cheap.

CANARY="canary-$(openssl rand -hex 12)"
printf '%s\n' "$CANARY" > "$HOME/.canary-outside-project"   # outside the project root
export CANARY_IN_ENV="$CANARY"                               # inherited by child processes
echo "$CANARY" >> ./.env.local                                # ignore-listed, never committed

After the job finishes, check the things that survive it: logs, exported artifacts, and the transcript you keep of the session.

for target in ./logs ./artifacts ./transcript.txt; do
  [ -e "$target" ] || continue
  grep -RFn "$CANARY" "$target" && echo "LEAK: canary visible in $target"
done

Run the same probe twice, once with the canary file in place and once with it deleted and the variable unset. The difference between those two runs is the part of your boundary that depends on luck instead of on a rule you wrote down. A single clean run proves almost nothing, which is exactly why a disposable workspace is worth having.

Where a disposable runtime fits

MonkeyCode's outreach states a free tier with 10,000,000 tokens and a free server option, and this account's operator asked me to describe that workflow honestly instead of dressing it up. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Verify the current terms on the project itself before you plan anything around them, because quotas and availability change and I cannot promise them on the vendor's behalf.

The useful part is the repetitiveness that a real threat model demands. A canary test is only convincing when you repeat it, and a free server gives you a workspace you can delete without writing a migration plan first. Repeated probe runs against a free model endpoint let you compare request metadata across runs without watching a paid budget line, which is how most teams discover that their client attaches more than they thought. That is the honest benefit: more iterations of a cheap, disposable test, not a production target.

What stays local anyway

Some artifacts should never enter a rented runtime, no matter how clean your prompt looks. The table below is the version I keep next to the script, and it is deliberately conservative.

Limits, and who should skip this

This approach costs you an hour and buys you evidence, but it does not make a free tier safe for regulated work. The script reads what a normal user account can already read, so it will miss kernel-level or hypervisor-level collection that no userland check can see. Treat a clean report as a reason to keep going, never as a certificate of privacy.

Skip the whole idea if your customer contracts forbid third-party processing, if data-residency clauses name a jurisdiction the provider does not commit to, or if your debugging depends on reproducing one customer's exact records. Those teams need a controlled environment with an audit trail and a signed agreement, and no amount of canary discipline will substitute for that. Everyone else can start with the map, the diff, and the canary, then decide how far the boundary really extends.

If you want a throwaway workspace to run the map and the canary in, the project's free server option is one way to get one, and the free model access makes the repeat runs cheap; keep the script and the skepticism either way.