DEV Community: jaryn

Your Free Model Endpoint Keeps Logs — Build the Relay That Decides What They Say

jaryn — Tue, 20 Oct 2026 09:18:04 +0000

A stack trace leaves someone's editor. It carries a database URL with a password, because connection strings love stack traces. It hits a small relay on a free server, gets forwarded to a free model endpoint, and comes back as a fixed bug.

Fine outcome. Now grep the relay's own log.

The plaintext is sitting there — in the request body someone logged "for debugging", and in the response someone logged "for observability". The provider's copy is outside your control. Your copy is not. That asymmetry is the whole article.

The failing sequence, in five lines

The agent reads a file containing DATABASE_URL=postgres://app:hunter2@db.internal:5432/app.
It posts the file to the relay.
The relay writes the request body to disk.
The relay forwards it to the model endpoint.
Six weeks later, a grep finds it.

Which line would survive a review? Line 3 — and only line 3. Lines 1 and 4 are policy questions you can't unilaterally answer. Line 3 is a code change.

Draw the boundary map before you write the code

You can't redact what you haven't located. So name the boundaries first.

#	Boundary	What crosses	Who can read it later
B1	workspace → relay	full prompt, unsanitized	your shell history, editor backups, agent transcripts
B2	relay → model endpoint	whatever you choose to forward	the provider's retention policy, your TLS terminator
B3	relay → its own log/disk	whatever you chose to log	anyone with disk access — on an ephemeral free host, assume "anyone"
B4	model response → workspace	model output	you, plus every tool that persists it

B3 is the only boundary where you own both the writer and the reader. That's where the artifact goes.

One design rule falls out of this: the relay must be one-way. No rehydration map, no "restore original values before forwarding". A bidirectional relay is a second copy of the secret, on the host you trust least.

Classify your data, then pick the action

Three actions, not two. "Send or don't send" is a false binary that pushes people back to pasting the whole repo.

Data class	Action	Why
Private keys, cloud access keys, bearer tokens, connection strings with passwords	Block	Rotation is the only real remedy; the model never needs the literal value
Customer email, internal hostnames, private IPs, ticket IDs	Placeholder	The model usually needs the shape, not the value
Source code with no matching pattern, public stack traces, public docs	Forward raw	Cost of redaction outweighs the marginal risk
Regulated data (health, cardholder, government IDs)	Stop	Redaction shrinks blast radius; it does not create a lawful basis

Write that table down before you deploy. Two columns in a file beats a paragraph in a wiki nobody opens.

Build the relay: 60 lines, standard library only

No dependencies, no model SDK, no framework. The relay does not call the model itself — it returns a decision, and your agent only forwards what comes back marked forward.

#!/usr/bin/env python3
"""relay.py - one-way redaction relay. Python 3.8+, standard library only."""
import argparse, hashlib, json, re
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

RULES = [
    ("private_key", re.compile(r"-----BEGIN [A-Z ]*PRIVATE KEY-----[\s\S]+?-----END [A-Z ]*PRIVATE KEY-----")),
    ("cloud_key",   re.compile(r"\b(?:AKIA|ASIA)[0-9A-Z]{16}\b")),
    ("bearer",      re.compile(r"(?i)\bBearer\s+[A-Za-z0-9._\-]{20,}")),
    ("conn_string", re.compile(r"\b[a-z][a-z0-9+]*://[^\s:@/]+:[^\s@/]+@[^\s]+")),
    ("email",       re.compile(r"\b[\w.+-]+@[\w-]+\.[\w.]+\b")),
    ("private_ip",  re.compile(r"\b(?:10\.\d{1,3}|127\.\d{1,3}|192\.168)\.\d{1,3}\.\d{1,3}\b")),
]
BLOCK = {"private_key", "cloud_key", "bearer", "conn_string"}
MAX_BODY = 64 * 1024

def redact(text):
    counts, out = {}, text
    for name, rx in RULES:
        def rep(m, _n=name):
            counts[_n] = counts.get(_n, 0) + 1
            return f"<<{_n}:{counts[_n]}>>"
        out = rx.sub(rep, out)
    return out, counts

def decide(text):
    redacted, counts = redact(text)
    blocking = sorted(set(counts) & BLOCK)
    return {
        "action": "blocked" if blocking else "forward",
        "blocking": blocking,
        "classes": counts,
        "prompt": redacted,
        "body_sha256": hashlib.sha256(text.encode()).hexdigest(),
        "bytes_in": len(text.encode()),
    }

class Relay(BaseHTTPRequestHandler):
    protocol_version = "HTTP/1.1"

    def reply(self, code, obj):
        body = json.dumps(obj).encode()
        self.send_response(code)
        self.send_header("content-type", "application/json")
        self.send_header("content-length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

    def do_POST(self):
        if self.path != "/relay":
            return self.reply(404, {"error": "not found"})
        n = int(self.headers.get("content-length", 0))
        if n > MAX_BODY:
            return self.reply(413, {"error": "too large"})
        try:
            text = json.loads(self.rfile.read(n) or b"{}")["prompt"]
            assert isinstance(text, str)
        except Exception:
            return self.reply(400, {"error": "bad payload"})
        d = decide(text)
        # audit line: no body, no redacted body, no match values - hashes only
        self.log_message("%s", json.dumps(
            {k: d[k] for k in ("action", "classes", "blocking", "body_sha256", "bytes_in")},
            sort_keys=True))
        if d["action"] == "blocked":
            return self.reply(422, {"action": "blocked", "blocking": d["blocking"], "classes": d["classes"]})
        return self.reply(200, {"action": "forward", "prompt": d["prompt"],
                                "classes": d["classes"], "body_sha256": d["body_sha256"]})

if __name__ == "__main__":
    ap = argparse.ArgumentParser()
    ap.add_argument("--bind", default="127.0.0.1")
    ap.add_argument("--port", type=int, default=8088)
    a = ap.parse_args()
    ThreadingHTTPServer((a.bind, a.port), Relay).serve_forever()

Look at what never gets written to disk: the original body, the matched substring, the placeholder count. Only a class name, a count, and a SHA-256 of the input. If the log leaks, it leaks a fingerprint — not a credential.

Fixtures: prove it blocks, and prove it doesn't

A relay that blocks everything passes every "did it block?" test and is useless. You need negative fixtures too — inputs that must come back 200 untouched.

#!/usr/bin/env bash
# fixtures.sh - run against a relay on 127.0.0.1:8088
set -u
RELAY=http://127.0.0.1:8088/relay
run() {
  local name=$1 want=$2 payload=$3 got
  got=$(curl -s -o /tmp/relay.out -w '%{http_code}' \
        -H 'content-type: application/json' -d "$payload" "$RELAY")
  printf '%-16s want=%s got=%s  %s\n' "$name" "$want" "$got" "$(head -c 150 /tmp/relay.out)"
}

run negative-01  200 '{"prompt":"path=/srv/app/.env host=example.com docs=https://203.0.113.10/help"}'
run blocked-aws  422 '{"prompt":"key=AKIAIOSFODNN7EXAMPLE"}'
run blocked-conn 422 '{"prompt":"DATABASE_URL=postgres://app:hunter2@db.internal:5432/app"}'
run redact-email 200 '{"prompt":"customer jane.doe@example.com reports 500 on /checkout"}'
run oversize     413 "$(printf '{"prompt":"%s"}' "$(head -c 70000 /dev/zero | tr '\0' 'a')")"

Expected evidence, line by line — this is the part people skip, and then they can't tell a working relay from a silent one:

Fixture	Want	Evidence you should see
`negative-01`	200	`"classes": {}` and the prompt echoed unchanged
`blocked-aws`	422	`"blocking": ["cloud_key"]`, no prompt echoed back
`blocked-conn`	422	`"blocking": ["conn_string"]`
`redact-email`	200	`jane.doe@example.com` replaced by `<<email:1>>`
`oversize`	413	`{"error": "too large"}` and no log line with body content

AKIAIOSFODNN7EXAMPLE is AWS's own documentation placeholder — deliberately shaped like a key, not a live one. Never fixture with a real credential; a fixture file is a credential file with worse permissions.

Standing it up on a free server

Here's where a free server option earns its place: the relay needs compute and zero secrets. That's the ideal tenant for a host whose lifecycle you don't control.

MonkeyCode currently offers free model access and a free server option — the operator advertises a token allowance (10M tokens at the time of writing) and states the free tier is available to try. Verify the current numbers on the site before you plan around them, because free-tier terms are the least stable component in this design.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Numbered steps:

Give the host nothing to steal. No env vars, no .env, no SSH keys beyond the one you need. The relay has no credentials by construction — keep it that way.
Bind loopback only. umask 077 then python3 relay.py --bind 127.0.0.1 --port 8088 2>> relay.log &. 0.0.0.0 on a host you don't own is a port scan waiting to happen.
Reach it over a tunnel, not a public port: ssh -N -L 8088:127.0.0.1:8088 you@host and point the agent at http://127.0.0.1:8088/relay.
Run the fixtures twice — once on the host, once through the tunnel. Identical output, or you have two relays and only one of them is yours.
Make the relay unskippable. An agent that can reach the model endpoint directly will eventually do so. Default-deny egress so the only reachable destination is the relay; otherwise you built a suggestion, not a boundary.
Treat the log as a cache, not a record. No body content, hash lines only, rotate or truncate freely. If you need incident review, ship the hash lines off-host — not the bodies.

Prevent, detect, recover

Layer	Control	Fails how
Prevent	Relay returns `blocked` for credential classes	Misses secrets that match no pattern
Detect	Hash-only log line per request; diff `classes` over time	Can't tell you what leaked, only that something matched
Recover	Rotate on any `blocked` event that also shows a provider response	Rotation after the fact can't undo an already-forwarded copy

That third row is the honest one. If a blocked fixture ever appears alongside a 200 response from a model in the same minute, assume the request got out through a second path and rotate. Don't debate it.

What this does not do

Regex is not a classifier. A UUID-shaped API token, a base64 blob, a customer name in prose — none of these match a pattern, and no amount of [A-Za-z0-9]{32,} fixes it without burying you in false positives. The relay raises the cost of an accident. It does not make a free endpoint safe for regulated data.

It's also one-way by design, so it breaks any task that genuinely needs the literal value — "why does this exact token fail to parse?" Use a synthetic fixture with the same shape instead of the real value. And it says nothing about provider retention; that boundary is theirs.

Who should not use this: teams that need contractual data-processing terms, a reproducible SLA, or an audit trail admissible in a compliance review. A redaction layer in front of a free tier is an engineering control against accidents, not a compliance posture. If losing a credential for an hour would page three people, fix rotation speed before you optimize the regex.

Start with the negative fixture, not your real repository. A relay that hasn't been proven to pass clean code through is just a firewall with good marketing.

And the question I'd leave on the table: which of these rules belongs in CI, and which belongs in the network layer? My answer — the fixtures belong in CI (they're fast, deterministic, and catch every rule regression), and the egress default-deny belongs in the network (it's the only layer an agent can't argue with). The relay is the thing in the middle, and the middle is where you keep the log you can afford to lose.

Your Leaked Prompt Secret Has a Rotation Order — Compute It Before You Click Rotate

jaryn — Mon, 19 Oct 2026 07:51:52 +0000

It is 02:14. A CI job fails with a 401, a developer pastes the last sixty lines of the job log into a model chat to ask why, and the log happens to contain the runner registration token leaked by an env dump. That is the leak. Everything after it is process.

At 02:40 the on-call engineer revokes the runner token. Correct instinct, wrong scope. At 09:00 a runner registers from a host nobody recognises — not because revocation failed, but because the CI personal access token that mints runner tokens was never touched. The attacker never needed the leaked value. They needed the parent. (Reconstructed tabletop sequence, not a single reported incident.)

So here is the question I keep asking platform teams: if a secret lands in a prompt at 02:14, what does your runbook do at 02:41 — and in what order?

Most runbooks I have read answer "rotate everything" and stop there. Order is the part that decides whether containment takes four minutes or four hours of re-leaking.

1. Map where the second copy lives

A prompt is a log line with an unknown retention window. Once you accept that, the interesting question stops being "did we leak a secret?" and becomes "how many copies exist now, and which of them can mint more?"

For a hosted workspace — including a free server option — the boundary map looks like this:

Boundary	Who can read the plaintext	Consequence for the runbook
Browser to model endpoint	you, plus a retention policy you cannot audit from here	every prompt is a log line; assume it outlives the tab
Workspace container	you, and whoever operates the platform	no long-lived credentials belong in it
Workspace filesystem and shell history	anyone who can snapshot it	`~/.aws/credentials` is a support ticket waiting to happen
Tool-call transcripts	your own observability stack	your logging pipeline is now a second copy
Repo and CI	your org	also the place where secrets get re-minted

Notice the last row. The minting capability usually lives on the other side of the boundary from the leak, which is exactly why rotating the leaked leaf feels like it worked.

2. Write the graph before you write the runbook

I keep the inventory as a CSV edge list, because it diffs cleanly in a PR and survives a wiki migration. Edge means "the left side can mint or replace the right side."

# minter,mintee
ci_github_pat,repo_deploy_key
ci_github_pat,ci_runner_reg_token
ci_runner_reg_token,runner_ephemeral_token

Three edges are enough to catch the treadmill. Add one line every time you add a minting path: token-to-token, token-to-key, key-to-certificate, org-admin-to-anything.

3. Compute containment order, not just a rotation list

This is the whole artifact. Standard library only, no dependencies — I ran it against the graph above and got the output shown below.

#!/usr/bin/env python3
"""rotate_order.py - containment and restore order for a leaked credential.

Usage: python3 rotate_order.py edges.csv ci_runner_reg_token
"""
import csv
import sys
from collections import defaultdict


def load(path):
    children, parents = defaultdict(list), defaultdict(list)
    nodes = set()
    with open(path, newline='') as f:
        rows = (r for r in csv.reader(f) if r and not r[0].startswith('#'))
        for row in rows:
            parent, child = row[0].strip(), row[1].strip()
            children[parent].append(child)
            parents[child].append(parent)
            nodes.update((parent, child))
    return nodes, children, parents


def reach(start, graph):
    seen, stack = set(), [start]
    while stack:
        node = stack.pop()
        for nxt in graph.get(node, []):
            if nxt not in seen:
                seen.add(nxt)
                stack.append(nxt)
    return seen


def topo(subset, children):
    indeg = {n: 0 for n in subset}
    for n in subset:
        for c in children.get(n, []):
            if c in subset:
                indeg[c] += 1
    ready = sorted(n for n, d in indeg.items() if d == 0)
    order = []
    while ready:
        n = ready.pop(0)
        order.append(n)
        for c in sorted(children.get(n, [])):
            if c in subset:
                indeg[c] -= 1
                if indeg[c] == 0:
                    ready.append(c)
        ready.sort()
    if len(order) != len(subset):
        stuck = ', '.join(sorted(subset - set(order)))
        raise SystemExit('cycle among: ' + stuck + ' - revoke the whole cycle by hand')
    return order


def main():
    path, leaked = sys.argv[1], sys.argv[2]
    nodes, children, parents = load(path)
    if leaked not in nodes:
        raise SystemExit(leaked + ' is not in the graph')
    down = reach(leaked, children)   # what the leak can mint
    up = reach(leaked, parents)      # what can re-mint the leak
    scope = up | down | {leaked}
    contain = topo(scope, children)
    print('guard :', ', '.join(sorted(up)) or 'none')
    print('contain:', ' -> '.join(contain))
    print('restore:', ' -> '.join(reversed(contain)))


if __name__ == '__main__':
    main()

Running it:

$ python3 rotate_order.py edges.csv ci_runner_reg_token
guard : ci_github_pat
contain: ci_github_pat -> ci_runner_reg_token -> runner_ephemeral_token
restore: runner_ephemeral_token -> ci_runner_reg_token -> ci_github_pat

Read that output carefully, because it says something counterintuitive. The first credential to revoke is the one that was not leaked. Kill the minter, then the leaf, then the leaf's leaf. Restore in the opposite direction so dependent jobs come back before the parent starts minting replacements.

If you rotate leaves first, you get the treadmill: revoke, re-mint, revoke, re-mint, and a very long night.

4. Handle the cycle honestly

The script hard-fails on cycles, and cycles are real — an org-admin token with permission to issue tokens can, in some configurations, mint a sibling of itself. When that happens, the honest answer is: you cannot compute order, so revoke the entire cycle manually, accept the outage, and then remove the minting loop so the next incident is computable. A graph that lies is worse than no graph.

5. Redact shapes, keep diagnostics

"Don't send secrets to a model" is advice, not a control. The control is a redactor that preserves enough shape for the model to help you.

# redact.py
import re

SHAPES = [
    ('aws_access_key_id', re.compile(r'\b(?:AKIA|ASIA)[0-9A-Z]{16}\b')),
    ('github_token', re.compile(r'\bgh[pousr]_[A-Za-z0-9]{36,255}\b')),
    ('private_key', re.compile(r'-----BEGIN [A-Z ]*PRIVATE KEY-----')),
    ('bearer', re.compile(r'(?i)\bauthorization:\s*bearer\s+[A-Za-z0-9._\-]{20,}')),
]


def classify(text):
    return sorted({name for name, rx in SHAPES if rx.search(text)})


def redact(text):
    for name, rx in SHAPES:
        text = rx.sub('[REDACTED:' + name + ']', text)
    return text

The negative fixtures matter more than the positive ones. A redactor that eats git SHAs destroys debugging value and gets disabled within a week.

# test_redact.py
import pytest
from redact import classify, redact

POSITIVE = [
    'AKIA' + 'Q' * 16,
    'ghp_' + 'a1B2' * 9,
    '-----BEGIN OPENSSH PRIVATE KEY-----',
    'Authorization: Bearer abcdefghijklmnopqrstuvwx1234',
]

NEGATIVE = [
    '9f2c1e7a4b8d3c5e6f708192a3b4c5d6e7f80912',   # 40-hex git SHA
    'a3b1f2c4-9d8e-4f10-8a2b-1c2d3e4f5a6b',       # UUID
    'sha256:6b3f9c1d2e4a5b6c7d8e9f0a1b2c3d4e',     # digest label
]


@pytest.mark.parametrize('sample', POSITIVE)
def test_positive_fixtures_are_caught(sample):
    assert classify(sample), sample
    assert 'REDACTED' in redact(sample)


@pytest.mark.parametrize('sample', NEGATIVE)
def test_negative_fixtures_stay_readable(sample):
    assert classify(sample) == [], sample

One tradeoff to state out loud: keeping a last4 for correlation is defensible for a 40-character high-entropy token and indefensible for low-entropy strings like internal hostnames. Decide per shape, not per policy paragraph.

6. Prove the revocation, don't assume it

The step everyone skips. These are command templates — I have not executed them for this article, and the expected strings vary by provider version and plan.

Credential	Expected failure evidence	Template
Cloud access key	`InvalidClientTokenId`	`AWS_ACCESS_KEY_ID=$OLD AWS_SECRET_ACCESS_KEY=$OLD_SECRET aws sts get-caller-identity`
GitHub PAT	`401 Bad credentials`	`curl -s -o /dev/null -w '%{http_code}' -H "Authorization: Bearer $OLD" https://api.github.com/user`
Deploy key	`Permission denied (publickey)`	`GIT_SSH_COMMAND='ssh -i old_key -o IdentitiesOnly=yes' git ls-remote git@github.com:org/repo.git`
Runner registration token	`403` on re-register	re-run the registration call with the old token

No evidence line, no closure. "I rotated it" is a claim; a 401 is a record.

7. Rotate now versus watch

Not every leak deserves an incident. Here is the table I actually use.

What you have evidence for	Action	Why
A shape matched in text you sent to a model endpoint	Rotate now, containment order	The copy may be retained outside your control
A secret sitting in a private workspace file, no egress	Move to runtime injection, rotate at next window	No evidence it crossed a boundary yet
A full private key pasted anywhere	Rotate now, then audit for derived certificates	Key material is not scope-limited
An internal hostname or topology detail	Do not rotate; classify as topology exposure	Rotation cannot fix architecture knowledge
A customer identifier	Route to your privacy process, not the credential runbook	Different remediation path entirely

The middle two rows are where teams burn goodwill: rotating everything on every signal trains people to ignore the alert.

8. What free access changes, and what it does not

Two availability claims are relevant here, and I am treating both as operator-supplied: MonkeyCode offers free model access and a free server option. Check the current offer terms yourself, since quotas and terms change faster than articles do.

Neither of those is a security control. They do change your threat model in one specific way: a free hosted workspace sits outside your network boundary, so your egress rules, disk encryption, and log pipeline no longer apply to the copy running there. That leads to three rules I would apply before pasting anything into it:

No long-lived credentials inside the workspace — inject short-lived, scoped tokens at runtime instead.
Assume the workspace filesystem and transcripts outlive your session, and export the transcript to a store you can scrub.
Since trying things costs nothing, there is no budget excuse for skipping redaction. Run the redactor first, then paste.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The useful part for me is the drill, not the pricing. Free access means a small team can rehearse containment end to end before it is real.

A twenty-minute drill you can run this week

Create edges.csv with three minting paths you know are true.
Pick a leaf credential and run rotate_order.py against it. If it prints a guard, you just found the hole in your runbook.
Add the test_redact.py negatives to CI. Four of them are enough to start.
Paste one real failing log through redact() and confirm the model can still answer the question.
Write the evidence line you will screenshot during an incident, per credential type.
Pin the script and the graph in the repo next to the runbook, so the runbook can be regenerated rather than remembered.

Limitations and who should skip this

Fewer than roughly eight credentials? Skip the graph. Rotate all of them and go to bed. The graph earns its keep at scale and under partial-permission models.
No inventory? The script only knows edges you typed. A stale graph is false confidence; grep your CI config for credential creation before you trust the output.
Heavy change-approval processes? The graph becomes the ticket attachment. Run it in dry-run mode, paste the contain order, and let approval happen in parallel with the first revocation.
Regulated environments with per-credential incident paperwork? The tool does not replace your process. It reorders it.

The honest summary: containment is a graph problem wearing a runbook costume, and the leaked secret is almost never the first thing you should revoke.

So which invariant do you put in CI: "no secret shape leaves the runner without a redaction record," or "every mint-capable credential has a documented parent"? I would start with the second — because the first one only fails once, and the second one fails every time somebody clicks rotate in the wrong order. If you want to rehearse the drill without provisioning anything, the free tier is a reasonable place to start.

Before the First Prompt: A Data-Class Gate for Free-Tier Model Trials

jaryn — Sun, 18 Oct 2026 06:48:56 +0000

The first prompt in that trial was supposed to be boring. Just "summarize the failing test." What actually left the laptop was 41 KB of pytest -vv output, and two of those lines contained a database URL with an inline password. Nobody wrote a policy that allowed that. Nobody wrote a policy at all. Someone flipped a flag, pointed an agent at a repo, and the tool did what tools do: it read everything it was allowed to read and sent a summary of it somewhere.

So here's the invariant I now refuse to run a trial without: no byte from a file whose data class exceeds the mode's ceiling may enter a prompt. Not "sensitive files should be avoided." Not "the model is probably fine." An explicit ceiling per mode, a per-file class, and a gate that fails closed on the unknown.

This post builds that gate with two small scripts, four fixtures, and an exit-code contract you can put in CI today.

Two modes, two boundaries (and one you have to verify yourself)

A hosted free model tier and a self-hosted free server are not the same trust boundary, and conflating them is how teams talk themselves into a bad first week.

In the hosted case, the prompt bytes cross out of your machine. Whether they are retained, logged, or used for anything else is a question for the provider's terms, not for your threat model. You can only control what you send.

In the free-server case, the model weights and the prompt both live on a host you were given. That removes the network hop. It does not remove a tenant boundary, a snapshot, a support login, or a billing integration. Before you raise your data ceiling for that mode, answer one question in writing: who else can read that host's disk? If you can't answer it, keep the ceiling where the hosted mode is.

This is where the free tier is genuinely useful rather than merely cheap. MonkeyCode's current signup advertises a free token allowance and a free server option — as of writing, 10 million tokens and a free server, operator-supplied terms you should re-check on the live page before planning around them. What matters for this article is that both boundaries are cheap enough to test instead of argue about. (Disclosure: This article was prepared as part of MonkeyCode's product outreach.)

Step 1 — Write the ceiling down as a file, not a vibe

Policy that lives in a wiki gets skipped at 11 p.m. Policy that lives in a dict gets imported. Start with something you can diff in review:

# policy.py — your decision, not the vendor's
POLICY = {
    # ceiling = highest class allowed into a prompt at all
    "hosted-free-tier":       {"ceiling": "internal",      "hard": ["secret"]},
    "free-server":            {"ceiling": "pii",           "hard": ["secret"]},
    "air-gapped-self-hosted": {"ceiling": "customer-data", "hard": ["secret"]},
}
RANK = {"public": 0, "internal": 1, "pii": 2, "customer-data": 3, "secret": 4, "unknown": 9}

Two design choices are load-bearing. First, unknown outranks everything, because an unclassified binary is not a safe binary. Second, secret is a hard block in every mode — a leaked credential is not a data-classification problem you can solve by picking a friendlier host.

Also note what is not in this file: token counts, model names, or anything you read off a promo page. Promotions change. Your ceiling shouldn't change because a banner did.

Step 2 — Classify the tree, and record a digest per file

The classifier below is deliberately dumb. Regex and path heuristics, no ML, no network calls. You want the gate to be explainable in a review meeting, and you want the failure mode to be a false deny, not a false allow.

#!/usr/bin/env python3
# classify.py — TEMPLATE. Not run against your repo. Pin your own rules.
import argparse, hashlib, json, re, sys
from pathlib import Path

SKIP_DIRS = {".git", "node_modules", "vendor", "dist", "build", ".venv", "__pycache__"}
MAX_BYTES = 512 * 1024
RANK = {"public": 0, "internal": 1, "pii": 2, "customer-data": 3, "secret": 4, "unknown": 9}

PATH_RULES = [
    ("secret",        re.compile(r"(^|/)(\.env(\..*)?|id_(rsa|ed25519)|\.npmrc|\.pypirc|credentials(\.json)?)$")),
    ("customer-data", re.compile(r"(^|/)(dumps?|exports?|snapshots?|prod[-_]?data)/")),
    ("pii",           re.compile(r"(^|/)(fixtures?|seeds?|samples?)/.*\.(csv|json|sql|ndjson)$")),
]

CONTENT_RULES = [
    ("secret", re.compile(r"(?i)\b(api[_-]?key|secret|password|passwd|token)\b\s*[:=]\s*['\"]?[A-Za-z0-9/_\-+]{16,}")),
    ("secret", re.compile(r"(?i)\b(postgres|mysql|mongodb|redis)://[^\s:@]+:[^\s:@]+@")),
    ("pii",    re.compile(r"\b\d{3}-\d{2}-\d{4}\b")),
    # ("pii", re.compile(r"\b[\w.+-]+@[\w-]+\.[\w.]{2,}\b")),  # keep off until calibrated
]

def digest(p):
    h = hashlib.sha256()
    with p.open("rb") as f:
        for chunk in iter(lambda: f.read(65536), b""):
            h.update(chunk)
    return h.hexdigest()

def classify(p, root):
    rel = "/" + p.relative_to(root).as_posix()
    hits = [(cls, "path") for cls, rx in PATH_RULES if rx.search(rel)]
    try:
        if p.stat().st_size > MAX_BYTES:
            return hits, "skipped-too-large"
        text = p.read_text(errors="ignore")
    except OSError:
        return hits, "unknown"
    hits += [(cls, "content") for cls, rx in CONTENT_RULES if rx.search(text)]
    return hits, "text"

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--root", required=True)
    ap.add_argument("--manifest", required=True)
    a = ap.parse_args()
    root = Path(a.root).resolve()
    files, worst, unknown = [], "public", 0
    for p in sorted(root.rglob("*")):
        if not p.is_file() or any(part in SKIP_DIRS for part in p.parts):
            continue
        hits, kind = classify(p, root)
        cls = "unknown" if kind == "unknown" else max(
            (h[0] for h in hits), key=RANK.get, default="public")
        unknown += kind == "unknown"
        worst = cls if RANK[cls] > RANK[worst] else worst
        files.append({"path": p.relative_to(root).as_posix(), "class": cls,
                      "kind": kind, "sha256": digest(p)})
    json.dump({"worst": worst, "unknown": unknown, "files": files},
              open(a.manifest, "w"), indent=2)
    print(f"worst={worst} files={len(files)} unknown={unknown}")
    sys.exit(4 if worst == "secret" else 3 if unknown else 0)

if __name__ == "__main__":
    main()

The digest is the part people skip and later regret. A manifest without hashes tells you a filename was fine yesterday. A manifest with hashes lets you prove that the file the agent actually read is the file you classified.

Step 3 — Gate the manifest per mode

The gate doesn't read your repo. It reads the manifest and answers one question per mode: does this tree fit under this ceiling?

#!/usr/bin/env python3
# gate.py — TEMPLATE. Verdict is per mode; there is no global "safe".
import json, sys
from policy import POLICY, RANK

def decide(manifest, mode):
    pol = POLICY[mode]
    bad = [f for f in manifest["files"]
           if f["class"] in pol["hard"] or RANK[f["class"]] > RANK[pol["ceiling"]]]
    return {"mode": mode, "verdict": "deny" if bad else "allow",
            "blocked": len(bad), "sample": [f["path"] for f in bad[:3]]}

if __name__ == "__main__":
    man = json.load(open(sys.argv[1]))
    for mode in POLICY:
        r = decide(man, mode)
        print(f'{mode:24} {r["verdict"]:5} blocked={r["blocked"]:3} {r["sample"]}')

That's it. Two files, no daemon. The interesting output is not allow — it's the case where hosted says deny and free-server says allow, because that difference is exactly the argument your team needs to have before the session starts.

Step 4 — Build fixtures that must fail

A gate you've only seen pass is a gate you haven't tested. Four fixtures, kept in the repo, deliberately synthetic:

fixtures/deny-secret/app/config.py      # fake DATABASE_URL with inline password
fixtures/deny-pii/fixtures/users.csv    # SSN-shaped rows, no real people
fixtures/allow/app/parser.py
fixtures/allow/README.md

Run the pair and treat the output as an assertion, not as evidence from my machine:

python3 classify.py --root fixtures/deny-secret --manifest /tmp/m.json; echo "exit=$?"
# expect: worst=secret files=2 unknown=0   /   exit=4

python3 classify.py --root fixtures/allow --manifest /tmp/m.json; echo "exit=$?"
# expect: worst=public files=2 unknown=0   /   exit=0

python3 gate.py /tmp/m.json
# expect hosted-free-tier DENY blocked>=1; air-gapped also deny on secret

The exit=4 is the artifact. Wire it into pre-commit and CI, and a credential in a working tree fails the build instead of becoming a training sample.

Step 5 — Decide what actually crosses the line

Prompts are the obvious channel. They are not the only one, and usually not the biggest.

Channel	Hosted free tier	Free server (verify tenancy first)
Prompt text	Crosses out; ceiling applies	Stays on host; tenancy still applies
Tool file reads	Agent may read beyond your prompt	Same, plus host disk access
Tool stdout / stack traces	Frequently contains secrets	Frequently contains secrets
Index or embedding cache	Often a second copy, often forgotten	Same, on someone's disk
Error reports, telemetry	Check the client's defaults	Check the server's defaults

If that table has a row you can't fill in, you're not ready to raise a ceiling.

Step 6 — Close the loop: deny, detect, recover

Layer	Control	Owning team
Prevent	`classify.py` in pre-commit, exit 4 on `secret`	Repo owners
Prevent	`gate.py` at session start, fail closed on `unknown`	Platform / harness
Detect	Manifest hash compared to the files the agent read	Platform
Detect	Canary string in `fixtures/`; alert if it appears in egress logs	Security
Recover	Rotate, then re-run the fixture suite before re-enabling the mode	Security + repo owner

Where this breaks (and who shouldn't use it)

Regex classifiers are dumb, and you should say so out loud. Your first run on a real monorepo will flag hundreds of files, unknown will dominate because of binaries and large generated files, and someone will ask to lower the ceiling to make CI green. That request is the actual test of your process.

It also only covers the working tree. git log -p can resurrect a rotated secret that no current file contains, so run a history scan separately. Submodules are skipped by the walker above unless you recurse deliberately. And nothing here inspects what the agent writes back — a patch or a generated script is outbound code that needs its own review gate.

Don't use this as a compliance control, and don't use it to justify putting regulated data on a free tier of any kind, hosted or self-hosted, without a contract and a named data owner. If you can't enumerate your repositories, fix that before you write the policy — a gate over an unknown tree is theatre.

If you want to run the same fixture set against both modes before buying anything, the free tier is a reasonable place to do it: run deny-secret against hosted and free-server, and confirm both deny. That's one soft pitch and it's also just the cheapest correct next step.

The boundary question I keep coming back to: classification belongs in CI, on every pull request. The ceiling decision belongs in the harness, at session start, owned by whoever is accountable for the data. Do you need both, or can one layer be trusted to enforce the other's invariant — and which one fails quietly if you get it wrong?

Build a Canary Regression Test for Model-Bound Webhook Data

jaryn — Sat, 17 Oct 2026 05:50:25 +0000

The 02:14 ticket

Last month a support engineer opened a ticket that looked like a hundred others: one tenant's webhook deliveries were failing, and she wanted a model to explain why. So she copied the failed delivery record — status code, endpoint, body, and the X-Signature header — into a chat box and asked, "what is wrong here?"

The answer was fine. The paste was not. That header is derived from a per-tenant signing secret, and it now lived in a vendor transcript, a browser cache, and a ticket that three people could read.

Nothing exploded. No failed request, no 500, no alarm. That is the worst kind of incident: a secret that crossed a boundary nobody drew.

So let's draw it — and then prove it with a test.

The boundary is not the network

Most "don't send secrets to models" advice is a vibe. The useful version is a specific question: which fields are allowed past the prompt assembler, and what fails the build when someone widens that list?

Boundary	What crosses	Failure mode	Control
Log store → prompt assembler	Structured event records	Whole-record serialization drags in secrets	Field allowlist projection
Assembler → model endpoint	Rendered prompt	Retention you don't control	HMAC pseudonyms + shape-only values
Model output → ticket	Free text	Regurgitated secret in a readable place	Output scan before write

Note what is not on that list: "tell the model not to repeat secrets." A system prompt is a preference, not an enforcement layer. Enforcement lives in code that runs before the bytes leave your process.

Step 1 — Classify data, not payloads

Start with a table somebody can argue with. Mine, for webhook delivery records:

Class	Example field	Send raw?	Why
Secret	`signature`, `authorization`, `cookie`	Never	Rotating a tenant secret is a customer-visible event
Identifier	`endpoint`, `host`, `bucket`	Never	Names your internal topology and tenant mapping
Personal data	`customer_email`, `phone`	Tokenized	Correlation is useful; identity is not
Free text	`body`, `error`, `stack`	Synthesized	Where the leaks actually hide
Telemetry	`event`, `status_code`, `duration_ms`	Yes	The reason you called a model at all

Argue about the rows now, in review, with names attached. Not at 02:14.

Step 2 — Project with a default-deny allowlist

Denylists lose because they need you to predict every new field. Allowlists lose nothing but convenience, and convenience is exactly what you want to spend.

# payload_policy.py — starting template, not a validated policy
import hashlib, hmac, re

RULES = [
    (r"(?i)^(event|event_id|status|status_code|attempt|duration_ms|timestamp)$", "allow"),
    (r"(?i)(secret|token|password|signature|cookie|authorization|api_?key)",      "drop"),
    (r"(?i)(host|hostname|endpoint|bucket|arn|ip_addr)",                         "drop"),
    (r"(?i)(email|phone|address|full_?name|card)",                               "tokenize"),
    (r"(?i)(body|payload|message|error|stack|trace)",                            "synthesize"),
]
DEFAULT = "drop"

def classify(key: str) -> str:
    for pattern, action in RULES:
        if re.search(pattern, key):
            return action
    return DEFAULT

def shape(value):
    if isinstance(value, str):
        return f"<str:{len(value)}>"
    if isinstance(value, bool) or value is None:
        return value
    if isinstance(value, (int, float)):
        return 0
    return "<obj>"

def project(record: dict, hmac_key: bytes) -> dict:
    out = {}
    for key, value in record.items():
        action = classify(key)
        if action == "drop":
            continue
        if isinstance(value, dict):
            out[key] = project(value, hmac_key)
        elif action == "allow":
            out[key] = value
        elif action == "tokenize":
            digest = hmac.new(hmac_key, str(value).encode(), hashlib.sha256).hexdigest()
            out[key] = "tok_" + digest[:16]
        else:
            out[key] = shape(value)
    return out

Two details matter more than the code. First, the HMAC key lives outside the prompt path, so pseudonyms correlate within a tenant but resist dictionary attack — an unkeyed hash of an email is reversible in seconds. Second, shape() preserves length and type; that leaks a little, and it is the price of the model still being able to say "this body looks truncated."

Step 3 — Synthesize what the model needs to see

Here is the tradeoff people skip: aggressive redaction produces prompts that are safe and useless. If you replace an error string with [REDACTED], the model can tell you nothing about it.

So keep the skeleton. Replace values with typed placeholders, keep key names, keep ordering, keep booleans. A stack trace becomes file=<str:41> line=0 fn=<str:18> — still enough to spot a pattern like "every failure is in the same function," which is usually the actual question behind the ticket.

Step 4 — Two fixtures, not one

A redaction test that only asserts absence will pass when your projection drops everything. You need a negative control too.

# test_payload_policy.py — pytest, no network
from payload_policy import project

KEY = b"test-only-key-not-a-secret"
CANARY = "CANARY-{}-8f3a1c"

def render(record):
    return repr(project(record, KEY))

def sample():
    return {
        "event": "webhook.delivery_failed",
        "status_code": 502,
        "signature": "sha256=" + CANARY.format("signature"),
        "endpoint": CANARY.format("endpoint"),
        "customer_email": CANARY.format("email") + "@example.test",
        "body": '{"order":"' + CANARY.format("body") + '"}',
    }

def test_canaries_never_reach_the_prompt():
    out = render(sample())
    for field in ("signature", "endpoint", "body"):
        assert CANARY.format(field) not in out, field

def test_useful_fields_survive():
    out = render(sample())
    assert "webhook.delivery_failed" in out   # over-redaction guard
    assert "502" in out
    assert "tok_" in out                      # tokenized, not dropped

def test_pseudonyms_correlate_but_do_not_collide():
    a = project({"customer_email": "a@example.test"}, KEY)["customer_email"]
    b = project({"customer_email": "a@example.test"}, KEY)["customer_email"]
    c = project({"customer_email": "b@example.test"}, KEY)["customer_email"]
    assert a == b and a != c

def test_unknown_field_defaults_to_drop():
    out = render({"some_new_field": CANARY.format("mystery")})
    assert "some_new_field" not in out

That last test is the one that keeps working after the refactor. Every new field a service adds lands in drop until somebody writes a rule and a reason.

Step 5 — Run it against a model you are allowed to break

The hard part of this workflow is not the regex, it is measuring whether your projection destroyed the signal. You need a model endpoint and a throwaway environment, and you should never use production records for that measurement.

This is where MonkeyCode's free model access and free server option are relevant: the operator states that free model access (currently advertised as a 10M-token allowance) and a free server option are available, which is enough to stand up an isolated project, point the same fixture at a real model, and compare answers from raw versus projected payloads. Treat those terms as operator-supplied and check the current page before you rely on them — allowances and server options change, and I have not benchmarked throughput or hardware here.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The measurement is simple. Take twenty synthetic records that produce a known correct diagnosis, run each through the model twice — once raw, once projected — and score whether the diagnosis survives. If accuracy collapses, your synthesize rules are too aggressive. If nothing changes, your drop rules are probably not firing.

Step 6 — Detect, then recover

Prevention fails eventually, so make failure loud. Scan rendered prompts before they are persisted, with deliberately dumb heuristics:

# scan a prompt log directory for shapes that should never be stored
grep -rEn 'CANARY-|sha256=[0-9a-f]{64}|Bearer [A-Za-z0-9._-]{20,}|AKIA[0-9A-Z]{16}' ./prompt-logs \
  && echo 'LEAK: rotate before continuing' && exit 1

A pattern match is not proof of a leak, and a clean scan is not proof of safety. It is a tripwire on the specific mistake you already made once.

Found in prompt log	Rotate	Notify
Signing secret	All tenant webhook secrets in that scope	Tenant owner, within the contract window
Session cookie	Invalidate sessions for the affected scope	Security on-call
Tokenized identifier only	Nothing	Nobody — but log the near miss

What this does not cover

Be honest about the edges. Key-name classification breaks the moment a customer pastes a secret into a free-text body field — you get shape-only values, which helps, but not extraction. Canaries only catch values you planted. Self-hosting the model removes network egress but not the prompt log on your own disk. And if your contract requires sending raw customer content to a processor, this gate is the wrong tool; go fix the contract first.

Who should not use this

Teams with no prompt log store: you cannot detect what you do not keep, and you cannot keep what you have not classified.
Anyone without a rotation runbook: redaction without recovery is theater.
Teams sending regulated data where legal review has not signed off on the synthetic-value approach.

The boundary question worth taking to your next review: which of these invariants belongs in CI as a canary test, which belongs in the assembler as an allowlist, and which one are you still pretending a system prompt will enforce?

Default-Deny Egress Before Your Agent Meets a Free Model Endpoint

jaryn — Fri, 16 Oct 2026 04:45:35 +0000

Here is a script I keep watching play out. A team reads that a free tier exists, spins up an agent on someone else's host, points it at a hosted model, and ships a demo by Friday. Nobody asks where the data went until an auditor does.

So let me ask the uncomfortable version early: if your agent runs on a host you don't fully control, what exactly is stopping it from sending your repository somewhere you never approved?

I'm not going to re-report benchmark news I haven't verified myself. But the trend signal is easy to read. DEV's front page this week is full of AI fatigue, "AI got better while software didn't," and posts about thousands of open-source AI projects landing in a single weekend. Teams respond by trying free tiers. And a free tier is exactly when the trust-boundary question gets real, because you're adopting two new boundaries at once.

This post is a security walkthrough. Threat model first, then two enforcement layers you can actually test, then a decision table for what may cross which boundary. Everything below is runnable fixture code, not a policy document.

The threat model, in five lines

Write this down before you write any agent code. If you can't fill all five lines, you don't have a threat model, you have a vibe.

Asset: the plaintext your agent can read — source, .env files, logs, ticket bodies, fixture data with real customer rows.
Actor: anything that can influence the payload. That includes prompt injection from a fetched file, a compromised dependency, and a helpful teammate who pastes a token "just for testing."
Path: prompt assembly → HTTP client → TLS → someone else's inference host.
Invariant: no secret-shaped string and no denied data class ever leaves the host, even when the agent is wrong.
Evidence: a failing canary connection and a failing unit test, both executed in CI.

Note line four. The invariant has to survive an agent that is confidently incorrect, because that is the normal state of agents.

Two boundaries, and only one can see plaintext

This is the part people get wrong, and it costs them a false sense of safety.

Layer	Where it lives	What it can see	What it can enforce
Content gate	Your process, before encryption	Full plaintext payload	Regex/classifier rules on strings
Destination gate	The kernel, on the host	IP, port, protocol, volume	Allowlist, default deny, counters

The content gate can read everything and can be bypassed by any code path that skips it. The destination gate cannot read anything, and cannot be bypassed by application code — but it also can't tell a secret from a shopping list. You need both, and you need to know which one is load-bearing when they disagree.

Step 1 — Write the egress contract before you write the agent

The contract is a small file that both layers read. One source of truth, two enforcement points.

{
  "version": 1,
  "reviewed_at": "2026-10-16",
  "allowed_destinations": ["203.0.113.10:443"],
  "resolver": "203.0.113.53:53",
  "data_classes": {
    "public_docs": "send",
    "internal_source": "send_after_review",
    "customer_pii": "never",
    "credentials": "never",
    "logs_with_tokens": "never"
  }
}

Two rules for this file. Pin the destination by IP and port, not by hostname — DNS is a second trust boundary and I'd rather not argue about it in a review meeting. Second, date it. An undated contract is a rumor.

Step 2 — Enforce destinations in the kernel

On a host where you control the kernel, this is the whole game. Default deny, allow the one endpoint, count and log the rest.

#!/usr/sbin/nft -f
# /etc/nftables.d/agent-egress.nft
table inet agent_egress {
  set allowed_dst {
    type ipv4_addr
    flags interval
    elements = { 203.0.113.10 }
  }

  chain output {
    type filter hook output priority 0; policy drop;

    oifname "lo" accept
    ct state established,related accept
    ip daddr @allowed_dst tcp dport 443 accept
    ip daddr 203.0.113.53 udp dport 53 accept
    meta nfproto ipv6 drop
    counter log prefix "agent-egress-drop " level warn
  }
}

Load it and confirm it took effect:

sudo nft -f /etc/nftables.d/agent-egress.nft
sudo nft list table inet agent_egress

Now prove it with a canary. A rule you haven't tested is a comment with extra steps.

CANARY=203.0.113.99
if timeout 5 bash -c "exec 3<>/dev/tcp/${CANARY}/443" 2>/dev/null; then
  echo "FAIL: canary destination reachable"; exit 1
else
  echo "PASS: egress blocked"
fi

sudo nft list table inet agent_egress | grep -c "agent-egress-drop"

If the canary connects, stop. Fix the policy before you debug the agent.

Step 3 — Enforce content where plaintext exists

Kernel rules can't read a payload, so the string policy has to live in the process that builds the request. Keep it dumb and fast.

# gate/preflight.py
import json, re

SECRET_PATTERNS = {
    "aws_access_key": re.compile(r"\bAKIA[0-9A-Z]{16}\b"),
    "github_pat": re.compile(r"\bghp_[A-Za-z0-9]{36}\b"),
    "private_key": re.compile(r"-----BEGIN [A-Z ]*PRIVATE KEY-----"),
    "bearer": re.compile(r"\bBearer\s+[A-Za-z0-9._\-]{20,}"),
}

DENY_CLASSES = {"customer_pii", "credentials", "logs_with_tokens"}


class EgressViolation(Exception):
    """Raised before bytes leave the process."""


def assert_payload_allowed(payload: str, contract: dict, declared: str) -> str:
    if contract["data_classes"].get(declared) == "never" or declared in DENY_CLASSES:
        raise EgressViolation(f"data class '{declared}' is not sendable")
    hits = sorted(n for n, rx in SECRET_PATTERNS.items() if rx.search(payload))
    if hits:
        raise EgressViolation(f"payload matched {hits}")
    return payload


if __name__ == "__main__":
    contract = json.load(open("egress.contract.json"))
    print(assert_payload_allowed("how do I pin nftables?", contract, "public_docs"))

And the fixture pair, because one-sided tests are theatre:

# tests/test_preflight.py
import pytest
from gate.preflight import EgressViolation, assert_payload_allowed

CONTRACT = {"data_classes": {"public_docs": "send", "customer_pii": "never"}}


def test_negative_secret_shaped_string_is_blocked():
    with pytest.raises(EgressViolation):
        assert_payload_allowed("token: ghp_" + "a" * 36, CONTRACT, "public_docs")


def test_negative_denied_class_is_blocked():
    with pytest.raises(EgressViolation):
        assert_payload_allowed("email a@b.example", CONTRACT, "customer_pii")


def test_positive_public_question_passes():
    assert assert_payload_allowed("regex help?", CONTRACT, "public_docs") == "regex help?"

Step 4 — Wire both layers into one gate

Enforcement that isn't in CI is a suggestion.

# .github/workflows/egress.yml
name: egress-gate
on: [pull_request]
jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install pytest
      - run: pytest -q tests/test_preflight.py
      - run: bash scripts/canary.sh

The unit tests catch content regressions in seconds. The canary catches the day someone relaxes the firewall "temporarily." Different failure modes, different layers, same gate.

Decision table: what may cross which boundary

Data class	Send to hosted model?	Store on the host?	Enforced by
Public docs, OSS source	Yes	Yes	Nothing — it's already public
Internal source	Only after review, pinned revision	Yes	Content gate + review
Customer PII	No	Only if already required by policy	Content gate, deny class
Credentials, tokens	No	Canary/short-lived only	Both layers, deny class
Logs with tokens	No	Redact at write time	Content gate, plus log sink policy

Where a free tier genuinely helps, and where it doesn't

Here's the honest version of the pitch. Two things matter for this workflow.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

First, the free model access matters because this whole approach depends on repeatedly running negative fixtures — canary probes, secret-shaped payloads, denied data classes. That is cheap, boring traffic, and paying per token to run it is silly. Second, the free server option matters because Layer 2 only exists if you control the kernel. On a pure client-side SaaS you can't write an output chain; you can only hope the application calls your gate.

If the host you get is a locked-down container without NET_ADMIN, you cannot load that nftables table — plan for substituting a forced proxy plus a resolver you control, or accept that you only have Layer 1. Check before you design around it.

The project advertises a free tier that at the time of writing includes 10M tokens and a free server. Treat that as operator-supplied and verify the current limits yourself on the project's own page before you build a budget on it; quotas move, and dated assumptions rot fast.

If you want to try the negative-fixture suite against an endpoint you don't own, a free tier is a reasonable place to start — just bring your own contract.

Limitations and failure modes

Be clear-eyed about what this does not do.

TLS is opaque to you. The destination gate sees IPs and ports. You cannot content-inspect the inference request without terminating TLS with a CA you control, which means running a broker you now have to secure too.
DNS is a second door. Pin the resolver, or an attacker swaps the name behind an allowed IP.
DoH/DoT bypass. A dependency that ships its own resolver walks around your port-53 rule.
Package installs break. Default-deny means your mirror must be on the allowlist, or builds fail at 2 a.m.
Counters lie by omission. If the log rule is the only evidence and nobody reads it, you have detection without detection.

Who should not use this

Don't build this for a throwaway weekend experiment on public sample data — the overhead isn't worth it, and default-deny rules will just slow you down. Don't use it if you need full payload inspection of encrypted traffic and you're not prepared to run a TLS-terminating broker with its own threat model. And don't adopt it as a substitute for data classification: the gate enforces what you declared. If your team can't say which column is PII, no firewall will guess for you.

The boundary question

The gate works when both layers are boring and both are tested. So the question I'd leave you with isn't whether to allowlist — it's where the decision belongs. Should the invariant "this data class never leaves" live in CI as a unit test, or in the kernel as a rule that ignores your application entirely?

I have an opinion, but it depends on your blast radius. Which layer would you trust when the agent is confidently wrong?

Build a Pre-Prompt Egress Ledger Before an Agent Reads Your Repo

jaryn — Thu, 15 Oct 2026 11:08:05 +0000

"This test is failing. Just fix it."

That is the entire prompt. The agent picks a read set, the read set is the repository, and the repository contains .env.local, a curl transcript under logs/, a deploy.yaml pointing at prod-db.internal, and a notebook with a traceback in it. Forty minutes later the test is green, and the context window has seen all four.

There is no attack in this story. No exploit, no malicious dependency, no clever payload. A read set was assembled once, by a tool, without an inventory, and the transcript turned up in a ticket two days later. I keep watching that sequence happen often enough that I stopped treating it as bad luck.

This week's DEV front page is heavy on AI fatigue and browser-side AI features. Underneath both sits one unglamorous question: what does the tool get to read, and who can prove it afterwards? That question has a boring, testable answer. So let's build the test instead of arguing about it.

1. The boundary moved. `.gitignore` never claimed to be a privacy control.

Most teams have exactly one rule for sensitive files: do not commit this. They have zero rules for do not send this. Those are different sets, and only the first set has tooling behind it.

Here is the pipeline nobody draws in the design doc:

your repo  ──▶  read set  ──▶  prompt assembly  ──▶  model request  ──▶  retention
    │              │                │                   │
 .gitignore        ?                ?                   ?            ?

.gitignore guards the first arrow and nothing else. Once the agent decides a file is useful, a committed-ignore rule has no opinion about it at all.

Why does that bite so reliably? Because the component choosing the read set is optimizing for recall. More context means better answers. Nothing in that loop asks whether a file was ever meant to leave the building.

2. Turn "be careful" into four answerable questions

Vague guidance does not survive a deadline. Four questions do:

Which files were in the read set for this task?
Which of those files contain data that must not leave the organization?
What is the token cost of a minimal read set versus the whole tree?
Which layer fails the build when question 2 has a non-empty answer?

If your honest answer to question 4 is "a comment in code review," you do not have a gate. You have a hope with a reviewer attached.

3. Step 1 — build the dirty fixture before you build the detector

If you write the classifier first, you will tune it until it passes on the leak you already know about. That is the one case you did not need help with. Build the fixture first, watch it fail, then make the detector fail with it.

mkdir -p fixtures/egress/docs fixtures/egress/src fixtures/egress/logs \
         fixtures/egress/conf fixtures/egress/notebooks

printf 'Runbook: rotate the staging key before the demo.\n' > fixtures/egress/docs/runbook.md
printf 'def handler(event):\n    return {"ok": True}\n' > fixtures/egress/src/handler.py
printf 'API_KEY=REDACTED_PLACEHOLDER_0000000000\n' > fixtures/egress/.env.local
printf "curl -H 'Authorization: Bearer PLACEHOLDER_TOKEN_VALUE_0001' https://api.example.com/v1/orders\n" > fixtures/egress/logs/curl.txt
printf '2026-10-15T02:10:44Z GET /v1/orders 200 X-Request-Id: 8f3c1a7b peer=10.0.4.7\n' > fixtures/egress/logs/api.log
printf 'db_host: prod-db.internal\n' > fixtures/egress/conf/deploy.yaml
printf 'Traceback (most recent call last):\n  File "handler.py", line 1, in handler\n' > fixtures/egress/notebooks/repro.txt

mkdir -p fixtures/clean/src
printf 'def add(a, b):\n    return a + b\n' > fixtures/clean/src/mathlib.py

Every value above is a placeholder, not a live credential. That matters: a fixture repository that contains real secrets is just a second incident waiting to happen.

Why keep two fixtures instead of one? Because a detector that flags everything is as useless as one that flags nothing. The clean tree is the negative control, and it is the only thing stopping your team from disabling the gate in week two.

4. Step 2 — write the ledger

Four design constraints, chosen so this survives contact with a free-tier container: standard library only, deterministic output, fail closed on credentials, and honest token estimates.

#!/usr/bin/env python3
"""tools/egress_ledger.py -- classify a workspace before any of it becomes a prompt."""

from __future__ import annotations

import argparse
import hashlib
import json
import re
import sys
from pathlib import Path

SKIP_DIRS = {'.git', 'node_modules', '.venv', 'venv', 'dist', 'build', 'target', '__pycache__'}
SKIP_EXT = {'.png', '.jpg', '.jpeg', '.gif', '.ico', '.pdf', '.zip', '.gz', '.woff2', '.mp4', '.so'}
MAX_BYTES = 2 * 1024 * 1024
UNKNOWN_WEIGHT = 10

RULES = (
    ('SECRET', 100, re.compile(
        r'AKIA[0-9A-Z]{16}'
        r'|-----BEGIN [A-Z ]*PRIVATE KEY-----'
        r'|(?i:\b(?:api[_-]?key|secret|passwd|password|token)\b\s*[:=]\s*[\x22\x27]?[A-Za-z0-9_\-/+]{16,})'
        r'|(?i:\bauthorization\s*:\s*(?:bearer|basic)\s+\S+)'),
     'credentials, private keys, auth headers'),
    ('CUSTOMER', 100, re.compile(
        r'(?i:\b(?:customer[_-]?id|account[_-]?number|invoice[_-]?id|ssn|date[_-]?of[_-]?birth)\b)'),
     'customer identifiers or PII fields'),
    ('INTERNAL', 50, re.compile(
        r'\b10\.\d{1,3}\.\d{1,3}\.\d{1,3}\b'
        r'|\b192\.168\.\d{1,3}\.\d{1,3}\b'
        r'|\.internal\b|\.corp\b'
        r'|(?i:\bprod-db\b|\bstaging-[a-z0-9-]+\b)'),
     'internal hosts, environments, infra names'),
    ('TRACE', 30, re.compile(
        r'Traceback \(most recent call last\)'
        r'|(?i:\bx-request-id\b|/var/log/|FAIL_TO_PASS)'),
     'runtime traces, log paths, request ids'),
)


def iter_files(root: Path):
    for path in sorted(root.rglob('*')):
        if not path.is_file():
            continue
        if any(part in SKIP_DIRS for part in path.parts):
            continue
        if path.suffix.lower() in SKIP_EXT or path.stat().st_size > MAX_BYTES:
            yield path, None
            continue
        yield path, path.read_text(encoding='utf-8', errors='replace')


def classify(text: str):
    hits = []
    for name, weight, pattern, why in RULES:
        found = pattern.findall(text)
        if found:
            hits.append({'class': name, 'weight': weight, 'matches': len(found), 'why': why})
    return hits


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument('--root', default='.')
    ap.add_argument('--out', default='egress-ledger.json')
    ap.add_argument('--internal-budget', type=int, default=0)
    args = ap.parse_args()

    root = Path(args.root).resolve()
    entries, weight_sum = [], 0

    for path, text in iter_files(root):
        rel = path.relative_to(root).as_posix()
        size = path.stat().st_size
        if text is None:
            weight_sum += UNKNOWN_WEIGHT
            entries.append({'path': rel, 'class': 'OPAQUE', 'weight': UNKNOWN_WEIGHT,
                            'bytes': size, 'tokens_est': None, 'sha256': None, 'hits': []})
            continue
        hits = classify(text)
        hit_weight = sum(h['weight'] for h in hits)
        weight_sum += hit_weight
        entries.append({
            'path': rel,
            'class': hits[0]['class'] if hits else 'PUBLIC',
            'weight': hit_weight,
            'bytes': size,
            'tokens_est': len(text) // 4,   # estimate only, not a tokenizer
            'sha256': hashlib.sha256(text.encode('utf-8')).hexdigest(),
            'hits': hits,
        })

    manifest = {'root': str(root), 'files': entries,
                'totals': {'files': len(entries), 'weight': weight_sum,
                           'tokens_est': sum(e['tokens_est'] or 0 for e in entries)}}
    Path(args.out).write_text(json.dumps(manifest, indent=2) + '\n', encoding='utf-8')

    hardest = []
    for e in entries:
        if e['class'] in ('SECRET', 'CUSTOMER'):
            hardest.append(e['path'])
            print('[FAIL] %-9s %s' % (e['class'], e['path']))
        elif e['class'] in ('INTERNAL', 'TRACE', 'OPAQUE'):
            print('[WARN] %-9s %s' % (e['class'], e['path']))

    print('[LEDGER] files=%d tokens_est=%d weight=%d -> %s'
          % (len(entries), manifest['totals']['tokens_est'], weight_sum, args.out))
    if hardest:
        return 30
    if weight_sum > args.internal_budget:
        return 20
    return 0


if __name__ == '__main__':
    sys.exit(main())

Label check before you run anything: these scripts are templates I am handing you, not a report on your repository. Nothing below claims your repo leaks. Run the fixture, diff the exit code, and then point it at your own tree.

Notice what the script does not try to be. It is not a secret scanner with a maintained rule pack, and it is not a data-loss-prevention product. It is a 90-line inventory that answers question 2 from section 2 and returns an exit code other tools can depend on.

5. Step 3 — run it and diff the exit codes

python3 tools/egress_ledger.py --root fixtures/egress --out /tmp/dirty.json; echo "exit=$?"
python3 tools/egress_ledger.py --root fixtures/clean  --out /tmp/clean.json; echo "exit=$?"
head -40 /tmp/dirty.json

Fixture	Expected stdout	Expected exit
`fixtures/egress`	`[FAIL] SECRET .env.local`, `[FAIL] SECRET logs/curl.txt`, plus `[WARN]` lines for `deploy.yaml`, `api.log`, `repro.txt`	`30`
`fixtures/clean`	`[LEDGER] ... weight=0` and nothing else	`0`

The contract is the point: 0 means the read set is within budget, 20 means infrastructure and trace metadata exceeded the budget, 30 means credentials or customer data are present. Three codes, three different conversations.

Now wrap both in an acceptance test so nobody has to remember the numbers:

#!/usr/bin/env bash
set -uo pipefail

run() { python3 tools/egress_ledger.py --root "$1" --out "$2" >/dev/null 2>&1; echo $?; }

dirty=$(run fixtures/egress /tmp/dirty.json)
clean=$(run fixtures/clean /tmp/clean.json)
printf 'dirty=%s clean=%s\n' "$dirty" "$clean"

[ "$dirty" -eq 30 ] || { echo 'FAIL: the dirty fixture must fail closed with 30'; exit 1; }
[ "$clean" -eq 0 ]  || { echo 'FAIL: the clean fixture must exit 0'; exit 1; }
echo 'OK: egress gate behaves as specified'

If your first run against a real repository returns 30, do not delete the gate. Open the manifest, read the match, and choose one of three actions: rotate the credential, redact the file, or allowlist the path with a comment explaining why. All three are decisions. Deleting the check is just deferring one.

6. Step 4 — make the gate a dependency, not a habit

A gate that lives in a README is a suggestion. Wire it into the step that builds the prompt:

.PHONY: egress-gate

egress-gate:
    python3 tools/egress_ledger.py --root . --out egress-ledger.json --internal-budget 40

prompt.md: egress-gate
    @test -s egress-ledger.json
    python3 tools/assemble_prompt.py --scope diff --out $@

And in CI, run the negative fixture every time so the test itself cannot rot:

name: egress-gate
on: [pull_request]
jobs:
  ledger:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - name: negative fixture must fail closed
        run: |
          set +e
          python3 tools/egress_ledger.py --root fixtures/egress --out /tmp/dirty.json
          test $? -eq 30 || { echo 'negative fixture did not fail closed'; exit 1; }
      - name: gate the real tree
        run: python3 tools/egress_ledger.py --root . --out egress-ledger.json --internal-budget 40
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: egress-ledger
          path: egress-ledger.json

Treat egress-ledger.json itself as INTERNAL, by the way. It is a complete file inventory with paths and hashes. Uploading it as a public artifact would hand over the map you just drew.

7. The prevent / detect / recover table

Asset	Boundary crossed	Failure mode	Prevent	Detect	Recover
`.env.local` values	workspace to model request	key echoed into a request log or shared transcript	ledger exits `30`	SECRET hit plus prompt log review	rotate key, invalidate sessions
Internal hostnames	repo to model context	topology leak inside a completion	`--internal-budget 0`	`[WARN] INTERNAL` lines	rename hosts, treat as recon
Customer rows in notebook output	notebook to prompt	PII inside a retention window	strip outputs in pre-commit	`[FAIL] CUSTOMER`	follow your notification path
Trace logs with headers	log file to agent context	bearer token in a provider trace	scrub before assembly	TRACE rule plus header regex	rotate, shorten retention
Whole-repo paste	agent read set	over-broad read set	diff-scoped reads	`tokens_est` versus scope	re-run with a narrower scope

Three columns, three different owners. Prevention belongs to whoever owns the repo. Detection belongs to whoever owns CI. Recovery belongs to whoever owns the incident channel, and they should know their row before they need it.

8. What not to send at all

Some files should not be argued about, only excluded:

.env*, *.pem, *.key, id_rsa, service-account.json
kubeconfig, .aws/credentials, .npmrc, .pypirc
terraform.tfstate and any plan output
*.sql dumps and fixtures generated from production
.har files and browser network exports
CI logs with masked-but-recoverable tokens
Notebook outputs, which often carry stack traces and sample rows you forgot were there

The list is short on purpose. A deny list nobody reads is worse than no list, because it creates the feeling of coverage.

9. Where the free tier actually fits

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The workflow above has one awkward property: it wants to run where the read set is assembled, not on your laptop. MonkeyCode is an open-source AI development platform, and its operator offers free model access plus a free server option (the operator currently quotes a 10M-token allowance; quotas, regions, and terms change, so check the current ones before you plan around them). That combination makes the negative fixture cheap to run: the free server gives you a workspace container, and the free model tier gives you something to assemble a prompt against without a billing conversation.

The honest reason it belongs in this article is narrower than availability. Prompt assembly happens on the platform side, so a gate that only runs on your local checkout is guarding a different tree from the one the agent reads. Run egress_ledger.py with --root pointed at the workspace the agent actually sees, and diff the two manifests. If your local run is clean and the workspace run exits 30, you have just learned that the two trees are not the same tree. Free tier or paid, that diff is the interesting artifact.

10. Limitations, and who should not use this

Regex classification has false negatives by construction. Base64-encoded secrets, values split across two lines, non-UTF-8 files, and anything larger than 2 MB land in OPAQUE and are counted as unknown rather than clean. Unknown is not clean — that is a stance, not a measurement.

The tokens_est field is len(text) // 4. It is a rough planning number, not a tokenizer, and it must never be used for billing or quota arithmetic.

The gate is prevention-only. It says nothing about what already left, and it produces no evidence about a vendor's retention behavior. If you need a data-flow inventory signed by a processor, this script is not that document.

Skip this approach if your secrets live in the CI environment rather than in files — your boundary is different and this ledger will look deceptively clean. Skip it if you need a guarantee instead of a gate. And skip it if you cannot commit to keeping the negative fixture green, because a classifier nobody re-tests decays into a regex that matches nothing and reports success.

Which invariant belongs in CI?

Two candidates, and they are not equivalent. "No file in the read set may be classified SECRET or CUSTOMER" is a hard invariant with a hard exit code. "The read set must be scoped to the diff" is a policy that shrinks the blast radius without ever being provable from a single run.

I put the first one in CI and the second one in the prompt-assembly step. Which one would your team actually enforce on a Friday afternoon — and which layer would have to own it for that to be true?

Audit a Workspace Read Set Before an Agent Indexes It

jaryn — Mon, 12 Oct 2026 23:00:17 +0000

I asked a coding agent to explain a failed terraform plan. It did. The context-pack preview also listed terraform.tfstate and a .env beside the module. Did the model need either file to explain a missing variable? No. Did the process have permission to open both? Yes. That is the failure I now refuse to skip. I have not filed it as a production incident, and I am not claiming a vendor leaked anything.

A DEV discussion this week argued that models improved while the software around them did not. I am not relitigating that post. I am asking a narrower question. If the indexer got better at walking a tree, did your allowlist shrink, or did you hand it a bigger directory?

Two boundaries, not one

People collapse these into an AI policy slogan, and then they test the wrong layer.

The first boundary is local and boring. Which paths can the agent uid open before a single token is spent? If open succeeds, you already lost, even when the weights run on a box you racked yourself.

The second boundary is egress. A hosted free server is not a cheaper synonym for a local model. Bytes leave the laptop. Self-hosting can shrink that second boundary. It does nothing for the first.

So which one are you actually proving when you say secrets never reach a model?

laptop
  agentfix uid -- test -r --> src/app.js     allow
  agentfix uid -- test -r --> .env           deny
  hosted free server                         egress, canaries only

What stays out of the index

I keep the denylist dull. Clever patterns miss the file the walker opens first.

Credential basenames come first: .env, .env.local, .netrc, .npmrc, .pypirc, id_rsa, id_ed25519, and credentials. Cloud and cluster admin files sit next to them: anything named kubeconfig, plus the usual AWS and gcloud config trees if you were careless enough to mount a home directory. State and dumps follow: terraform.tfstate, terraform.tfstate.backup, SQL dumps, and packet captures.

VCS metadata is the sneaky one. A .git/config remote with a userinfo field is a token that does not look like a token. Would I paste that list into a chat and ask the model to be careful? No. The decision is a file-mode check. A sentence in a system prompt is not a lock.

Step 1. Pin the tools and the manifest

This whole fixture is an unexecuted template. I did not run it in CI this week. Expected lines below are assertions you should see if you run it, not a log I captured.

Pin the interpreter before you trust the exit code. I wrote the gate for Bash 5.2, Git 2.40 or newer, and GNU findutils 4.9. On macOS, take those from Homebrew. BSD find will not honor the same flags, and a green run on the wrong find is not evidence.

# readset.deny — exact basename, one per line
.env
.env.local
.netrc
.npmrc
.pypirc
id_rsa
id_ed25519
credentials
kubeconfig
terraform.tfstate
terraform.tfstate.backup

A basename of credentials will also match a harmless test file with that name. That false positive is intentional. Rename the test file. Do not delete the rule because it annoyed a unit test.

Step 2. Build the positive fixture

Use a scratch directory on a lab VM. Never point the first run at your real home folder, and do not create this uid on a shared workstation.

mkdir -p /tmp/readset-fixture/src
printf 'AWS_SECRET_ACCESS_KEY=canary-not-real\n' > /tmp/readset-fixture/.env
printf 'console.log(1)\n' > /tmp/readset-fixture/src/app.js
chmod 600 /tmp/readset-fixture/.env
sudo useradd --system --create-home --shell /usr/sbin/nologin agentfix || true
sudo chown root:root /tmp/readset-fixture/.env

The positive case is the secret file. If agentfix can test -r it, the gate must exit 1. A policy line that says ignore secrets does not count. Why would it? The walker does not ask permission in English.

Step 3. Keep a negative fixture readable

src/app.js is the negative case. The gate must not fail merely because source code exists. If the denylist is so wide that the agent cannot read the file you asked it to review, someone will chmod 777 the tree and call it unblocked. I have seen that workaround on other gates. I do not want this one to teach it.

Ask one question before you add a path to the allow side. If I replaced the contents with the string REDACTED, could the agent still answer the question I typed? If yes, the file stays denied. If no, allow it, and add it to the negative fixture so a later rule cannot swallow it quietly.

Step 4. Run the gate as the agent uid

#!/usr/bin/env bash
# Unexecuted template. Assertions are intended, not captured.
set -euo pipefail
root="${1:?workspace root}"
agent_user="${2:?agent uid name}"
deny="${3:?path to readset.deny}"
fail=0

[[ -d "${root}" ]] || { printf 'missing root: %s\n' "${root}" >&2; exit 2; }
id "${agent_user}" >/dev/null

while IFS= read -r base || [[ -n "${base}" ]]; do
  case "${base}" in
    ''|\#*) continue ;;
  esac
  while IFS= read -r -d '' path; do
    if sudo -u "${agent_user}" test -r "${path}"; then
      printf 'DENY readable by %s: %s\n' "${agent_user}" "${path}" >&2
      fail=1
    else
      printf 'ok denied: %s\n' "${path}"
    fi
  done < <(find "${root}" -xdev -name "${base}" -print0)
done < "${deny}"

safe="${root}/src/app.js"
if [[ ! -f "${safe}" ]]; then
  printf 'negative fixture missing: %s\n' "${safe}" >&2
  exit 2
fi
if ! sudo -u "${agent_user}" test -r "${safe}"; then
  printf 'SAFE path not readable, denylist too wide: %s\n' "${safe}" >&2
  fail=1
fi
exit "${fail}"

Intended evidence, once you actually run it: exit 1 and a DENY readable line when .env is mode 644; ok denied plus exit 0 when .env is mode 600 and owned by someone other than agentfix, while src/app.js stays readable. If you cannot create that uid, stop. A check that runs as you will pass for every file you can already read. That green bar is worse than no bar.

find -xdev will not cross filesystems. A secret mounted elsewhere is invisible to this gate. If the agent can see that mount, pass it as its own root, or drop -xdev and accept the slower walk. Either way, write the choice down. A silent skip is not a deny.

Step 5. Decide where the bytes are allowed to go

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The gate above does not know which model you call next. That is the point. I still want a cheap place to rehearse the deny path, because a script that never runs is a comment with a shebang.

For this draft, MonkeyCode is described as offering free model access and a free server option. I am not stating a token quota, a hardware shape, a region, or an expiry. Those figures move, and I have not re-checked a primary page while writing. Read the project docs on the day you rely on them.

Here is the split I would not blur.

Place you run the rehearsal	Proves the uid cannot read the denylist?	Proves bytes stayed on your network?	Fit
Local agent uid, no model call	Yes, if `sudo -u` is real	Yes, nothing left	Always run this first
Model server you already operate	No, unless you also ran the gate	Only if you configured it that way	After the gate is red or green for real
Hosted free server	No	No	Canary trees only

Use the hosted option only after the positive fixture contains a canary string, not a live key. A free server answers whether the workflow can run. It does not answer whether the data may leave. If your team needs a contract before any workspace byte leaves the laptop, skip the hosted path and point the same gate at a model you already run.

If you want a non-production checkout to prove the gate fails closed, that free model access is enough to rehearse the deny path. It is not a reason to mount a production tree.

Prevent, detect, recover

Phase	Control	Evidence that counts
Prevent	Dedicated agent uid, no home mount, denylist checked with `test -r`	Denylisted paths print `ok denied`
Detect	CI runs the gate on the workspace before any indexer starts	Non-zero exit and the path, not a model summary of the path
Recover	Rotate anything that was readable, then fix the mode	New canary present, old canary absent from agent logs

Recovery is rotation, not a request that the model forget. If a hosted server already received the file, treat it as disclosed to that operator and follow your own vendor process. I will not invent a deletion promise here.

Logs are part of the same boundary. A gate that prints the secret while proving the secret was readable has just copied it into CI output. Print the path. Never print the file. Would you scroll that log into a chat to ask why CI failed? Then the log is the next thing to deny.

Who should not use this

Skip the hosted rehearsal if the checkout holds customer data, production state, or anything under a residency clause. The local gate is still worth running. A zero invoice does not make a server a sandbox.

Skip the whole approach if you cannot create a separate uid. Also skip it as a replacement for history scanning. This fixture sees the current tree and one uid. It will not see a token committed last March and deleted from HEAD. Pair it with a history scanner you already trust. I am not crowning one.

Do not use the gate as proof that a product is safe. It proves one invariant on one machine: this uid cannot read these basenames. That is all. It also will not catch a secret pasted into a source comment, a screenshot, or a prompt you typed by hand. Those need a different fixture.

What this draft is not

I did not execute the template against MonkeyCode. I did not measure latency, token spend, or a vulnerability. There is no CVE in this post, and there is no benchmark. If you run the script, keep the output. That output is the evidence. The draft is only the procedure.

One invariant belongs in CI. The agent uid cannot read the denylist. One layer should enforce it. Filesystem permissions, before the indexer starts. The model is a reader. It is not the lock.

Which path in your tree is still mode 644 only because the agent might need it?

Reproduce a WAF Sample Leak With a Never-Send Fixture

jaryn — Sun, 11 Oct 2026 20:14:20 +0000

I rebuilt a near-miss as a fixture, not as a named customer outage. A checkout rule fires on a POST that should have passed. The scratch file holds a Cookie, an upstream token, an email, and a comment about an office NAT bypass. The paste key is already halfway down.

That habit is the failure. A model prompt is an export. If I would not attach the scratch file to a public ticket, it does not cross a model boundary. A free host does not edit that rule.

The failure mode is the paste

I write the invariant before any prompt exists. The laptop may hold the raw sample. A local gate may read it. The outbox may not contain a secret. Anything past the outbox is outside the trust zone.

Would you drop that scratch file into a public gist so a stranger could take a look? No? Then a chat box is not a private notebook. It is an egress path with a friendly cursor.

This piece is not a vulnerability report. I did not run a vendor export, and I am not claiming a WAF product leaked anything. The human path is untested until a fixture fails closed.

Trust boundaries, drawn small

Keep four zones, and keep them boring. The workstation is inside: it already has the sample, which you can encrypt and wipe. The gate is inside too: it prints reason codes and refuses to write an outbox file on a hit.

Reason codes name the field. They must not echo the value. A CI log that reprints an Authorization header is the same leak with extra steps. Which log pipeline scrapes stderr on your runner? Know that before you add a helpful debug print.

The outbox is the only artifact allowed to leave. If a file is not in the outbox, it is not a prompt. The hosted model, and any free server you did not build, sit outside. They can discuss a redacted signature. They do not get raw on-call bytes.

scratch file --> local gate --fail closed--> stderr codes (field names only)
                    |
                    +--only if clean--> outbox/ --> hosted assistant

A free server does not collapse that drawing. If you did not provision the box, own the disk, and name the log sink, treat it as a third party. I am not describing a product topology. I am describing the default until a data-flow diagram says otherwise.

What a blocked request quietly carries

People shrug and call it just a WAF sample. Look again. Headers often carry Authorization, Cookie, X-Api-Key, or an upstream token stuffed into X-Internal-Token. The body excerpt can hold an email, a phone, or a long digit run.

The rule comment is worse than the request. That is where bypass notes, office CIDRs, and a copied basic-auth line go to live. The match context is frequently the secret itself, because the engine shows the bytes that fired.

Which of those do you want in a transcript you cannot delete on your own clock? I want none of them. The table is the decision, not the mood.

Field	Send to a model?	Reason
rule_id	Yes	Identifier, not a credential
Header names with values already replaced	Yes	Shape without secrets
Raw Cookie or Authorization	No	Session or bearer material
Rule comment with a bypass CIDR or copied secret	No, until redacted	Topology plus credential
Synthetic body you generated	Yes	Not customer content
Customer body excerpt	No	Content, and often a token

I am not claiming SafeLine, ModSecurity, or any other engine leaks by default. The stand-in schema is waf-sample/v0. I made it up so the fixture has a contract. Map your real export before you trust a green check.

1. Pin the invariant

Fail closed. A sample with a denylisted header, a PEM private-key banner, a bearer-shaped string, an email, or an AKIA access-key shape must not produce an outbox file. Exit 2 is the passing result for that case.

A green job on a leaky sample means the control is installed backwards. Would you celebrate a firewall test that only passes when the deny rule is deleted? Same energy.

Positive fixture: secrets present. Spec: exit 2, no outbox write. Negative fixture: high-risk patterns already gone. Spec: exit 0, outbox written. Hidden fixture: headers look clean, secret sits in rule_comment. Spec: exit 2, hit path under $.rule_comment.

I have not executed this template in the environment that will publish the post. Those exits are the specification, not a measured run. Do not cite them as a benchmark. Python 3.11 or newer, standard library only. I am not pinning a third-party scanner I did not install.

2. Lay down three synthetic samples

Positive. Obviously fake. Still enough to trip the gate. Save it as fixtures/positive_leak.json.

{
  "schema": "waf-sample/v0",
  "rule_id": "checkout-sqli-17",
  "headers": {
    "Authorization": "Bearer EXAMPLE.not.a.secret",
    "Cookie": "session=example-session-value",
    "Content-Type": "application/json"
  },
  "body_excerpt": "email=ada@example.com",
  "rule_comment": "office bypass note removed from this fixture on purpose"
}

Negative. This is what done looks like. Save it as fixtures/negative_clean.json.

{
  "schema": "waf-sample/v0",
  "rule_id": "checkout-sqli-17",
  "headers": {
    "Authorization": "[redacted]",
    "Cookie": "[redacted]",
    "Content-Type": "application/json"
  },
  "body_excerpt": "email field removed",
  "rule_comment": "bypass note removed"
}

Hidden. A header denylist alone will miss it. That miss is the test. Save it as fixtures/hidden_in_comment.json.

{
  "schema": "waf-sample/v0",
  "rule_id": "checkout-sqli-17",
  "headers": { "Content-Type": "application/json" },
  "body_excerpt": "id=1",
  "rule_comment": "copied snippet still had Bearer EXAMPLE.not.a.secret"
}

Do not substitute a real customer capture to make the demo better. The walker also does not understand partial redaction. If an @ remains in a field, that sample is not the negative case, and the gate should stay red.

3. Drop in the gate

Unexecuted template. Read it before you run it. If your samples are gzip, pcap, or screenshots, this file will not save you. It only walks JSON strings.

#!/usr/bin/env python3
"""never_send_gate.py — unexecuted template. Spec, not a measured run.

Stand-in schema: waf-sample/v0. Python 3.11+ stdlib only.
"""
from __future__ import annotations

import argparse
import json
import re
import sys
from pathlib import Path

DENY_HEADERS = {
    "authorization",
    "proxy-authorization",
    "cookie",
    "set-cookie",
    "x-api-key",
    "x-internal-token",
}

PATTERNS = [
    ("pem", re.compile(r"-----BEGIN [A-Z ]*PRIVATE KEY-----")),
    ("bearer", re.compile(r"(?i)\bbearer\s+\S{8,}")),
    ("email", re.compile(r"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}")),
    ("aws_access_key_shape", re.compile(r"\bAKIA[0-9A-Z]{16}\b")),
]

REDACTED = "[redacted]"


def walk_strings(value, path="$"):
    if isinstance(value, str):
        yield path, value
    elif isinstance(value, dict):
        for key, item in value.items():
            yield from walk_strings(item, f"{path}.{key}")
    elif isinstance(value, list):
        for index, item in enumerate(value):
            yield from walk_strings(item, f"{path}[{index}]")


def header_hits(sample: dict) -> list[str]:
    headers = sample.get("headers") or {}
    if not isinstance(headers, dict):
        return ["headers_not_object"]
    hits = []
    for name, val in headers.items():
        if str(name).lower() in DENY_HEADERS and str(val) != REDACTED:
            hits.append("header:" + str(name))
    return hits


def pattern_hits(sample: dict) -> list[str]:
    hits = []
    for path, text in walk_strings(sample):
        if text == REDACTED:
            continue
        for label, cre in PATTERNS:
            if cre.search(text):
                hits.append(label + ":" + path)
    return hits


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--check", required=True, type=Path)
    parser.add_argument("--outbox", type=Path)
    args = parser.parse_args()
    sample = json.loads(args.check.read_text(encoding="utf-8"))
    if sample.get("schema") != "waf-sample/v0":
        print("schema_mismatch", file=sys.stderr)
        return 2
    hits = header_hits(sample) + pattern_hits(sample)
    if hits:
        print("never_send", file=sys.stderr)
        for hit in hits:
            print(hit, file=sys.stderr)
        return 2
    if args.outbox:
        args.outbox.parent.mkdir(parents=True, exist_ok=True)
        payload = json.dumps(sample, indent=2) + "\n"
        args.outbox.write_text(payload, encoding="utf-8")
    print("ok")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

Notice what it does not do. It does not print the match text. It does not call the network. It does not fix the rule. A gate that rewrites secrets into a prompt so the model can help redact has already lost.

4. Assert both directions

Green has to mean something specific. If the job only passes on exit 0, wrap the positive case. Assert exit 2, and assert the outbox path does not exist. A test that forgets the negative path is how a deny-all bug ships. You want both.

python3 never_send_gate.py --check fixtures/positive_leak.json --outbox outbox/pos.json
echo "positive_exit:$?"
# spec: exit 2, stderr starts with never_send, outbox/pos.json absent

python3 never_send_gate.py --check fixtures/negative_clean.json --outbox outbox/neg.json
echo "negative_exit:$?"
# spec: exit 0, stdout line ok, outbox/neg.json written

python3 never_send_gate.py --check fixtures/hidden_in_comment.json --outbox outbox/hid.json
echo "hidden_exit:$?"
# spec: exit 2, a bearer hit on $.rule_comment, outbox/hid.json absent

What does green mean in your pipeline today? If you cannot answer in one sentence, the fixture is not wired yet. Wire the hidden case first. That is the one a header-only cleanup will cheat.

5. Prevent, detect, recover

Phase	Control	Evidence you should demand
Prevent	Only `outbox/` may be attached to a prompt. A wrapper refuses the scratch path.	Raw sample path never shows up in the assistant CLI history.
Detect	CI runs all three fixtures on every change to the gate.	Hidden fixture goes red if someone simplifies the walker down to header keys.
Recover	If a raw sample already left, rotate the credential and treat the transcript as tainted.	Incident note lists field names, not a second paste of values.

Asking a model to forget is not recovery. I have no evidence, in this post, that any provider stored or leaked a WAF sample. The recover row exists because you cannot prove the negative after the bytes leave. Rotation does not depend on that proof.

Where an assistant is allowed to sit

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode is the open-source AI development platform this draft is allowed to discuss. Two availability claims were supplied with the assignment: free model access, and a free server option. I am not pinning a token quota, a GPU shape, a time limit, or a retention promise. Those are time-sensitive, and I will not freeze a number I have not checked against a current primary page.

So what is the workflow, once that disclosure is out of the way? Redact on the laptop. Diff the outbox. Then, if you still want a second pair of eyes on the rule logic, send the outbox only. Ask a narrow question: is checkout-sqli-17 matching the redacted body shape, or is the operator too wide? Do not ask it to look at the original. There is no original on that side of the line.

A free server is still a server. Unless it sits in a network you operate, it belongs in the outside column of the drawing above. Generated rule text is a suggestion. A human diffs it before it is loaded. Would you reload a WAF from a chat transcript with no diff? I would not, even if the model were perfect.

If you evaluate that free model access or that free server option, point either one at outbox/ and read the current data-handling terms before the first real incident. The fixture still works if you never do that. That is the test of whether this piece was worth writing.

Who should skip this

Do not use the script as a DLP product. It misses gzip, unlabeled base64, pcaps, and screenshots. It will also flag a documentation address you meant to publish. That false positive is acceptable for a never-send gate and annoying everywhere else. I did not measure a rate. Do not invent one in a slide.

Do not feed it real customer bodies to see if it works. Synthesize. If blocked payloads are customer content under a retention schedule, the fix is not a smarter prompt. Keep the body off the machine that has a model CLI installed.

Teams that need a signed data-processing agreement, or a path that never leaves the VPC, should not trial a hosted box on live samples while the paperwork catches up. Build the fixture. Then pick a host. If you cannot name the log sink, you are not ready to upload even the redacted file.

What this does not prove

I am not saying hosted models are unsafe for every debugging task. Redacted signatures, public write-ups, and synthetic requests are fair game. I am also not saying a self-hosted assistant becomes trusted because the binary is open source. Open code does not redact a Cookie you pasted. The gate does, or nothing does.

This week's public developer discussion keeps circling one mood: models got faster, and the software around them did not grow a matching boundary. I am not reviewing those posts, and I am not treating their titles as evidence. The boundary I care about is one exit code on a file you control.

The question I want in the retro

Which invariant belongs in CI this week, and which layer should enforce it live?

I would pin the positive fixture to exit 2, on synthetic files, in the same pipeline that lints WAF config. The live layer is a separate argument: an editor hook, an egress filter that blocks Authorization inside outbound prompt bodies, or both. A proxy you can bypass with a personal key is not enough on its own.

The fixture still fails closed when someone is tired and the proxy is off. If you only adopt one line from this piece, adopt that. Exit 2 on a leak is the control. The model is optional. The scratch file is not a prompt.

Audit a Paste Gate Before Logs Cross a Model Boundary

jaryn — Sat, 10 Oct 2026 16:16:29 +0000

Picture the paste sitting in a ticket comment, not in a threat report. The failing request is POST /internal/billing/replay. It returns 500. Under it, someone has already copied DATABASE_URL=postgres://app:EXAMPLE_NOT_A_SECRET@db.internal/billing and a customer email.

That text is still on the laptop. The trust boundary breaks when it is submitted to a model. I do not get the secret back. A cheerful answer is not a deletion receipt.

I want one invariant. No incident text leaves the workstation until a local gate prints class=shareable and a short hash.

Sounds fussy? Good. Fussy is cheaper than a rotation call.

The boundary I am actually defending

I am not trying to make a model polite. I am trying to keep three things on the near side of the wire: secrets, customer identifiers, and names that map the internal network.

A remote model is a new processor. A free server is also a new processor until I know who runs it, where the logs land, and how long a prompt sticks. A different hostname does not shrink that boundary.

So the useful question is not which model can explain this 500. It is which bytes are allowed to leave.

Logs are not a prompt format

Most bad pastes start as logs. An access line, an app traceback, a support export, a dashboard shot. Someone calls that context. I call it an export.

Would you hand a stranger the raw file just because the status code is interesting? I would not. A log line is an event record. It was not written as a document I consented to ship off the machine.

Query strings hide emails. Upstream URLs hide userinfo. Cookie jars and signature headers are not debugging hints. They are credentials with extra steps.

A WAF audit log is the same class of export as an app log. Timestamps and status codes can be rewritten as fields. Header tokens cannot.

I copy fields. I do not attach the file. This rewrite is the only shape I would even consider sharing:

ts=2026-10-10T00:00:00Z method=POST route=/internal/billing/replay status=500 code=E_UPSTREAM_TIMEOUT

No host. No email. No password in the URL. If I cannot rebuild the symptom from fields like that, I am not ready to ask a model. I am ready to read the code.

Screenshots are logs too. This template reads text only. A PNG does not become shareable because I forgot to OCR it. The manual rule is blunt. Images stay on the laptop.

What I refuse to send

If I cannot name the class, I do not paste the blob. A sentence that says please ignore any secrets is a wish, not a control.

Class	Example shape (fake)	Default
Connection URL	`postgres://app:EXAMPLE_NOT_A_SECRET@db.internal/billing`	block
Env assignment	`WEBHOOK_SECRET=EXAMPLE_NOT_A_SECRET`	block
Private key banner	`-----BEGIN PRIVATE KEY-----`	block
Customer email	`ada@example.com` inside a ticket	block
Internal hostname	`billing.internal`	block
Stack frame, no secret	`File app/replay.py, line 40`	human review
Synthetic health failure	`GET /healthz -> 503 E_UPSTREAM_TIMEOUT`	shareable

The examples are canaries. They are not live credentials. They are not a claim that I found them in a product.

Four zones, then a tool

I draw the zones before I pick a model. Otherwise the tool picks the boundary for me, and that is backwards.

[1 laptop] --gate--> [2 shareable text]
                         |-- [3 remote free model]
                         \-- [4 free server option]
blocked and review stay in zone 1

Zone 1 is the only zone I fully control in this walkthrough. Zones 3 and 4 can both retain prompts. Both can log.

Both may be operated by someone who is not me. I do not treat the word free as a synonym for private.

What actually crosses the gate? A classified file, a 12-character SHA-256 prefix, and the hit list. What stays home? The original ticket, the env file, the HAR, the kubectl dump, the dashboard shot.

Would I send a redacted diff of a function that is already public? Yes, after the gate. Would I send the production traceback so a model can see the real path? No. I rewrite the path to app/replay.py, then I classify again.

Step-by-step: the paste gate

This is an unexecuted template. It targets Python 3.12 and the standard library only. I have not run it for this draft. Expected lines are the contract I want, not observed output. Nothing here is a vulnerability report.

1. Pin the runner

I pin the interpreter in the command, not in a slide.

python3.12 --version
# contract: Python 3.12.x
# fixture: paste-gate-v1

If the runner is not 3.12, I stop. I will not trust an exit code from whatever python happens to be on PATH.

2. Keep the classifier offline

The script reads one file. It prints one line. It exits 0, 2, or 3. There is no socket import on purpose.

If a gate can open a network connection, it is no longer a gate. It is another exporter.

#!/usr/bin/env python3
# paste_gate.py - unexecuted template. Python 3.12, stdlib only.

import hashlib
import re
import sys
from pathlib import Path

FIXTURE_VERSION = "paste-gate-v1"

BLOCK = [
    ("connection_url", re.compile(r"\b(?:postgres|mysql|mongodb|redis)://\S+", re.I)),
    ("env_secret", re.compile(r"\b[A-Z0-9_]*(?:SECRET|TOKEN|PASSWORD|API_KEY)\s*=\s*\S+")),
    ("pem", re.compile(r"-----BEGIN (?:RSA |OPENSSH |EC )?PRIVATE KEY-----")),
    ("email", re.compile(r"\b[\w.%+-]+@[\w.-]+\.[A-Za-z]{2,}\b")),
    ("internal_host", re.compile(r"\b[\w.-]+\.(?:internal|corp|local)\b", re.I)),
]
REVIEW = [
    ("stack_path", re.compile(r"File .+, line \d+")),
]

def classify(text: str) -> tuple[str, list[str]]:
    hits = [name for name, pat in BLOCK if pat.search(text)]
    if hits:
        return "blocked", hits
    review = [name for name, pat in REVIEW if pat.search(text)]
    if review:
        return "review", review
    return "shareable", []

def main(argv: list[str]) -> int:
    if len(argv) != 2:
        print("usage: paste_gate.py <file>", file=sys.stderr)
        return 1
    raw = Path(argv[1]).read_text(encoding="utf-8")
    klass, hits = classify(raw)
    digest = hashlib.sha256(raw.encode()).hexdigest()[:12]
    print(
        f"version={FIXTURE_VERSION} class={klass} "
        f"sha256_12={digest} hits={','.join(hits) or '-'}"
    )
    return {"shareable": 0, "blocked": 2, "review": 3}[klass]

if __name__ == "__main__":
    raise SystemExit(main(sys.argv))

Why a hash prefix? So a review note can point at a file without pasting the file into chat again. Why not build the whole design around one header name? Header names change. A connection URL and a private-key banner should fail closed anyway.

The email pattern also flags userinfo in a URL, because EXAMPLE_NOT_A_SECRET@db.internal looks like a mailbox. That overlap is intended. Fail closed.

3. Add a positive fixture and a negative one

Positive means must not leave. Negative means may leave. I want both. A gate with only scary samples becomes a panic button, and nobody runs panic buttons.

fixtures/block_db_url.txt is the positive fixture:

POST /internal/billing/replay -> 500
DATABASE_URL=postgres://app:EXAMPLE_NOT_A_SECRET@db.internal/billing
WEBHOOK_SECRET=EXAMPLE_NOT_A_SECRET
customer=ada@example.com

fixtures/pass_healthz.txt is the negative fixture:

GET /healthz -> 503
code=E_UPSTREAM_TIMEOUT
note=synthetic fixture, no identifiers

fixtures/review_stack.txt is the middle, and the middle is where people cheat:

File "app/replay.py", line 40, in replay
    raise TimeoutError("upstream")

A path can be harmless. It can also be a map of the repo. That is why review is not a quiet pass.

4. Write the expected failure down

I put the contract in a comment. I do not invent a hash and pretend I executed the file.

python3.12 paste_gate.py fixtures/block_db_url.txt; echo exit:$?
# UNEXECUTED contract: class=blocked hits=connection_url,env_secret,email,internal_host exit 2

python3.12 paste_gate.py fixtures/pass_healthz.txt; echo exit:$?
# UNEXECUTED contract: class=shareable hits=- exit 0

python3.12 paste_gate.py fixtures/review_stack.txt; echo exit:$?
# UNEXECUTED contract: class=review hits=stack_path exit 3

If a later run prints class=shareable on the block file, the gate is wrong. I do not ask a model why. I fix the pattern, and I keep the failing file in the tree.

5. Pick a destination only after the exit code

Only exit 0 may be copied. Exit 3 stays in zone 1 until I delete the sensitive lines and re-run. Exit 2 never gets a second chance in the same bytes. I redact into a new file, then I classify that new file.

Destination	Exit 0 synthetic	Exit 3 stack	Exit 2 bundle
Remote free model	copy allowed	no	no
Free server I do not operate	copy allowed, assume retention	no	no
Server I operate and can wipe	copy allowed	only after rewrite and a new exit 0	redact first, then re-gate
Laptop	always	always	always

I do not edit the blocked file in place and forget which version I hashed. The hash is the point. If the bytes change, the prefix changes, and the old approval is dead.

6. Rewrite, then classify the rewrite

Before the gate, I rebuild the log into four fields. Time. Method. A route template, not a raw path if the path embeds an id. Status, plus a stable error code.

That is the whole shareable object. If the bug lives in a header, I describe the header name and the failure mode. I do not copy the header value. If the bug lives in a query parameter, I copy the parameter name and a fake value of the same shape, like id=REDACTED_INT.

Then the gate runs on the rewrite, not on the original. Two files. Two hashes. One approval.

Prevent, detect, recover

Phase	Control	Evidence I want
Prevent	Local gate, no socket, deny by default	Exit 2 on the block fixture
Detect	CI runs the three fixtures when the pattern list changes	Contract comments still match
Recover	Treat a bad paste as already disclosed	Rotate the secret, tell the owner, do not paste the same line into a cleanup prompt

Recovery is the step I see skipped. If the URL already left the laptop, redacting the next prompt does not rewind the first one. Rotate the credential. Then add a fixture so the next URL cannot match shareable.

Asking the same model to forget the previous message is not recovery. It is a second export.

Where free access actually fits

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode is an open-source project. The operator supplied two availability claims for this draft: free model access, and a free server option. I am not pinning a token quota, a model name, a hardware size, or a duration. Those figures were not checked against a primary source here, and an uncited number goes stale. Read the project page before you plan a workload around a limit.

I would still use the same gate.

A free model is a fair place for fixtures/pass_healthz.txt, and for a redacted function that is already public. It is a bad place for the billing paste, even when the allowance looks large. A large allowance is not a trust boundary.

A free server option can be the better zone when the prompt needs to stay on infrastructure I operate. Can be is not is. Until I have read how that server isolates tenants, what it logs, and who can open the disk, zone 4 sits behind the same exit codes as zone 3. If I do operate it, I still do not disable the gate. Local classification is cheaper than a forensic argument later.

If you already keep a MonkeyCode workspace, run this gate on the paste before the first completion. Let the model answer a shareable file. Do not let it decide what is shareable.

Who should not use this

Regex is a sieve. It misses a sentence that describes a firewall rule in plain English. It misses a secret split across two lines. It false-positives on a public note that contains an email, which is why example.com still blocks here. I would rather review a false positive than explain a leaked URL.

This script does not encrypt anything. It does not delete remote logs. It does not prove a provider retention setting. Exit 0 means this file matched my allow shape. It does not mean a vendor forgot the prompt.

Skip this approach if you need a real data-loss control plane, a legal hold, or a customer contract that forbids this class of export. Skip it if a green check would talk you out of rotating a secret you already pasted. Skip it as evidence of a product flaw. The fixture was not executed against a target, and it found nothing.

The question I would actually put in CI

Which invariant belongs in CI, and which layer should enforce it?

I would put the three fixtures in CI, on the repo that owns the gate. I would not put production tickets in CI just to test a model. The laptop gate enforces the paste. The CI job enforces the gate. The model enforces neither.

Audit a Trace Slice Before a Model Explains the 500

jaryn — Fri, 09 Oct 2026 12:03:05 +0000

Checkout returned 500. The next message in the thread was the dangerous one: paste the trace, let the model explain it. I built that thread as a fixture, not from a customer ticket. Line three still has a session cookie and reset_token in the query string.

That is the trust-boundary violation. The model is not on the request path. The paste is. Why would I hand a session cookie to a system whose job is to echo, summarize, and sometimes retain?

I am not claiming a live incident, a bounty, or a vendor finding. What follows is an unexecuted template: a pre-send gate, two fixtures, and the failure evidence I want CI to demand. I have not run it against a production model, and I will not pretend I have.

Where the boundary actually sits

A trace slice has more than one owner. Forget the model for a second.

The app emitted the line.
The log pipeline stored it.
A human copied a window of it.
A model endpoint, or a helper server, received the copy.

Steps 1 and 2 can stay inside your trust zone. Step 4 often does not. A hosted model is someone else's process. A server you stood up because it was free is still a second machine, with disk, logs, and an admin path you may not have reviewed.

So the invariant is small. No secret-bearing field crosses step 4. Not in the prompt. Not in a file upload. Not in a "debug context" attachment.

Does a redaction regex make the model safe? No. It only stops the obvious paste. That is still the gate I want in front of the clipboard.

app  ->  log store  ->  human slice  ->  [pre-send gate]
                                          | deny: stop
                                          | allow: model or assistant server
raw slice stays in the incident store. It does not ride along.

Logs are the messy part. An access line, a span attribute, and a copied shell scrollback can all carry the same cookie under different names. If I only scrub the prompt box, the attachment still leaves. The gate has to see the bytes that would actually be sent.

What I refuse to send

I keep a deny list, not a hope list. If a field is on it, the slice does not leave.

Authorization, Proxy-Authorization, Cookie, Set-Cookie
Query keys such as token, reset_token, code, password, api_key
Connection strings (postgres://, mysql://, mongodb://, redis://)
Cloud key shapes (AKIA, ASIA) and PEM private-key blocks
Internal hostnames I have not explicitly allow-listed for that ticket

A stack trace without those fields is usually fine. A stack trace with a request dump is not. Would you paste the same bytes into a public gist? If the answer is no, the model does not get them either.

Headers are the obvious leak. Query strings are the one people defend. "It is just a reset link." It is a bearer credential with a question mark in front of it. Treat it that way.

Shell history is the third copy. curl -v output, kubectl describe, and a pasted .env diff are not "context." They are credential stores with worse retention than your vault. I do not attach them. I attach the redacted symptom: status, route, exception type, and the line number.

The fixture

Pinned assumptions, so this does not drift into folklore:

Language: Python 3.12, standard library only. No package pin, because there is no package.
Input: one JSON object, UTF-8, capped at 64 KiB in this template.
Contract: exit 0 only when the slice is already redacted; exit 2 on a hit; never print the secret value.
Status: unexecuted template. Expected evidence is specified below, not observed.

#!/usr/bin/env python3
"""pre_send_gate.py — unexecuted template. Not a scan result."""
import json, re, sys

DENY = re.compile(
    r"(?i)(authorization|proxy-authorization|cookie|set-cookie)\s*[:=]"
    r"|((?:reset_)?token|api_key|password|code)\s*[=:]\s*[^&\s]{6,}"
    r"|postgres(?:ql)?://\S+|mysql://\S+|mongodb(\+srv)?://\S+|redis://\S+"
    r"|\bAKIA[0-9A-Z]{16}\b|\bASIA[0-9A-Z]{16}\b"
    r"|-----BEGIN [A-Z ]*PRIVATE KEY-----"
)

def main() -> int:
    raw = sys.stdin.read(65536)
    if sys.stdin.read(1):
        print("reject: oversize", file=sys.stderr)
        return 2
    try:
        doc = json.loads(raw)
    except json.JSONDecodeError:
        print("reject: not-json", file=sys.stderr)
        return 2
    blob = json.dumps(doc, ensure_ascii=False)
    if DENY.search(blob):
        print("reject: secret-shaped field", file=sys.stderr)
        return 2
    print("allow: no deny-pattern hit")
    return 0

if __name__ == "__main__":
    raise SystemExit(main())

Short script. Narrow job. It does not call a model, and it must not grow a client "for convenience."

1. Negative fixture

Save this as fixtures/negative.json. It should fail closed. The values are synthetic. Do not replace them with real ones to "make the test better."

{
  "path": "/checkout",
  "status": 500,
  "request_headers": "Cookie: session=synthetic-session; Authorization: Bearer synthetic-demo",
  "query": "reset_token=synthetic-secret-value"
}

Expected, not observed: python3 pre_send_gate.py < fixtures/negative.json exits 2 and prints reject: secret-shaped field on stderr. The secret itself must not appear on stdout. If your run prints the cookie, the gate is an exfiltrator. Delete that print before you debug anything else.

2. Positive fixture

Save this as fixtures/positive.json. Same incident shape. Secret-shaped fields are dropped, not masked after the colon. This template treats Cookie: itself as a hit, so Cookie: <REDACTED> still fails. Good. Fail closed on the field, not on your confidence in the mask.

{
  "path": "/checkout",
  "status": 500,
  "headers_present": ["cookie", "authorization"],
  "query": "<REDACTED>",
  "error": "NullPointerException at CheckoutService.java:88"
}

Expected, not observed: exit 0 and allow: no deny-pattern hit. If the positive fixture still fails, the slice is not clean, or the pattern is broader than you thought. Do not weaken the regex to force a pass. That is how gates rot.

headers_present is the compromise I will allow. The model can know a cookie header existed. It cannot know the cookie. If you need the model to see a header name, put the name in a list. Never leave the colon-form in the blob.

3. Keep the model unreachable on failure

python3 pre_send_gate.py < fixtures/negative.json
test $? -eq 2 || echo "gate failed open"
python3 pre_send_gate.py < fixtures/positive.json && echo "human may paste this slice"

No model URL belongs in the failing branch. If I cannot show the exit code, I do not have a gate. I have a comment in a README.

Run this on Python 3.12 and keep the stderr next to the commit. A screenshot of a chat reply is not evidence. The exit code is.

Prevent, detect, recover

Phase	Control	What "done" means
Prevent	Deny-list gate before any paste or upload	Negative fixture exits 2; secret not echoed
Detect	CI job on the fixture pair, plus pipeline redaction	A green build cannot hide a failing negative
Recover	Rotate the credential, revoke the session, file the paste	Assume the recipient retained the bytes

Rotation is not optional once a negative slice has crossed the boundary. I cannot audit a recipient's retention from a chat transcript. Can you? Then do not bet the session on it.

Detect is where teams get lazy. They run the positive fixture, see allow, and call the control done. The negative fixture is the control. A gate that has never failed in CI has never been shown to work.

Where a free model and a free server fit

This is where a product can sit in the workflow, and also where a free tier makes a bad paste feel cheap.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The operator describes free model access and a free server option for MonkeyCode, an open-source AI development platform. I am not pinning a token quota, a model id, a hardware size, or a duration. Those figures move, and I do not have a primary source in this draft. A stale allotment would be worse than none.

Read the placement this way.

A free model is still an egress destination. Free does not mean inside your VPC. A free server is still a host. If you self-host the assistant there, you moved the process closer. You did not delete the boundary. Disk, shell history, and container logs on that box can retain the same cookie you refused to paste into a hosted chat.

The workflow does not change with the price tag.

Export the smallest slice that explains the 500.
Run the gate. A negative result stops the workflow.
Only the positive slice may enter a prompt, whether the endpoint is free, paid, or on a server you stood up this morning.
Keep the raw slice in the incident store. It does not ride along as extra context.

Would I send the negative fixture to a free tier just to see what the model says? No. The free tier is where casual paste happens, because the cost signal is gone. The security signal should not leave with it.

If you want to try that platform, read the live terms for the free model access and the free server option, then point only a redacted slice at it.

Limitations, and who should walk away

This regex is a fixture, not a DLP product. It misses split secrets, homoglyphs, values logged under a name I did not list, and secrets already copied into a stack message. It will also false-positive on docs that quote an Authorization: example, and the bare code alternative is deliberately broad. Fail closed anyway. A false positive costs a rewrite. A false negative costs a session.

Do not use this approach if any of these are true.

You handle regulated data, and even a redacted trace may not leave the zone.
You need attested coverage, key custody, or a vendor questionnaire. Forty lines of Python are not that.
Your team will bypass the gate when the model "needs more context." The bypass is the incident.
You came for a WAF rule, a deployment guide, or a mass-assignment fix. Different boundary.

I also did not execute the commands in this draft. If you adopt the fixture, run both files yourself and keep the exit codes next to the commit. An unrun template is a proposal. A captured exit code is evidence.

There is a second limitation I care about more than the regex. The gate does not know your business. An employee id, a medical record number, or an unlisted internal hostname can be sensitive and still sail through. Add those patterns locally. Do not wait for a generic list to grow a conscience.

What belongs in CI?

Which invariant belongs in CI, and which layer should enforce it?

I would put the fixture pair in CI. Negative must exit 2. Positive must exit 0. The job must not hold a model credential at all. The log pipeline, not the model client, should strip secret-shaped fields before a human can copy a window. CI proves the gate still fails closed. The pipeline proves the secret never became copyable.

If your CI job needs a live model key to "test the prompt," the boundary is already wrong. Fix that before you ask any model why checkout returned 500.

Audit a Prompt Bundle Before It Crosses a Model Trust Boundary

jaryn — Thu, 08 Oct 2026 09:10:39 +0000

A checkout 500 should have stayed a checkout 500.

Here is the sequence I use in reviews. It is a composite, not a customer postmortem, and I am not claiming a live finding. An on-call engineer exports the ticket, runs kubectl logs deploy/checkout --tail=200, and drops the last Terraform plan into ask.md. They hand that file to a coding assistant and ask why the payment call failed.

The answer comes back useful. The file does not. It still holds a customer email, a session-cookie fragment, and a Postgres DSN that survived the stack frame. Did anyone intend to send that? No. Did the trust boundary notice intent? Also no.

The invariant I want is smaller than a policy PDF. A prompt bundle either passes a deny fixture, or it does not leave the workstation.

Name the boundary before you name the model

I split the path into four zones. Your editor is zone 0. Ticket text and cluster logs are zone 1: still inside the company, still full of other people's data. A coding server you operate is zone 2. A remote model, including a free model path you do not host, is zone 3.

Zone 2 feels safe because you can see the disk. It is not automatically safe. If that server still forwards prompts, zone 3 is the real boundary. If the server logs full prompts, your own disk becomes a second copy of the secret.

Which copy do you rotate first? And who else can read zone 2 when you are asleep?

ticket/logs (zone 1) -> ask.md (zone 0)
        | deny fixture must fail closed here
        v
coding server you operate (zone 2)
        | if it proxies outbound
        v
remote model (zone 3)

Free hosting does not move those arrows. It only changes who pays for the box.

What I will not put in the bundle

I keep a short refuse list. If a line matches, the bundle is dead. I do not "just this once" it.

Connection strings, cloud access-key shapes, kubeconfig client-key-data, and private key blocks.
Session cookies, Authorization values, and one-time reset links, even when truncated.
Customer identifiers that are not already public: email, phone, account id, raw ticket body.
Production Terraform plans, database dumps, and kubectl output you have not scrubbed.
Another team's incident-channel paste. That is not your data to donate to a model.

A sanitized stack trace with file paths and line numbers? Fine. A failing unit test you wrote with fake data? Fine. The raw ticket? Not fine.

Would you paste that same file into a public gist? If the answer is no, a remote model is the wrong destination too.

Step 1. Pin the fixture, and label it unexecuted

This is an unexecuted template. I have not run it against a production corpus, and a green local run would not prove your logs are clean. Pin the interpreter. I wrote it for Python 3.12 stdlib only, so you are not pulling a scanner package you have not reviewed.

Save it as prompt_egress_gate.py.

#!/usr/bin/env python3
"""Unexecuted template. Fail closed before a prompt bundle leaves zone 0.

Target: Python 3.12 stdlib. Not a DLP product. Not evidence of a live leak.
"""
from __future__ import annotations

import re
import sys
from pathlib import Path

RULES: list[tuple[str, re.Pattern[str]]] = [
    ("private_key_block", re.compile(r"-----BEGIN [A-Z ]*PRIVATE KEY-----")),
    ("postgres_dsn", re.compile(r"postgres(?:ql)?://[^\s:]+:[^\s@]+@", re.I)),
    ("aws_access_key_shape", re.compile(r"\bAKIA[0-9A-Z]{16}\b")),
    ("bearer_header", re.compile(r"(?i)authorization:\s*bearer\s+\S+")),
    ("cookie_header", re.compile(r"(?i)\bcookie:\s*\S+=")),
    ("kube_client_key", re.compile(r"(?i)client-key-data:\s*\S+")),
    ("generic_secret_assign", re.compile(
        r"(?i)\b(?:password|secret|token)\s*[:=]\s*\S+"
    )),
    ("email_address", re.compile(
        r"\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b", re.I
    )),
]

def scan(text: str) -> list[str]:
    hits: list[str] = []
    for rule_id, pattern in RULES:
        if pattern.search(text):
            hits.append(rule_id)
    return hits

def main(argv: list[str]) -> int:
    if len(argv) != 2:
        print("usage: prompt_egress_gate.py <bundle>", file=sys.stderr)
        return 2
    path = Path(argv[1])
    hits = scan(path.read_text(encoding="utf-8", errors="replace"))
    if hits:
        print(f"DENY {path} rules={','.join(hits)}")
        return 2
    print(f"ALLOW {path}")
    return 0

if __name__ == "__main__":
    raise SystemExit(main(sys.argv))

Why fail on email? Because a support bundle without one is usually still debuggable, and a bundle with one is already customer data. Too blunt for a product DLP. Right bluntness for a lab gate.

You can delete that rule. Do not delete the DSN rule.

Step 2. Add a negative fixture that must fail

Negative means "this must not be sent." Use obvious fakes. Do not paste a real key just to see if the regex wakes up.

fixtures/negative_ticket.md:

Ticket 18422
Customer: alex@example.com
Stack: dial tcp: postgres://app:example-not-a-secret@db.internal:5432/app
Access key shape: AKIAEXAMPLEKEY000000
Request header: Authorization: Bearer example.not.a.real.token
Cookie: session=example-cookie-fragment

Expected evidence, once you actually run it:

python3.12 prompt_egress_gate.py fixtures/negative_ticket.md
echo "exit=$?"

I expect exit code 2 and a DENY line naming email_address, postgres_dsn, aws_access_key_shape, bearer_header, and cookie_header. If you get ALLOW, the fixture is wrong. Stop. Do not send the file while you "fix the regex later."

Step 3. Add a positive fixture that must pass

Positive means "this is the shape I am willing to send." No identifiers. No headers. A reconstructed failure only.

fixtures/positive_checkout.md:

Symptom: checkout returns 500 after the payment client times out.
Repro: unit test TestCheckoutTimeout uses host "payments.invalid" and cart id "cart_test_1".
Question: which retry belongs in the client, and which belongs in the worker?
Constraint: point at the interface. Do not propose a new store for credentials.

python3.12 prompt_egress_gate.py fixtures/positive_checkout.md
echo "exit=$?"

I expect exit code 0 and ALLOW. If the positive fixture trips generic_secret_assign, your wording is too close to an assignment. Rewrite the question. Do not weaken the rule to make the demo green.

Want a one-liner that fails the build when someone adds a third file? This wrapper is also an unexecuted template.

#!/bin/sh
# prompt-egress-check.sh — unexecuted template, Python 3.12
set -eu
root=${1:-fixtures}
fail=0
for bundle in "$root"/*.md; do
  python3.12 prompt_egress_gate.py "$bundle" || fail=1
done
exit "$fail"

Point it at a directory of synthetic bundles. Do not point it at ~/Downloads full of real tickets and call that a test.

Step 4. Decide the destination before you pick a server

This is the matrix I want in the review, not in a slide.

Data class	Local editor	Server you operate, no remote model	Remote model, including a free path
Synthetic failing test	Yes	Yes	Yes, after the gate
Scrubbed stack trace, no ids	Yes	Yes	Only if the gate is clean
Raw ticket or `kubectl` dump	Yes, on your laptop	No, unless the host is approved for that data	No
DSN, cookie, key, kubeconfig	Secret store only	No	No

A free server is still a server. Who else has SSH? Where do request bodies go? Is the prompt written to /var/log on every call? If you cannot answer those three, the host is not zone 2. It is an unreviewed copy of zone 3.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. The walkthrough uses that open-source coding platform as the lab example, not as proof that any host is safe.

The operator describes a free model path and a free server option. I am not stating model names, token quotas, hardware, or how long that offer lasts. A chat may quote a large free allowance. Read the current project page, and treat any secondhand number as stale.

If you stand up that server, put the gate in front of it. Do not aim it at production logs to see whether the model is clever.

Step 5. Prevent, detect, recover

Phase	Control	Evidence I want
Prevent	Run the gate on `ask.md` before any client upload. Exit 2 blocks the send.	Shell trace with `DENY` and rule ids
Detect	Alert if the coding server logs a request body, or if egress from zone 2 is not on an allowlist.	A log sample that shows bodies are dropped, plus one denied egress record
Recover	Rotate anything that already crossed. Rewrite from the positive fixture. Do not edit the leaked file in place and resend it.	A rotation ticket, not a hope that the vendor skips training

Training-opt-out language is not a recovery plan. If the DSN left, rotate the password. If the cookie left, revoke the session. If the email left, follow your incident path.

I would rather rotate a canary than argue about retention. Would a model vendor's policy page undo a password that already crossed? No.

What this gate will miss

Regex does not understand base64, gzip, or a screenshot of the same ticket. It will miss a secret split across two lines. It will also flag a design note that says token: and annoy you.

Good. Annoyance is cheaper than a leaked DSN.

Do not encode the bundle to slip past your own rule. That is how a lab gate becomes theater. And do not treat ALLOW as a legal review.

This is the wrong tool if you handle health data, payment card numbers, or a contract that bans third-party processors. A Python file on a laptop is not a control framework.

Who should skip the approach? Teams that already enforce egress DLP and a model gateway. Use that. Also skip it if your free server is a shared host whose admin you cannot name. You do not have a trust boundary then. You have a roommate.

One lab path, then stop

I keep the corpus synthetic: the two fixtures above, nothing pulled from the ticket system. A free model path is enough to check whether your client respects a failed gate. A free server is enough to check whether you can disable prompt logging and constrain egress.

Confirm both on the current project page before you write them into a runbook. Quotas and hardware change. A number you remember from a chat is not a control.

Which invariant belongs in CI, the deny fixture on every ask.md and ticket export? And which layer should enforce it: the workstation, the server you operate, or the egress proxy in front of the model? If you can only fund one, fund the layer that still runs when someone is tired. That is rarely the model.

Audit a Prompt Envelope Before CI Echoes the Match

jaryn — Thu, 08 Oct 2026 06:31:45 +0000

I still run the same drill before I let a log near a model. Staging migrate fails. The trace is short enough to paste, and one line is a database URL with a password sitting in it.

Would I notice that on a tired scroll? Sometimes. Would I notice it after the model already answered? Almost never. So the drill starts with a pause, not with a prompt.

I write the candidate text to a file on the laptop. The chat box stays empty. That empty box is the point.

Name the zones before you name the bug

A model call is not a local function. It is egress.

Who receives the bytes? The endpoint you called. Who might retain them? That provider, plus any attached server the model can use to read a repo or run a tool. Who else keeps a copy without being asked? Shell history, CI logs, and the teammate who re-runs your debug script with set -x still on.

I keep four zones written down. Laptop session, model endpoint, attached server, artifact store. If I cannot name the zone for a field, the field does not leave. A nameless field is how a quick paste becomes an incident.

laptop session
  |  envelope.txt          review here, before any paste
  |  no-echo gate          deny log gets rule id + offset only
  |
  +-- do not cross raw --> model endpoint
  |
  +-- do not cross raw --> attached server (disk, process list, logs)
  |
  +-- copies you forgot -> artifact store (CI, history, support bundles)

Does a free endpoint move those lines? No. Price is not a trust boundary. A zero invoice does not pull a remote process back inside your laptop.

A threat model, not a vibe check

I am not claiming a vulnerability in a vendor, and I am not publishing a finding. This is the invariant I want even when the log looks boring. Label the assets, then decide what a model is allowed to see.

Asset	Zone	If it leaves
Database URL with a password	laptop only	replay against whatever host the URL names
Bearer or session token	laptop only	the prompt holder holds the session
Private key block	laptop only	long-lived identity leaves with the paste
Customer identifier in a trace	laptop only until minimized	privacy incident, not just a leaked password
Internal hostname	laptop only by default	a map of the network, even with no password
SQLSTATE, error class, revision sha	model-allowed	high debugging value, low secret value

What about a stack trace? Useful, and filthy. Paths leak usernames. db.statement attributes leak query text. I strip both before I even run the gate, because the gate is a tripwire, not a parser for every telemetry SDK on earth.

Recovery is not a request to forget. If the bytes crossed, rotate the credential. Then ask what the endpoint and the server actually retain. A delete button on a transcript is a hope, and hopes are not controls.

What I refuse to send

I will not send connection strings. I will not send Authorization lines, cloud access-key ids, or a private-key banner. I will not send a raw span attribute map. That map is where http.request.header goes to hide.

I also will not send a file whose redaction tool printed the match into stdout. Think about that failure for a second. You blocked the model, then your CI log became the new envelope. Did you reduce exposure, or did you just change the sink?

Synthetic error text is fine. A SQLSTATE is fine. A revision sha is usually fine. A customer email is not, even when the explanation would land faster.

Faster is not the invariant I am enforcing. The model can be clever and still be the wrong recipient. Clever does not pull a field back across a zone line.

The no-echo fixture

What follows is an unexecuted template. I am not reporting a run against a live provider, and a local exit code would not prove an endpoint is safe. Target CPython 3.11 or newer. Standard library only, because I do not want a dependency install standing between me and a deny decision.

Positive fixture, fixtures/ok_trace.txt. This one should be allowed.

migrate failed
sqlstate=42P01
relation=invoices
revision=abc123
service=billing

Negative fixture, fixtures/bad_trace.txt. Both secrets are placeholders. Do not improve the test with a real one.

migrate failed
DATABASE_URL=postgres://app:example-not-a-real-secret@db.internal:5432/billing
password=example-not-a-real-secret
sqlstate=42P01

audit_prompt_envelope.py:

#!/usr/bin/env python3
"""UNEXECUTED TEMPLATE. Fail closed. Never print the matched secret."""

import re
import sys
from pathlib import Path

RULES = (
    ("conn_url", re.compile(r"(?i)\b(?:postgres|mysql|mongodb|redis|amqp)://\S+:\S+@")),
    ("aws_access_key_id", re.compile(r"\bAKIA[0-9A-Z]{16}\b")),
    ("private_key", re.compile(r"-----BEGIN (?:RSA |OPENSSH |EC )?PRIVATE KEY-----")),
    ("bearer", re.compile(r"(?i)\bbearer\s+[A-Za-z0-9._\-]{8,}")),
    ("assignment", re.compile(r"(?i)\b(?:api[_-]?key|secret|password|token)\b\s*[:=]\s*\S+")),
)

def audit(text: str) -> list[tuple[str, int]]:
    hits = []
    for rule_id, pattern in RULES:
        for match in pattern.finditer(text):
            hits.append((rule_id, match.start()))
    return hits

def main() -> int:
    path = Path(sys.argv[1])
    hits = audit(path.read_text(encoding="utf-8", errors="replace"))
    if not hits:
        print(f"allow path={path} rules=0")
        return 0
    for rule_id, offset in hits:
        print(f"deny rule={rule_id} offset={offset}")
    return 2

if __name__ == "__main__":
    sys.exit(main())

If you execute this later, the evidence you want is dull on purpose. Rule id, byte offset, and exit status. Not the URL. Never the URL.

# UNEXECUTED TEMPLATE. Intended contract, not an attached run.
python3 audit_prompt_envelope.py fixtures/ok_trace.txt
echo "exit=$?"
# intended: allow path=fixtures/ok_trace.txt rules=0
# intended: exit=0

python3 audit_prompt_envelope.py fixtures/bad_trace.txt
echo "exit=$?"
# intended: deny rule=conn_url offset=<n>
# intended: deny rule=assignment offset=<n>
# intended: exit=2

The allow path should print allow and exit 0. The deny path should print two deny lines, one for conn_url and one for assignment, then exit 2. I am describing the template's intended contract, not a run I am attaching as proof.

Why offset instead of the match? Because the next tool in the pipeline will archive stdout. Give it nothing it can reuse. If your CI plugin dumps the input file on failure, turn that dump off, or you rebuilt the leak with better intentions.

How I run the gate

None of these steps start in the chat box. If they do, you already crossed.

Write the candidate prompt to envelope.txt on the laptop. Do not paste it into a browser just to see. Pasting is the egress. The file is the review surface.
Run the template on fixtures/ok_trace.txt and require exit 0. A broken script that your shell ignores is fail-open. Look at $?. If the positive fixture fails, fix the gate before you trust a deny.
Run the template on envelope.txt. Exit 2 means stop. Exit 0 means these rules did not match. That is not a cleanliness certificate. Encoded secrets, split lines, and binary attachments walk right past this list.
Replace denied fields with placeholders such as <DB_URL> and <TOKEN>. Point at the local secret store in a note the model does not need. Do not write a line that says to ignore the secret above. You would already have sent it.
Re-run the gate on the rewritten file. Only an allow moves forward. Skipping this because you are tired? That is the leak window.
Send the minimized envelope, and only if you still need a model. Keep the original file off any attached server. If a tool runner wants a worktree, give it a scrubbed copy. Do not mount $HOME. Home directories collect .env files, cloud CLIs, and notes you forgot were secrets.
After the call, review history without reprinting lines. If a count is non-zero, rotate the credential, then chase retention. Detection without rotation is a diary entry.

# UNEXECUTED TEMPLATE. Count only, so this review does not echo a line.
# Point HISTFILE at your shell history first.
grep -cE 'postgres://|AKIA|BEGIN .*PRIVATE KEY' "$HISTFILE" || true

Where does this want to live? Step 3 belongs in CI for any job that uploads a prompt artifact. Step 6 belongs on the runner, because a hurried human will skip the script. Two layers, one invariant: credential-shaped strings do not cross, and the deny log does not become a second copy.

Where free capacity sits

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I am using only two product facts in this walkthrough. MonkeyCode has free model access, and it has a free server option. I am not naming models, token quotas, hardware, duration, or benchmarks. I have not pinned those here.

Read the current docs before you plan around either fact. Availability language goes stale. A blog post is a bad place to freeze it.

How do those two facts sit on the four zones? Free model access is still the model endpoint. The bytes leave your laptop. A free server is still an attached server: disk, process list, logs, and whatever debug bundle a support path might collect.

Free does not mean inside your VPC. It does not mean the logs are yours. It does not mean another tenant cannot meet a file you left in a shared workspace.

Would I point a raw deploy log at that server because the offer is free? No. I would point the scrubbed worktree from step 6 at it, and only after I have read whatever the project currently says about retention and tenancy. If those pages are silent, I assume retention I cannot bound, and I send less.

If you want a non-production place to exercise the minimized fixture, check MonkeyCode's current free model access and free server option, confirm retention in the docs you have today, and only then send an envelope that already passed the no-echo gate. That is the only invitation I am making. The gate still comes first.

Prevent, detect, recover

Phase	Control	Failure you should expect
Prevent	No-echo gate in CI, exit 2 on a rule hit	A wrapper that prints the source file on failure
Prevent	Scrubbed worktree, no `$HOME` mount	Tool runner inherits the developer environment
Detect	Offset-only deny lines, plus a count-only history check	`set -x` echoing a header you thought was local
Recover	Rotate, then chase retention	Deleting a chat and calling the incident closed

Regex misses base64, multiline splits, and the HAR file you attached because the UI made it easy. The assignment rule will also false-positive on the word token in ordinary prose, so tune it before you fail a pipeline on it. I am not describing a DLP product. I am describing a tripwire for shapes that show up in deploy logs.

If your only control is this file, you are not done. You have a regression test for one invariant. Treat a green exit as a narrow pass, not a security review.

Who should walk away

Do not use redact-and-send on production customer data, payment data, or anything under a retention duty you cannot waive. Minimizing is not a lawful basis. If the right action is do not send, an allow exit is irrelevant. Ignore it.

Do not treat a free server as an air gap. If policy says prompts stay on-box, a remote model is out. Full stop. Do not cite this template as evidence that a product is safe, or that a vulnerability exists. It does not scan a vendor. It scans a file you chose.

If your team needs a contractual deletion window, a named region, and a reviewed subprocessor list, stop at the docs. A tutorial gate does not finish that review. It does not even start it.

The question I would put in the retro

Which check belongs in CI, and which layer has to enforce it when CI is not on the path? I ask that in the retro, not in the prompt.

The no-echo deny belongs in CI. Artifact uploads are quiet, and they last. The rule against mounting home belongs on the runner, because that is where the extra files are. The model is a bad enforcement point for both.

By the time the model can see the string, the boundary is already behind you. So I audit the envelope before the call. I refuse to let the auditor reprint the match. And I treat free capacity as capacity, not as trust.

DEV Community: jaryn

Your Free Model Endpoint Keeps Logs — Build the Relay That Decides What They Say

The failing sequence, in five lines

Draw the boundary map before you write the code

Classify your data, then pick the action

Build the relay: 60 lines, standard library only

Fixtures: prove it blocks, and prove it doesn't

Standing it up on a free server

Prevent, detect, recover

What this does not do

Your Leaked Prompt Secret Has a Rotation Order — Compute It Before You Click Rotate

1. Map where the second copy lives

2. Write the graph before you write the runbook

3. Compute containment order, not just a rotation list

4. Handle the cycle honestly

5. Redact shapes, keep diagnostics

6. Prove the revocation, don't assume it

7. Rotate now versus watch

8. What free access changes, and what it does not

A twenty-minute drill you can run this week

Limitations and who should skip this

Before the First Prompt: A Data-Class Gate for Free-Tier Model Trials

Two modes, two boundaries (and one you have to verify yourself)

Step 1 — Write the ceiling down as a file, not a vibe

Step 2 — Classify the tree, and record a digest per file

Step 3 — Gate the manifest per mode

Step 4 — Build fixtures that must fail

Step 5 — Decide what actually crosses the line

Step 6 — Close the loop: deny, detect, recover

Where this breaks (and who shouldn't use it)

Build a Canary Regression Test for Model-Bound Webhook Data

The 02:14 ticket

The boundary is not the network

Step 1 — Classify data, not payloads

Step 2 — Project with a default-deny allowlist

Step 3 — Synthesize what the model needs to see

Step 4 — Two fixtures, not one

Step 5 — Run it against a model you are allowed to break

Step 6 — Detect, then recover

What this does not cover

Who should not use this

Default-Deny Egress Before Your Agent Meets a Free Model Endpoint

The threat model, in five lines

Two boundaries, and only one can see plaintext

Step 1 — Write the egress contract before you write the agent

Step 2 — Enforce destinations in the kernel

Step 3 — Enforce content where plaintext exists

Step 4 — Wire both layers into one gate

Decision table: what may cross which boundary

Where a free tier genuinely helps, and where it doesn't

Limitations and failure modes

Who should not use this

The boundary question

Build a Pre-Prompt Egress Ledger Before an Agent Reads Your Repo

1. The boundary moved. .gitignore never claimed to be a privacy control.

2. Turn "be careful" into four answerable questions

3. Step 1 — build the dirty fixture before you build the detector

4. Step 2 — write the ledger

5. Step 3 — run it and diff the exit codes

6. Step 4 — make the gate a dependency, not a habit

7. The prevent / detect / recover table

8. What not to send at all

9. Where the free tier actually fits

10. Limitations, and who should not use this

Which invariant belongs in CI?

Audit a Workspace Read Set Before an Agent Indexes It

Two boundaries, not one

What stays out of the index

Step 1. Pin the tools and the manifest

Step 2. Build the positive fixture

Step 3. Keep a negative fixture readable

Step 4. Run the gate as the agent uid

Step 5. Decide where the bytes are allowed to go

Prevent, detect, recover

Who should not use this

What this draft is not

Reproduce a WAF Sample Leak With a Never-Send Fixture

The failure mode is the paste

Trust boundaries, drawn small

What a blocked request quietly carries

1. The boundary moved. `.gitignore` never claimed to be a privacy control.