Every time you paste a snippet into an AI coding tool, you are making a network request. The safest habit you can build is to run a small boundary check on that snippet before it goes. Most leaks in AI-assisted development are not exotic model exploits but ordinary boundary mistakes that follow a boring pattern. An environment file resolves into context, a recent diff still carries a rotated credential, or a copy-paste drags a customer record into the prompt.
The Trust Boundary
The mental model starts with one question: where is your trust boundary? Your editor and your local agent sit on one side, and the model server sits on the other, so everything in your prompt is what you just handed across that line. Free model tiers and free server options change the economics but not the geometry of that boundary. A request still leaves your machine, and it lands on shared infrastructure that can be logged, retained, or inspected like any remote API call. The practical conclusion is to treat the remote model as an untrusted third party with a friendly interface, and to let that assumption drive what you include.
Think of the boundary in three layers, starting with the repository where secrets accumulate silently in diffs, comments, and test fixtures. The configuration layer is next, and this is where many setups are accidentally wide open because the assistant defaults to whole-repo visibility. The request layer is the payload that actually leaves, and it contains not just your prompt but tool results and any file contents the agent decided to attach. When a current DEV discussion asks what developers do while AI codes, the uncomfortable answer is that many of us audit this request layer after the fact instead of before it.
The Pre-Flight Check
Here is the pre-flight check you can keep in your dotfiles, a small Python script that answers three questions about any candidate set of files. It reports whether sensitive-named files are present, whether live credential patterns appear in their contents, and whether anything would be visible to an agent that respects normal ignore rules. It is deliberately readable so you can extend it before you trust it.
#!/usr/bin/env python3
# boundary_check.py - print what an AI coding tool is about to read.
import re
import subprocess
import sys
from pathlib import Path
SENSITIVE_NAMES = re.compile(
r'(\\.env(\\..*)?$|\\.pem$|\\.key$|id_rsa|credentials?|secret|token)', re.I
)
SECRET_PATTERNS = [
re.compile(r'\\bAKIA[0-9A-Z]{16}\\b'),
re.compile(r'\\bgh[pousr]_[A-Za-z0-9]{36,255}\\b'),
re.compile(r'\\bsk-[A-Za-z0-9]{20,}\\b'),
re.compile(r'-----BEGIN [A-Z ]*PRIVATE KEY-----'),
re.compile(r'(?i)\\b(password|passwd|api[_-]?key)\\s*[:=]\\s*\\S+'),
]
def expand(paths):
files = []
for p in paths:
path = Path(p)
if path.is_dir():
files.extend(str(f) for f in path.rglob('*') if f.is_file())
else:
files.append(str(path))
return files
def main():
args = sys.argv[1:]
if not args:
print('usage: boundary_check.py <files-or-dirs> [--git]')
sys.exit(2)
if '--git' in args:
args.remove('--git')
tracked = subprocess.check_output(['git', 'ls-files'], text=True).split()
files = sorted(set(expand(args)) | set(tracked))
else:
files = expand(args)
flagged = []
for f in files:
if SENSITIVE_NAMES.search(f):
flagged.append((f, 'sensitive filename'))
try:
text = Path(f).read_text(errors='ignore')
except OSError:
continue
for pattern in SECRET_PATTERNS:
if pattern.search(text):
flagged.append((f, pattern.pattern[:28]))
break
if not flagged:
print('BOUNDARY CLEAR: nothing obviously sensitive in the candidate set.')
return
print('BOUNDARY FLAGGED: review these before anything leaves the machine:')
for f, reason in flagged:
print(' %s (%s)' % (f, reason))
sys.exit(1)
if __name__ == '__main__':
main()
The usage is deliberately boring, and boring is what you want from a safety tool. The first form builds the candidate set from everything git tracks, which is a good default because your assistant will usually read tracked files. The second form matches a manual paste workflow, where you list exactly the files you intend to show, and the script complains if any of them look secret-adjacent.
python3 boundary_check.py . --git
python3 boundary_check.py src/ app.py config/settings.py
In practice the output either says BOUNDARY CLEAR, or it names the file and the pattern class that triggered, which is enough to stop and rotate a credential long before it becomes a prompt. A useful routine is to run this check before every session that involves remote model access, and to treat its output as the scope of what the assistant may read. When you point the open-source assistant MonkeyCode at a repository, the same rule applies because its free model access still sends your context to a shared model endpoint, and its free server option is another network boundary you should treat as remote. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The project's published plan currently includes a ten-million-token free allowance and a free server, and those numbers are exactly the kind of time-sensitive detail you should verify on the project page before repeating them anywhere. Whatever the current totals are, the boundary check itself does not change: only the files that survive the pre-flight ever enter the prompt.
A Realistic Refactor
Consider a realistic case where you want a refactor of your authentication module, and the assistant asks for the full repository so it can understand the call sites. A full-repo grant would hand over deployment playbooks, seed data with synthetic users, and any secrets that a previous sprint left in comments, and none of those have anything to do with the refactor. Running the pre-flight, then allowing only auth/, the tests that touch it, and the dependency manifest, keeps the request small and the boundary honest. If the refactor produces a confusing result, the diagnosis becomes tractable because you know exactly what the model saw.
Limitations
Now the honest limits, because a regex script is a tripwire and not a secret manager. It catches the patterns you gave it and silently misses everything else, so teams with real compliance obligations should pair it with gitleaks or trufflehog and verify the provider's retention policy directly. The approach is also wrong for workloads under strict data-residency rules, because no pre-flight check can make a remote free tier compliant with obligations you have not examined yourself. And if your repository history already contains a credential, deleting the file locally is not enough, because the old value is compromised forever and must be rotated first.
Who Should Skip This
Skip this workflow if your threat model requires guarantees instead of warnings, if your team cannot tolerate even metadata about repository structure leaving the building, or if you need proof that a tool read only the files you listed rather than a promise that it tried to. For regulated pipelines and air-gapped code, the correct answer remains a local model and a locked-down egress policy, not a friendly free tier.
The Takeaway
The durable conclusion is that free APIs and free servers are not a reason to relax your trust boundary but a reason to check it more often, because the convenience is higher while the cost of a mistake stays the same. Build the pre-flight into your routine, run it before every session, and the assistant becomes a faster version of you instead of an extra place where your secrets go to be logged. If you want to test these rules against a real remote setup, the MonkeyCode project page lists the current free allowance and server details, and reading that page is itself a small exercise in not trusting outdated numbers.
Top comments (0)