DEV Community: jaryn

Build a Set-Cookie Regression Fixture for HAR 1.2

jaryn — Thu, 24 Sep 2026 18:25:11 +0000

Say the login redirect is looping. I export a HAR from DevTools in this walkthrough because I want a second look at the status codes, and the reflex I am blocking is the paste into a model. I do not paste it.

The export is a transcript of a private channel. Search for Set-Cookie, Authorization, and csrf before you admire the timing waterfall. A session cookie, a CSRF field, and a bearer token on the token endpoint do not explain a 302. Pasting them is the trust-boundary violation. I can reproduce that class of mistake with a fixture. I am not describing a dated incident, and I am not claiming a vulnerability in any browser.

Would you still paste the file if the only question was why this 302 points back at /login? If the answer is no, the rest of this is the gate that makes no enforceable.

Trust boundaries, in order

I split the path into four zones, and I keep them in order on purpose.

The browser profile. Cookies, storage, and CSRF tokens live here.
The HAR file on disk. That is a copy, not a view, and copies get attached to tickets.
The redaction gate. It must fail closed.
The model context. It may see a fixture. It does not get the raw export.

Skip zone 3 and you already crossed the boundary. A model on your laptop still counts. Local does not mean unlogged. Have you checked whether the client writes prompts to a history file?

DevTools can omit sensitive headers at export time. People still "sanitize" a capture by deleting the hostname and leaving Cookie intact. That is a rename, not a redaction. Why keep a header the model cannot safely use?

browser profile
    |
    v
HAR file on disk ---- raw volume, model cannot mount
    |
    v
deny gate (fail closed)
    |
    +-- fail --> stop, no model
    |
    v
redacted sibling or positive fixture
    |
    v
model context, and any prompt log that context writes

Logs sit on that last hop. If the review process logs prompts, the log is another copy. A debug flag that prints the model request body will undo the gate. I would rather have a missing explanation than a prompt log that still contains a session cookie.

Fixtures, negative then positive

This template is unexecuted. I have not run it against a production capture, and nothing in this draft is evidence that a bug was found. If you run it later, assume Python 3.12 and jq 1.7, and pin those yourself. The values are canaries, not secrets. Do not drop the negative fixture into a public sample repo without the canary prefix.

Negative fixture, fixtures/har-negative.json. It should always fail the gate:

{
  "log": {
    "version": "1.2",
    "entries": [
      {
        "request": {
          "method": "POST",
          "url": "https://app.example.test/login",
          "headers": [
            {"name": "Cookie", "value": "session=CANARY_COOKIE_DO_NOT_SEND"},
            {"name": "X-CSRF-Token", "value": "CANARY_CSRF_DO_NOT_SEND"}
          ],
          "postData": {
            "mimeType": "application/x-www-form-urlencoded",
            "text": "password=CANARY_PASSWORD_DO_NOT_SEND"
          }
        },
        "response": {
          "status": 302,
          "headers": [
            {"name": "Set-Cookie", "value": "session=CANARY_SET_COOKIE_DO_NOT_SEND; HttpOnly"}
          ]
        }
      }
    ]
  }
}

Positive fixture, fixtures/har-positive.json. Same redirect story, nothing a session could be reused from:

{
  "log": {
    "version": "1.2",
    "entries": [
      {
        "request": {
          "method": "POST",
          "url": "https://app.example.test/login",
          "headers": [
            {"name": "Content-Type", "value": "application/json"}
          ],
          "postData": {
            "mimeType": "application/json",
            "text": "username=ada"
          }
        },
        "response": {
          "status": 302,
          "headers": [
            {"name": "Location", "value": "/login?error=1"}
          ]
        }
      }
    ]
  }
}

The positive file is the only shape I would hand a model. Method, path, status, one non-secret body field. That is enough to argue about a redirect loop. Need the cookie to reproduce the bug? Stay in a private debugger. Do not promote the cookie into a prompt so the model can "see what you see."

The gate, as numbered steps

Regex is a tripwire. It is not a proof that the file is clean. Say that out loud before you trust a pass.

Deny headers by name, not by vibe. Block Cookie, Set-Cookie, Authorization, Proxy-Authorization, X-CSRF-Token, and X-XSRF-TOKEN.
Scan postData.text and the URL query for password, access_token, refresh_token, client_secret, and the prefix CANARY_.
Fail closed when the file is not valid JSON. A truncated export is not "probably fine."
Write a redacted sibling. Never overwrite the source. You may still need the original offline, on a volume the model client cannot mount.
Only then may a model process open the sibling. If step 1 or 2 fired, stop. Do not ask the model to ignore secrets. It will not enforce that sentence.

Unexecuted checker. A sketch, not a scan result:

#!/usr/bin/env python3
"""Unexecuted template. Assumes Python 3.12. Not a scan of a live HAR."""
import json
import sys

DENY_HEADERS = {
    "cookie",
    "set-cookie",
    "authorization",
    "proxy-authorization",
    "x-csrf-token",
    "x-xsrf-token",
}
CANARY = "CANARY_"

def walk(node, hits):
    if isinstance(node, dict):
        name = str(node.get("name", "")).lower()
        if name in DENY_HEADERS:
            hits.append("header:" + name)
        for value in node.values():
            walk(value, hits)
    elif isinstance(node, list):
        for value in node:
            walk(value, hits)
    elif isinstance(node, str) and CANARY in node:
        hits.append("canary")

def main(path):
    try:
        data = json.loads(open(path, encoding="utf-8").read())
    except (OSError, json.JSONDecodeError) as exc:
        print("FAIL closed:", exc)
        return 2
    hits = []
    walk(data, hits)
    if hits:
        print("FAIL", ",".join(hits))
        return 1
    print("PASS")
    return 0

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

Expected evidence, once you actually run it: har-negative.json exits 1, and har-positive.json exits 0. I am not inventing a terminal transcript for a run I did not do. Keep the output beside the fixture version you pinned.

Pre-check I would run before the Python gate. Still not a substitute:

jq -r '.. | objects | .name? // empty' fixtures/har-negative.json | tr 'A-Z' 'a-z' | sort -u

If cookie or set-cookie shows up, stop. A second command, for the canary prefix:

rg -n "CANARY_|set-cookie|authorization" fixtures/har-negative.json

You want that search to hit on the negative fixture and miss on the positive one. If it misses on the negative fixture, your fixture is wrong, not clean. What were you about to send, exactly?

What I will not send

Even a box I administer does not get these raw values in a model prompt. Logs on that box are still a copy.

Field	Send raw?	Why I refuse	What I send instead
`Cookie` / `Set-Cookie`	No	Session material	Header name and value length
`Authorization`	No	Bearer or basic material	Scheme only, value removed
CSRF header or form field	No	Often paired with the cookie	Present or absent
Password in `postData`	No	Credential	Key present, value dropped
Query `access_token`	No	URLs leak into proxies and traces	Path only
Status, method, path, timing	Yes	Enough for a redirect question	Unchanged
`Content-Type`, cache headers	Usually	Low sensitivity	Keep, unless a token is embedded

"The agent never left the browser" is not a privacy property. The moment you export a HAR, copy a console dump, or let a tool read storage, the data has left the cookie jar. Did the tool result get logged? That is the same boundary, just with a different file extension.

Application logs are a separate paste. I am not opening that file here. If a log line and a HAR are in the same prompt, the HAR gate does not cover the log line. Run the same deny list on both, or send neither.

Prevent, detect, recover

Phase	Control	Failure you should expect
Prevent	Disable sensitive headers on export, then run the deny-header gate	Exit 1 on the negative fixture
Detect	CI on fixtures only; `CANARY_` must never pass	A green run on `har-negative.json` means the gate is broken
Recover	Rotate the session if a raw HAR was pasted; delete model history if the product allows it	An incident note with the time of the paste, not a second copy of the cookie

Recovery is rotation and deletion. It is not a smarter prompt. If the cookie already crossed, the transcript is evidence. Pasting it again while you clean up is a second leak. How fast is your session revocation, really? Do not assume it is instant.

After the gate, a review step you control

I still want help reading a redacted redirect trace. That is a fair use of a model. An unredacted HAR is not.

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

MonkeyCode is an open-source AI development platform. I would use it for the review step after the gate, not as a place to drop the export and hope. The brief for this article states that free model access and a free server option are available, and it described the free token allowance as 10 million. I am not treating that figure as a verified live quota. No primary offer page was attached here, and allowances move. A stale number is worse than none. Confirm the live token cap, duration, model list, and server terms on the project page before you plan a workload around them.

What I care about is placement. Keep the pre-redaction HAR on a volume the model process cannot mount. Mount only the positive fixture or a redacted sibling. A free server does not relax that invariant. It only changes where the review process runs, which is useful if you do not want the redacted trace leaving a machine you administer. Free access is not a reason to skip the gate. If the current free path does not fit a security-review workload, use a path that does, or run the gate with no model at all. The gate is the article. The model is optional.

Who should not use this approach? If a tested DLP proxy already sits in front of every model route, do not replace it with a short script. If the capture holds regulated health or payment data, a canary gate is not a compliance program. If you need the raw Set-Cookie to debug, stay in a private debugger.

Limitations, so this cannot be quoted as a finding. I did not execute the checker in this draft. A header deny list misses tokens under custom names such as X-App-Session. Base64 and compressed bodies sail past a string search. I assumed HAR 1.2; other exports differ. A pass means these fixtures behaved as specified. It does not mean a live file is safe.

Which layer should enforce it?

Which invariant belongs in CI, and which layer should enforce the live block? I put the canary regression in the fixture repo, so a helpful redactor cannot silently start passing Cookie. I put the export block on the workstation, before any model client starts. The model host is the wrong place to discover that the cookie was still in the file.

Start the next HAR debugging session from the negative fixture. Did the gate fail closed? If it did not, you are not ready to ask a model anything.

Audit logging.exception Before a Model Sees Your Authorization Header

jaryn — Wed, 23 Sep 2026 16:05:13 +0000

I reconstructed a 500 I keep seeing in incident channels. A client called GET /orders/not-an-id with a session token. FastAPI raised ValueError. The exception handler logged dict(request.headers) “for context.”

I copied the traceback into a model chat. Why? Because int("not-an-id") looked like a one-line fix. The paste also contained Authorization: Bearer test-token-do-not-use. The model did not need that header. My log pipeline never stopped it.

That is the trust-boundary violation. The failing request already happened. The privileged action is the next paste.

What actually crossed the boundary

Logs are not a scratch pad. They are an egress path.

Once a header lands in stdout, it can move to a file, a log shipper, a Slack thread, an agent tool result, or a model context window. Do you redact in the worker, or do you hope someone notices a token in frame 7?

I treat this as three boundaries, not one:

Request vs process. Headers belong to the HTTP connection. The app may read Authorization to authenticate. It must not serialize that value into a LogRecord.
Process vs log sink. stdout, journald, and your aggregator are a different trust domain. Whoever can read the sink can replay the session.
Log sink vs model. A paste or a tool call is a fourth party. Self-hosted or not, the model runtime is not your authorization layer.

The invariant I want in CI is boring: captured exception text must not contain Authorization, Cookie, or Bearer.

This is a constructed lab, not a CVE against FastAPI. I did not find a vendor bug. I reproduced a handler anti-pattern that turns a 400 into a credential disclosure the moment a human—or an agent tool—forwards stderr.

[Client] -- Authorization --> [FastAPI worker]
                                  | logging.exception(..., dict(request.headers))
                                  v
                              [stdout / journal]
                                  | human paste / agent tool result
                                  v
                              [Model context]

Redaction belongs in the worker. The chat window is not a control.

Lab pin (unexecuted until you run it)

Pinned for the fixture, not a production endorsement:

Python 3.12
fastapi==0.115.6
pytest==8.3.4
httpx==0.28.1

python -m venv .venv
source .venv/bin/activate
pip install 'fastapi==0.115.6' 'pytest==8.3.4' 'httpx==0.28.1'

If your resolver floats Starlette, freeze the lockfile before you trust the assertion. Label the next blocks as a lab recipe until pytest is green on your machine.

Negative fixture: the leak

Save as app_leaky.py. This handler is the failure I want the test to catch.

# app_leaky.py — lab fixture, constructed leak
import logging
from fastapi import FastAPI, Request

logging.basicConfig(level=logging.INFO)
log = logging.getLogger("orders")

app = FastAPI()

@app.middleware("http")
async def log_headers_on_error(request: Request, call_next):
    try:
        return await call_next(request)
    except Exception:
        log.exception("handler failed headers=%s", dict(request.headers))
        raise

@app.get("/orders/{order_id}")
async def get_order(order_id: str):
    return {"order_id": int(order_id)}

The request that should fail. The token is fake on purpose.

# Unexecuted until you run it.
curl -sS -D - \
  -H 'Authorization: Bearer test-token-do-not-use' \
  http://127.0.0.1:8000/orders/not-an-id

Expected failure evidence: process logs contain Bearer test-token-do-not-use next to the traceback. If you paste that stderr into a model, the token went with it. That is the whole bug.

Uvicorn access logs are a side path, not the main one. Default access format prints method, path, and status. The dangerous line is the one you added: dict(request.headers) inside logging.exception.

Look at the extra dict. %s plus a header map is how secrets survive a “harmless” stack trace. log.exception already includes the traceback. You do not need the header dump. You wanted a request id. You shipped a replay handle instead.

Positive fixture: redact before getMessage()

A logging.Filter runs in-process, before handlers write. That is the right layer.

# redact.py
import logging
import re

HEADER_RE = re.compile(
    r"(?i)\b(authorization|cookie|set-cookie|x-api-key|x-auth-token)\b\s*[:=]\s*\S+"
)
BEARER_RE = re.compile(r"(?i)\bBearer\s+\S+")

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

def scrub(text: str) -> str:
    text = HEADER_RE.sub(lambda m: m.group(1) + "=[REDACTED]", text)
    return BEARER_RE.sub("Bearer [REDACTED]", text)

class HeaderRedactFilter(logging.Filter):
    def filter(self, record: logging.LogRecord) -> bool:
        record.msg = scrub(str(record.msg))
        if record.args:
            if isinstance(record.args, dict):
                record.args = {k: _scrub_obj(v) for k, v in record.args.items()}
            else:
                record.args = tuple(_scrub_obj(a) for a in record.args)
        headers = getattr(record, "headers", None)
        if isinstance(headers, dict):
            record.headers = {
                k: "[REDACTED]" if k.lower() in DENY_HEADERS else v
                for k, v in headers.items()
            }
        return True

def _scrub_obj(value):
    if isinstance(value, str):
        return scrub(value)
    if isinstance(value, dict):
        return {
            k: "[REDACTED]" if str(k).lower() in DENY_HEADERS else _scrub_obj(v)
            for k, v in value.items()
        }
    return value

Wire it once, at process start, on the root logger and on uvicorn / uvicorn.access if you customize those. Installing it only on orders will miss a library that logs the request object.

# app.py
import logging
from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
from redact import HeaderRedactFilter

logging.basicConfig(level=logging.INFO)
for name in ("", "orders", "uvicorn", "uvicorn.access"):
    logging.getLogger(name).addFilter(HeaderRedactFilter())

log = logging.getLogger("orders")
app = FastAPI()

@app.exception_handler(ValueError)
async def value_error_handler(request: Request, exc: ValueError):
    # Path and request id only. Not the header map.
    log.warning("invalid order_id path=%s", request.url.path)
    return JSONResponse({"detail": "invalid order_id"}, status_code=400)

@app.get("/orders/{order_id}")
async def get_order(order_id: str):
    return {"order_id": int(order_id)}

Notice the handler logs the path, not the header map. The filter is defense in depth. It is not permission to dump request.headers again. If a reviewer asks “why not log everything and redact later?”, the answer is encodings. Regex will miss the second copy.

Regression tests that fail closed

test_redact.py is the artifact I actually want in CI. Positive and negative. If the negative test starts passing without the leaky logger, the harness is lying.

# test_redact.py
import logging
from redact import HeaderRedactFilter, scrub

def test_scrub_removes_bearer():
    raw = "handler failed headers={'authorization': 'Bearer test-token-do-not-use'}"
    assert "test-token-do-not-use" not in scrub(raw)
    assert "Bearer [REDACTED]" in scrub(raw)

def test_filter_redacts_logrecord_args(caplog):
    logger = logging.getLogger("orders_test")
    logger.setLevel(logging.INFO)
    logger.addFilter(HeaderRedactFilter())
    with caplog.at_level(logging.INFO, logger="orders_test"):
        logger.info("headers=%s", {"Authorization": "Bearer test-token-do-not-use"})
    text = caplog.text
    assert "test-token-do-not-use" not in text
    assert "REDACTED" in text

def test_negative_raw_logger_still_leaks(caplog):
    """Guard the guard. If this fails, caplog is not capturing what we think."""
    logger = logging.getLogger("orders_leaky")
    logger.setLevel(logging.INFO)
    with caplog.at_level(logging.INFO, logger="orders_leaky"):
        logger.info("headers=%s", {"Authorization": "Bearer test-token-do-not-use"})
    assert "test-token-do-not-use" in caplog.text

Run:

pytest -q test_redact.py

Expected: three passed. The third test documents the leak. Do not “fix” it by adding the filter to orders_leaky. You want that assertion to stay red-team honest.

Optional grep gate on fixture output, after you capture a real 500:

# Unexecuted template. Fail the job on a leftover credential shape.
rg -n -i -e 'Bearer ' -e 'authorization=' -e 'cookie=' captured-logs/ && exit 1 || true

Threat model

Asset	Trust boundary	Failure mode	Impact if a model sees it
`Authorization` bearer	App → log → paste/tool	`log.exception(..., dict(request.headers))`	Session replay against the API
`Cookie` / `Set-Cookie`	Same	Same	Session replay, CSRF token theft
`X-Api-Key`	Same	Gateway key in middleware logs	Service impersonation
Query `?token=`	Access log path	Token in URL	Replay; also Referer leaks
User email in path	Path in traceback	`/users/ada@example.com`	PII in model logs
Internal `Host` / kube DNS	Error page / traceback	Cluster layout	Recon, not credentials

I do not treat “the model promised not to train on it” as a control. Promises are not invariants. Tool calling makes this worse, not better: the same dump can re-enter context as a tool result without anyone clicking paste. Who owns that hop in your harness?

Prevent / detect / recover

Stage	Control	Evidence it works
Prevent	Never log `request.headers` or `request.cookies`. Log path, status, `X-Request-ID` only.	Code search + review
Prevent	`HeaderRedactFilter` on root and uvicorn loggers	`test_filter_redacts_logrecord_args`
Detect	CI `pytest` plus a grep gate on captured fixture logs	Job fails on `Bearer`
Detect	Gateway already authenticated the client; the app must not re-emit the secret	Architecture review
Recover	Rotate the token, invalidate the session, treat the paste as disclosure	Incident ticket
Recover	If the dump already left the network, rotate first, argue about the model vendor second	Time-to-revoke < time-to-debate

Regex will miss encodings. Base64 of the header, split tokens, Authorization%3A%20Bearer, Unicode lookalikes. The filter is a seatbelt. The real prevent control is: do not put the header map in the log call.

What I still will not send a model

Even after redaction, I keep a deny list for pastes:

Canonical request dumps with bodies (password=, otp=)
Set-Cookie and session IDs in any form
Connection strings, even “expired”
Customer email, phone, government IDs in paths or payloads
Internal signed URLs
Full repr(request) / Starlette Headers objects
Other users’ data that happened to be in the same traceback

If the remaining text is only ValueError: invalid literal for int() with base 10: 'not-an-id' plus a path /orders/{id}, that is enough for a model. Anything else is curiosity, not debugging. Ask yourself: would I put this string in a public GitHub issue? If no, it does not belong in a prompt.

Where a self-hosted workspace actually fits

Redaction is the control. Location is residual risk.

If you still want a model to read the sanitized stack, do not confuse “our GPU” with “safe to dump secrets.” A self-hosted runtime still has operators, swap, crash dumps, and prompt logs. I use it only after the filter and the deny list.

MonkeyCode is an open-source AI development platform. The two availability options that matter for this workflow are free model access and a free server, so a trial does not have to begin by shipping exception text to a third-party inference API. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

That is optional. The pytest file is not. If you already gate logs in CI, you do not need a new product to enforce the invariant.

Who should not use this approach

Teams that will treat regex redaction as a license to log request.headers again.
Anyone pasting live production dumps—including into a laptop LLM—without rotating the credential that appeared.
Pipelines that forward raw stdout to an agent tool. The tool result is another model ingress. Filter before the tool, not after the chat.
Orgs without session revocation. Detection without recover is a diary.

Limitations

I have not claimed a production breach. The leaky middleware is a fixture. FastAPI and Uvicorn versions drift; pin them.

logging.Filter will not see writes that bypass logging: print(request.headers), traceback.print_exc() to a custom file, OpenTelemetry span attributes, or an APM agent that captures request headers by default. If you enable header capture in a tracing SDK, this pytest will stay green and you will still paste a token. Extend the same deny list to span processors, or disable header capture.

Access logs that include query strings need a separate test. This article does not cover HAR files, container env dumps, Terraform state, or WAF 403 bodies. Those are different sinks. Same invariant, different fixture.

Boundary question

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

I want no Bearer in captured exception text as a pytest gate on every service that handles Authorization. The worker enforces it with a filter and by not logging headers. The model is not a control plane. If a sanitized stack still leaves the machine, that is a separate decision about residual recon data—not a reason to skip the fixture.

Reproduce a Bearer Token Replay From a curl -v Fixture

jaryn — Tue, 22 Sep 2026 14:22:13 +0000

The internal billing API returned 401. I needed a second pair of eyes, so I pasted the full curl -v transcript into the agent and asked why the token was rejected.

That paste still contained Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.... The model did not need the credential to explain a 401. The next tool call might. Conversation logs definitely would.

So the invariant is not "the model promised not to leak." It is this: verbose HTTP debug never crosses into model context until hop-by-hop credential headers are stripped. A gate. Not manners.

The trust boundary you actually crossed

A 401 debug session looks harmless. Status line, JSON error body, maybe a WWW-Authenticate challenge. Then you add -v and you have moved a live secret across four principals at once.

[operator shell] -- curl -v stderr --> [clipboard / paste]
        |                                      |
        v                                      v
[tool result channel] ------------------> [model context]
        |                                      |
        v                                      v
[prompt / response logs]                 [next tool arguments]

Which of those layers is allowed to see Authorization? Only the shell that already held the token. Everything after that is a different principal. Ask yourself: if the agent later calls write_file or http_request, is the bearer still in-window? If your telemetry stores prompts, did you just persist a live token next to a "why is this 401" question?

I treat the rest of this article as a fixture walkthrough, not a claim that I found a production breach. Synthetic values only. Pinned tools for the commands below: curl 8.11.1, Python 3.12.

What curl -v actually emits

Useful parts of a 401: the path, the status, the error body, the challenge. Not useful: the request header that proves you already had the secret.

* Connected to billing.internal (10.1.2.3) port 443
> GET /v1/invoices HTTP/1.1
> Host: billing.internal
> Authorization: Bearer FAKESECRET_g2h3i4j5k6l7m8n9o0p1
> User-Agent: curl/8.11.1
> Accept: application/json
>
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Bearer error="invalid_token"
< Content-Type: application/json
{"error":"token expired"}

Same class of leak, different names: Cookie, Proxy-Authorization, X-Api-Key, X-Amz-Security-Token, X-Auth-Token. If your agent wraps curl, httpie, or a generated SDK client with debug logging, you are in this threat model even when nobody "pastes" anything. The tool-result channel is the paste.

Fixtures first: one must block, one must pass

I keep two files under fixtures/http-verbose/. If a scanner cannot tell them apart, you do not have a control. You have a regex you hope is lucky.

Positive fixture (must-block.txt) — expected: exit 2, hit on Authorization.

> GET /v1/invoices HTTP/1.1
> Host: billing.internal
> Authorization: Bearer FAKESECRET_g2h3i4j5k6l7m8n9o0p1
> User-Agent: curl/8.11.1
< HTTP/1.1 401 Unauthorized
{"error":"token expired"}

Negative fixture (must-pass.txt) — expected: exit 0. The 401 body and the challenge stay. No credential header.

> GET /v1/invoices HTTP/1.1
> Host: billing.internal
> User-Agent: curl/8.11.1
> Accept: application/json
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Bearer error="invalid_token"
{"error":"token expired"}

The canary JWT is the point. It must never be a production token. If that exact string later appears in a tool argument or a prompt log, the boundary failed even if a human "redacted" the first paste by eye.

Numbered workflow: capture, scan, strip, prompt, prove

1. Capture the dump without widening the blast radius

Write stderr to a file. Do not pipe it straight into the agent.

curl -sS -D - -o /tmp/body.json -v \
  -H "Accept: application/json" \
  -H "Authorization: Bearer ${BILLING_TOKEN}" \
  https://billing.internal/v1/invoices \
  > /tmp/billing-401.headers 2> /tmp/billing-401.verbose

${BILLING_TOKEN} already lived in the shell. The file /tmp/billing-401.verbose is the new copy. Treat it like a secret until the gate says otherwise.

2. Scan with a boring, deterministic gate

Label: local scanner, not an LLM classifier. I want it dull enough to put in CI.

#!/usr/bin/env python3
"""http_verbose_gate.py — fail closed on hop-by-hop secrets in HTTP dumps."""
from __future__ import annotations

import re
import sys
from pathlib import Path

BLOCK = re.compile(
    r"(?im)^(?:[<>*]\s+)?(?:"
    r"authorization|proxy-authorization|cookie|set-cookie|"
    r"x-api-key|x-amz-security-token|x-auth-token"
    r")\s*:",
)
BEARER = re.compile(r"(?i)\bBearer\s+[A-Za-z0-9._\-+=/]+")

def scan(text: str) -> list[str]:
    hits = []
    for i, line in enumerate(text.splitlines(), 1):
        if BLOCK.search(line) or BEARER.search(line):
            hits.append(f"L{i}: {line.strip()[:80]}")
    return hits

def main(argv: list[str]) -> int:
    if len(argv) != 2:
        print("usage: http_verbose_gate.py <dump.txt>", file=sys.stderr)
        return 2
    text = Path(argv[1]).read_text(encoding="utf-8", errors="replace")
    hits = scan(text)
    if hits:
        print("BLOCKED: verbose HTTP dump still contains credential headers")
        print("\n".join(hits))
        return 2
    print("PASS: no hop-by-hop credential headers")
    return 0

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

python3 http_verbose_gate.py fixtures/http-verbose/must-block.txt; echo exit:$?
# expected: BLOCKED, L3 Authorization, exit 2

python3 http_verbose_gate.py fixtures/http-verbose/must-pass.txt; echo exit:$?
# expected: PASS, exit 0

If must-block.txt ever exits 0, the fixture is the regression. Do not negotiate with it.

3. Strip, then rebuild the prompt from the 401 body only

python3 - <<'PY'
from pathlib import Path
import re, sys
src = Path("/tmp/billing-401.verbose").read_text(encoding="utf-8", errors="replace")
block = re.compile(
    r"(?im)^(?:[<>*]\s+)?(?:authorization|proxy-authorization|cookie|set-cookie|x-api-key|x-amz-security-token|x-auth-token)\s*:.*\n?"
)
redacted = block.sub("> Authorization: Bearer [REDACTED]\n", src)
redacted = re.sub(r"(?i)Bearer\s+[A-Za-z0-9._\-+=/]+", "Bearer [REDACTED]", redacted)
Path("/tmp/billing-401.redacted").write_text(redacted, encoding="utf-8")
print("wrote /tmp/billing-401.redacted")
PY
python3 http_verbose_gate.py /tmp/billing-401.redacted; echo exit:$?
# expected: PASS after strip; if still BLOCKED, do not prompt

Now the model gets the status line, the challenge, and {"error":"token expired"}. It does not get the bearer. That is the whole product of this workflow.

4. Prompt on the redacted side of the boundary

Unexecuted template — fill in your own completion endpoint:

# template, not executed against a public chatbot
printf '%s\n' \
  "Explain this 401. Do not request credentials. Headers are redacted." \
  "---" \
  "$(cat /tmp/billing-401.redacted)" \
  "---" \
  "$(cat /tmp/body.json)" > /tmp/prompt.txt

If you cannot explain a 401 without the original Authorization line, the model is not the right debugger. The token was already rejected. The body is the evidence.

5. Prove the canary did not replay

After the turn, scan downstream artifacts, not just the input dump.

CANARY='eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.CANARY_NOT_A_SECRET'
grep -R --line-number -F "$CANARY" \
  /tmp/prompt.txt \
  /var/log/agent/ \
  ./tool-args.json \
  && echo "BOUNDARY FAIL: canary replayed" && exit 2
echo "canary absent from prompt, logs, and tool args"

No canary check means you only proved the first file was redacted. You did not prove the agent failed to re-emit it.

Threat model, in one table

Boundary	Secret that should stop	Failure mode	Evidence I accept
Shell → file	Bearer in `curl -v` stderr	Engineer pastes verbose output	`must-block.txt` exits 2
File → model	Same header after "please debug"	Tool result concatenated into context	gate on the prompt blob
Model → next tool	Canary JWT in arguments	Agent retries the API "with the token it saw"	grep on tool-arg JSON
Model → logs	Bearer in prompt store	SaaS or self-hosted telemetry keeps transcripts	SIEM hit on `Bearer eyJ`

Prevent / detect / recover is not a slogan. It is three different owners.

Layer	Prevent	Detect	Recover
Operator shell	Do not alias debug `curl` into the agent stdin	Too late once it is on the clipboard	Rotate the token; you cannot unpaste
Tool result channel	Strip hop-by-hop headers before completion	Gate exit 2 fails the turn	Retry with 401 body only
Model context	Never ask for "full verbose output"	Canary JWT in the positive fixture	Wipe the conversation; invalidate the canary
Telemetry	Prompt logs deny `Authorization` / `Bearer`	Alert on `Bearer eyJ` in agent logs	Treat the log store as a secret incident

What this gate is not

This does not make kubectl get secret -o yaml a safe tool. It does not parse HAR, docker inspect Env, or terraform state. Those encodings are out of scope here. A header regex will also lose to base64 -w0, to split lines, to HTTP/2 binary dumps, and to gRPC traces. Label those as uncovered.

It does not stop a model from requesting a secret. If the harness already injects BILLING_TOKEN into an exec tool, the credential is on the wrong side of the boundary before any dump exists. Result redaction is a backstop, not a permission model.

Who should not use this as their only control? Anyone whose agent has unrestricted exec. Anyone who thinks a 30-line scanner replaces allowlisted tools. Anyone about to paste a real 401 transcript into a public chatbot "just this once" because the gate passed on a fixture.

Where a self-hosted completion path actually participates

I still want a model to explain the 401. I do not want that paste in a third-party prompt log I do not control.

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

MonkeyCode is an open-source, self-hosted AI development platform. For this workflow two operator-supplied facts matter: free model access, and a free server option. That lets the "explain this 401" loop hit a completion endpoint on your side of the diagram above. The gate still runs before the prompt is built. The product does not replace the fixture, and it does not change which headers are forbidden.

If you already self-host a coding agent, put http_verbose_gate.py in front of the tool-result path and add the two fixtures to CI. That is the only ask.

Limitations I will not paper over

Expected evidence is exit codes on must-block.txt and must-pass.txt. I have not executed this against your billing API.
Free model access and a free server option only change which network the remaining prompt crosses. They do not make verbose dumps safe.
ASCII header matching is the scope. Binary protocol dumps need a different parser; do not pretend this one works there.
Synthetic JWTs in fixtures must never have been production tokens. Rotate anything that touched a real dump.

Which invariant belongs in CI? The positive/negative pair, every commit that touches the agent harness. Which layer should enforce it? The tool-result channel — not the model's manners, and not a human remembering to edit the paste.

Audit docker inspect Env Before a Model Sees the Connection String You Leaked

jaryn — Mon, 21 Sep 2026 12:34:01 +0000

Last Tuesday a worker refused to talk to Postgres. I did what every on-call engineer does without thinking.

docker inspect api-worker --format '{{json .Config.Env}}'

The JSON came back with DATABASE_URL=postgres://app:CANARY_PASSWORD@db.lab.internal:5432/app sitting next to JWT_SECRET=lab-only-not-a-real-key. I needed a second pair of eyes. My cursor was already in a chat box.

That is the trust-boundary violation. Not a CVE. Not a clever jailbreak. Just a runtime dump about to leave the host.

Would you paste that blob into a remote model? I almost did. The rest of this article is the gate I now run first.

The failing sequence

Label this a lab reconstruction, not a production incident. I did not find a live credential in the wild. I built a fixture that fails on purpose.

A container starts with connection strings in Config.Env.
docker inspect serializes those values as plain JSON strings.
An engineer pastes the dump into a coding model because the error message is useless.
The model now holds a password, a JWT signing secret, and the internal hostname.
Logs, chat history, and any provider-side retention sit outside the cluster's trust boundary.

The inspect API is not the bug. The missing invariant is: runtime Env never crosses a model boundary in the clear.

Trust boundaries, not vibes

Draw the lines before you argue about tools.

flowchart LR
  subgraph host [Container host]
    Dump["docker inspect JSON"]
    Gate[Env classifier]
  end
  subgraph remote [Remote free-model access]
    Redacted[Redacted question only]
  end
  subgraph local [Self-hosted coding server]
    Raw[Raw dump stays here]
  end
  Dump --> Gate
  Gate -->|no residual secrets| Redacted
  Gate -->|secret still present| Raw

Three boundaries matter:

Host runtime. docker inspect is privileged-adjacent. Anyone who can inspect can often exec.
Prompt channel. A remote model is a third party, even when the quota is free.
Workspace disk. A self-hosted coding server still writes prompts, diffs, and tool output to disk. Disk is not "safe." It is a different failure domain.

If you cannot name which layer enforces the invariant, you do not have an invariant. You have a habit.

What not to send

I treat Config.Env as secret-by-default. Names lie. NODE_ENV=production is boring. APP_KEY is not. DEBUG=1 is boring until it is DEBUG_TOKEN.

Do not send these to a remote model, even "just to parse JSON":

URLs with userinfo (postgres://, mysql://, redis://, amqp://, mongodb://)
*_SECRET, *_TOKEN, *_PASSWORD, *_PRIVATE_KEY, *_API_KEY
PEM blocks and BEGIN markers
JWT-shaped strings (eyJ prefix, two dots)
Cloud-shaped access keys and session tokens
Cookie headers, Authorization values, webhook URLs with path secrets

Topology leaks still hurt after redaction. db.prod.internal:5432 plus the app name is often enough to aim the next phish. Redact values. Then ask whether the keys and hostnames still belong off-box.

Lab fixture (unexecuted template)

Pinned assumptions: Docker inspect JSON with .Config.Env as a list of KEY=VALUE strings. Python 3.12. Patterns below are lab defaults, not a detection product.

Positive fixture — must fail the gate:

{
  "Config": {
    "Env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
      "NODE_ENV=production",
      "DATABASE_URL=postgres://app:CANARY_PASSWORD@db.lab.internal:5432/app",
      "JWT_SECRET=lab-only-not-a-real-key"
    ]
  }
}

Negative fixture — must pass after allowlisting non-secret keys:

{
  "Config": {
    "Env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
      "NODE_ENV=production",
      "LANG=C.UTF-8"
    ]
  }
}

Expected failure evidence: exit code 2, stderr containing DATABASE_URL and JWT_SECRET, no raw password on stdout.

#!/usr/bin/env python3
"""Lab gate: refuse docker inspect Env that still holds secrets."""
from __future__ import annotations

import json
import re
import sys
from pathlib import Path

SECRET_NAME = re.compile(
    r"(SECRET|TOKEN|PASSWORD|PASSWD|PRIVATE_KEY|API_KEY|ACCESS_KEY|CREDENTIAL)$",
    re.I,
)
SECRET_VALUE = re.compile(
    r"(://[^\s:]+:[^\s@]+@)|(\beyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.)|(BEGIN [A-Z ]+PRIVATE KEY)",
    re.I,
)
ALLOW_NAME = {"PATH", "LANG", "HOME", "TERM", "NODE_ENV", "PYTHONUNBUFFERED"}

def parse_env(pairs: list[str]) -> dict[str, str]:
    out: dict[str, str] = {}
    for item in pairs:
        if "=" not in item:
            continue
        key, value = item.split("=", 1)
        out[key] = value
    return out

def findings(env: dict[str, str]) -> list[str]:
    hits: list[str] = []
    for key, value in env.items():
        if key in ALLOW_NAME:
            continue
        if SECRET_NAME.search(key) or SECRET_VALUE.search(value):
            hits.append(key)
    return hits

def main() -> int:
    payload = json.loads(Path(sys.argv[1]).read_text())
    env = parse_env(payload["Config"]["Env"])
    hits = findings(env)
    if hits:
        print("FAIL: secret-bearing Env keys:", ", ".join(hits), file=sys.stderr)
        return 2
    redacted = {k: ("<redacted>" if k not in ALLOW_NAME else v) for k, v in env.items()}
    json.dump({"ok": True, "env": redacted}, sys.stdout, indent=2)
    print()
    return 0

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

Wrapper I keep next to the script:

#!/usr/bin/env bash
set -euo pipefail
# Lab only. Replace api-worker with a canary container you own.
docker inspect api-worker > /tmp/inspect.json
python3 inspect_env_gate.py /tmp/inspect.json

If you want a one-liner before the Python gate exists, this jq probe is the smoke test, not the policy:

docker inspect api-worker | jq -r '.[0].Config.Env[]' \
  | awk -F= '$1 ~ /(SECRET|TOKEN|PASSWORD|API_KEY)$/ { print $1; found=1 } END { exit found+0 }'

A zero from awk here is not a pass. It is a hint. Names without those suffixes still leak URLs with embedded passwords. That is why the Python fixture looks at values too.

Local free server versus remote free model

Once the dump exists, you still need a place to reason about it. I split the work by boundary, not by brand.

MonkeyCode is an open-source, self-hosted AI development platform with free model access and a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I do not need a model catalog to use that split. Remote free-model access is for questions that already passed the gate. A free server you operate is for the raw inspect JSON, the compose file, and the crash loop that still contains the DSN.

Artifact	Remote free-model channel	Self-hosted server	Why
`PATH`, `NODE_ENV`, `LANG`	Allowed	Allowed	No secret material
Redacted schema: keys only	Allowed after gate	Allowed	Structure without values
`DATABASE_URL` in the clear	Denied	Disk encrypted, access logged	Credential + topology
`JWT_SECRET`	Denied	Denied in chat logs too	Signing key outlives the incident
Full `docker inspect`	Denied	Allowed in a restricted workspace	Image IDs and mounts leak too

Convenience is not a control. Free remote tokens do not change the data-flow. They change the invoice.

Prevent / detect / recover

Layer	Prevent	Detect	Recover
Image build	Runtime secrets from a manager, not `ENV`/`ARG`	`docker history` and `inspect` in CI	Rebuild without the value; rotate
Host	Drop `docker inspect` from shared jump boxes	Gate on inspect JSON before paste	Treat paste as a credential event
Prompt channel	Block secret-bearing Env at the workspace sync	Fail closed on `exit 2`	Rotate DB password and JWT key
Self-hosted disk	Workspace allowlist, no homedir mounts	Alert on `BEGIN PRIVATE KEY` in prompt logs	Wipe workspace volume, rotate again

Rotation is the recovery. Redaction is not. If a remote model already saw CANARY_PASSWORD, you rotate. You do not "ask the provider to forget."

Threat model notes

Attacker is not a nation-state here. Attacker is you, tired, plus whoever later reads the chat transcript.

Spoofing. A paste looks like "debug context." It is a credential export.
Information disclosure. Env dumps include topology, image tags, and sometimes file paths.
Tampering. A model that saw a JWT secret can suggest "fixes" that keep the same secret.
Denial of recovery. If the only copy of the DSN lived in that dump and you rotate blindly, you still need a secrets manager as source of truth.

I also assume the self-hosted server can be compromised. That is why JWT material does not belong in its chat logs either. Local is a smaller blast radius. It is not a shredder.

Limitations — who should not use this

This gate will miss low-entropy passwords in names like APP_SETTING_12. It will false-positive on GPG_TTY. It will not see secrets in overlay files, Swarm secrets, or Kubernetes envFrom once they are already in the process. docker inspect is one serialization. proc/<pid>/environ is another.

Do not use this approach if:

You need the model to debug the literal password. That request is the incident.
Your policy forbids any runtime metadata leaving the VPC, redacted or not.
You cannot rotate the credential you might leak. A gate without rotation is theater.
You ship this regex pack as a compliance control. It is a regression fixture.

Unexecuted means unexecuted. Run it against a canary container you own. Do not point it at a production inspect dump and then paste the failure into a ticket that syncs to a SaaS tracker. That just moves the leak.

What I actually enforce

I want one invariant in CI: inspect JSON with secret-bearing Env never attaches to a model job.

The host enforces collection. The classifier enforces the prompt channel. The secrets manager enforces recovery. Which of those three belongs in CI for your platform, and which layer should fail closed when the worker is down and someone is in a hurry?

Audit a WAF 403 Dump Before a Model Sees the Cookie You Blocked

jaryn — Sun, 20 Sep 2026 10:40:40 +0000

Last Tuesday a platform engineer dropped a WAF 403 into our incident channel. Full request. Host, path, Cookie, Authorization, X-Real-IP. Then someone asked the question I now treat as a pager: can we just paste this into the model and ask why it got blocked?

I read the dump twice. The model would have learned more about our session than about the rule that fired.

That is the failure. Not a jailbreak. A trust-boundary violation you can reproduce with a text file and a bad habit.

The event sequence that actually leaks

I keep seeing the same five steps. They take under a minute, and nobody files a ticket.

A client hits an app behind a WAF and gets 403.
The WAF log stores the raw request: method, path, headers, sometimes a truncated body.
An engineer copies the log line into a coding agent and asks why it got blocked.
The model answers something plausible about XSS, a bot score, or a missing header.
Nobody notices session= and Authorization: Bearer just crossed into model context.

Did the model need the cookie to explain a 403? No. Did we send it anyway? Yes.

If you cannot show a failing fixture for that paste, you do not have a control. You have a guideline.

Trust boundaries, drawn the way a WAF thinks

I draw four zones. Anything that moves right pays a tax.

[browser] --request--> [WAF] --maybe--> [app]
                          |
                          v
                    [block log / SIEM]
                          |
                          v
              [human paste / agent pack]
                          |
                          v
               [model runtime]   <== prompt boundary

The WAF is allowed to see the cookie. That is its job. The log store is a maybe, and I usually argue it should not. The model runtime is a no.

A self-hosted coding platform does not collapse those zones. It moves the runtime. The cookie still left the WAF.

Think about the second hop, too. Prompt cache, conversation export, ticket attachments, the SIEM sample someone forwarded to a chat thread. Once a session value is in model context, you are rotating credentials. You are not editing a prompt.

Whether the box in front of the app is SafeLine or another reverse-proxy WAF does not change the invariant. The product can see the header. The model must not.

What I refuse to send

I am not trying to redact the internet. I am trying to stop the dump formats I actually paste.

Never send these in a why-was-this-blocked prompt:

Cookie and Set-Cookie values, including session, sid, JSESSIONID
Authorization headers, Basic or Bearer
CSRF tokens (X-CSRF-Token, hidden form tokens)
Internal IPs and full X-Forwarded-For chains
Request bodies with passwords, one-time codes, or card-shaped numbers
JWT strings. The payload is not just metadata.

What can I send? Method, path, a redacted host, the WAF rule id, the action (deny / challenge), and a header-name list without values. That is enough to debug a false positive. If it is not, your log pipeline is the bug, not the model.

Header names can travel. Header values cannot. Can you say that out loud in a design review without someone reaching for a full raw request? If not, the paste habit is already the control failure.

Build a prompt-boundary fixture

I want a gate that fails the paste. Not a slide. A command that exits 1.

These dumps are synthetic fixtures, not evidence of a production finding. Pin Python 3.12. The file names are the contract. Label the scanner unexecuted until you run it on your machine.

1. Negative fixture (must pass)

Create fixtures/waf_403_negative.txt:

timestamp=2026-09-20T14:02:11Z
action=deny
rule_id=100245
method=GET
path=/admin/users
host=app.example.internal
blocked_headers=Cookie,Authorization,X-Forwarded-For
note=header values stripped by log pipeline

No cookie value. No bearer. No internal client IP. This is what I want the model to see.

2. Positive fixture (must fail)

Create fixtures/waf_403_positive.txt:

timestamp=2026-09-20T14:02:11Z
action=deny
rule_id=100245
method=GET
path=/admin/users
host=app.example.internal
Cookie: session=s8d7f6e5c4b3a2; csrf=0a1b2c3d
Authorization: Bearer FAKESECRET_w3x4y5z6a7b8c9d0e1f2
X-Forwarded-For: 10.4.12.8, 192.168.9.3

Synthetic values only. If your scanner returns 0 on this file, the scanner is theater.

3. The scanner

Save as prompt_boundary_audit.py. The checks stay reviewable on purpose: header-line prefixes, a few token needles, and stdlib ipaddress for RFC1918.

#!/usr/bin/env python3
"""Fail a WAF dump that still carries session material."""
from __future__ import annotations

import ipaddress
import sys
from pathlib import Path

HEADER_LABELS = {
    'cookie:': 'cookie-header',
    'set-cookie:': 'set-cookie-header',
    'authorization:': 'authorization-header',
    'x-csrf-token:': 'csrf-header',
    'x-forwarded-for:': 'xff-header',
    'x-real-ip:': 'real-ip-header',
}

TOKEN_LABELS = {
    'bearer ': 'bearer-token',
    'session=': 'session-cookie',
    'jsessionid=': 'session-cookie',
}


def scan(text: str) -> list[str]:
    hits: list[str] = []
    lowered = text.lower()

    for line in text.splitlines():
        stripped = line.strip().lower()
        for prefix, label in HEADER_LABELS.items():
            if stripped.startswith(prefix) and label not in hits:
                hits.append(label)

    for needle, label in TOKEN_LABELS.items():
        if needle in lowered and label not in hits:
            hits.append(label)

    idx = lowered.find('eyj')
    if idx >= 0:
        chunk = lowered[idx:idx + 80]
        if chunk.count('.') >= 2 and 'jwt-like' not in hits:
            hits.append('jwt-like')

    for part in text.replace(',', ' ').replace(';', ' ').split():
        try:
            ip = ipaddress.ip_address(part.strip())
        except ValueError:
            continue
        if ip.is_private and 'rfc1918-ip' not in hits:
            hits.append('rfc1918-ip')
    return hits


def main(argv: list[str]) -> int:
    if len(argv) != 2:
        print('usage: prompt_boundary_audit.py <dump>', file=sys.stderr)
        return 2
    path = Path(argv[1])
    hits = scan(path.read_text(encoding='utf-8', errors='replace'))
    if hits:
        print('FAIL ' + str(path) + ': ' + ', '.join(hits))
        return 1
    print('PASS ' + str(path))
    return 0


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

4. Expected evidence

Run both files. I want opposite exit codes. Anything else is a broken gate.

python3 prompt_boundary_audit.py fixtures/waf_403_negative.txt; echo $?
# expected: PASS fixtures/waf_403_negative.txt
# expected exit: 0

python3 prompt_boundary_audit.py fixtures/waf_403_positive.txt; echo $?
# expected: FAIL fixtures/waf_403_positive.txt: cookie-header,
#           authorization-header, xff-header, bearer-token,
#           session-cookie, jwt-like, rfc1918-ip
# expected exit: 1

Put the positive case in CI. If someone improves logging by writing raw headers back to disk, the job should go red. That is the whole point.

Prevent, detect, recover

Layer	Prevent	Detect	Recover
WAF log pipeline	Drop `Cookie`, `Authorization`, bodies, and client IPs before disk	Alert when a log line still matches the scanner	Rotate the session, invalidate the cookie, treat the log as a secret
Engineer paste	Refuse to copy raw dumps; keep a redacted template	Run the scanner on the file before any model call	Assume the conversation is tainted; wipe it; rotate
Agent harness	Allowlist a context pack; never glob `*.log`	Fail the tool call when the fixture would fail	Revoke the workspace credential; keep the dump out of prompt cache

I would rather fight with a log vendor about field stripping than explain a session cookie in a model transcript. Wouldn't you?

Where a free model runtime still sits

When I evaluate a self-hosted coding agent, I treat the model runtime as a separate trust zone even if the server is ours.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source AI development platform. The operator-supplied options I care about here are free model access and a free server option. Those change cost. They do not move the prompt boundary. If a 403 dump still contains a session cookie, a free server is the wrong place for it.

I will use a free runtime to iterate on the scanner, the fixtures, and a redacted dump. I will not use it as a reason to relax log stripping. Cheap inference is not a data-handling control.

Limitations, and who should not use this

This scanner is a regression fixture. It is not DLP.

It will miss encoded cookies, line-folded headers, gzip members, multipart bodies, and tokens split across chunks. It can false-positive on prose that puts Authorization: at the start of a line. That is why the negative fixture records header names as blocked_headers=Cookie,Authorization,... without a colon-space value form. Tune the prefixes. Do not pretend they are complete.

Do not use this approach if:

You need a real DLP or tokenization pipeline in front of every model call
You work in an environment where even redacted 403 paths are customer-identifying
You will treat a green PASS as permission to upload production traffic
You cannot rotate sessions after an accidental paste

And do not confuse a WAF false-positive debug session with a penetration test. This article does not reproduce a bypass. It reproduces a leaky paste.

Which layer owns the invariant?

I want one question left on the table. Which invariant belongs in CI, and which layer should enforce it?

My default: the log pipeline must strip values. CI must keep the positive dump failing. The harness must refuse *.log globs. The human paste rule is last, because humans paste.

If you are standing up a self-hosted coding workspace, run this fixture against a redacted 403 before you ever paste a live one.

Build a Homedir Deny Fixture Before an Agent Reads `.netrc`

jaryn — Sat, 19 Sep 2026 08:56:19 +0000

Last Tuesday a coding agent “helped” with a flaky checkout script. The repo was tiny. The workspace was not.

Someone had opened the agent at ~/work. checkout.sh called curl --netrc. The agent did what file tools do: it followed the comment, opened ~/.netrc, and quoted a machine api.internal line back into the chat. No prompt injection. No jailbreak theater. A trust-boundary miss.

If your agent can read a credential file, the model is not the interesting part. The path is. Would you paste that file into Slack? Then why can a tool loop open it?

This is a lab walkthrough, not a vulnerability report. I did not find a CVE. I built two fixtures and a gate that fails closed when the agent root can see homedir secrets. Treat the commands as a local regression, not evidence that any hosted product leaked production credentials.

The failing sequence

Here is the event order I keep reproducing in a throwaway directory. It is boring. That is the point.

Developer points a coding agent at ~/work because “that is where the repos live.”
~/work/shop/checkout.sh contains curl --netrc -f "$API_URL/health".
The agent lists files, then reads checkout.sh, then follows the flag to ~/.netrc.
Chat now contains machine, login, and password lines. Those lines also land in agent traces, session exports, and whatever log shipper you forgot.

The trust boundary is not “the model is aligned.” The boundary is “which realpaths the file tool may open.” Mix $HOME into that set and you are doing vibe ops. You are not doing engineering.

Threat model, kept small

I only care about three files in this fixture. Expand later if you must. Do not start with a 40-row spreadsheet and zero failing tests.

Asset	Trust boundary	What the agent should never receive	Failure mode
`~/.netrc`	Homedir credential store, not the git tree	`machine` / `login` / `password` stanzas	Chat, traces, and fine-tunes learn internal API basic auth
`~/.pgpass`	libpq client secret file	`host:port:db:user:password`	Integration-test “help” dumps a live DB password
`~/.docker/config.json`	Registry auth cache	`auths.*.auth` (base64 `user:pass`)	Agent “debugs a pull” and reprints a registry token

Secondary assets I deny by name in the same gate: id_rsa, id_ed25519, .git-credentials, kube user.token files, and credentials under .aws. I still do not treat a filename deny-list as a sandbox. It is a CI tripwire. Shell tools can walk $HOME unless you block that too.

What about logs? Same rule. If the agent cannot open .netrc, it also cannot open a support zip that already copied .netrc. Redact at the workspace edge. Do not pray at the prompt.

Two fixtures, pinned to a layout

Python 3.12. No third-party packages. Unexecuted against your laptop until you run it; expected evidence is the gate’s exit code, not a screenshot of a vendor UI.

Layout:

agent-root-lab/
  tools/assert_agent_root.py
  fixtures/positive/src/checkout.sh
  fixtures/negative/.netrc
  fixtures/negative/.pgpass
  fixtures/negative/.docker/config.json
  fixtures/negative/src/checkout.sh

Positive checkout.sh talks to a public health endpoint and does not mention --netrc. Negative checkout.sh does. That is deliberate. The gate must fail on the credential files even if you later rewrite the script.

Negative canaries. Fake on purpose:

machine api.internal.example
login ci-bot
password canary-netrc-token-NOTREAL

127.0.0.1:5432:shop:shop:canary-pgpass-NOTREAL

{
  "auths": {
    "ghcr.example.invalid": {
      "auth": "Y2FuYXJ5OmNhbmFyeS1kb2NrZXItYXV0aC1OT1RSRUFM"
    }
  }
}

If a later export, RAG chunk, or chat transcript contains canary-netrc-token-NOTREAL, you have a leak in the pipeline. That string is the test oracle. Keep it ugly so grep never collides with a real password.

The gate

tools/assert_agent_root.py is the artifact. It refuses $HOME, /, and any agent root that contains deny-listed basenames. It also refuses a root whose resolved path is inside $HOME unless you pass --i-mean-it — which CI must not pass.

#!/usr/bin/env python3
"""Fail closed if an agent workspace can see homedir credential files.

Lab fixture for Python 3.12. Not a sandbox. Not a vulnerability report.
"""
from __future__ import annotations

import argparse
import os
import sys
from pathlib import Path

DENY_NAMES = {
    ".netrc",
    ".pgpass",
    ".npmrc",
    ".git-credentials",
    "id_rsa",
    "id_ed25519",
    "credentials",  # .aws/credentials
    "kubeconfig",
}

DENY_TAIL = {
    (".docker", "config.json"),
    (".aws", "credentials"),
    (".kube", "config"),
}


def fail(msg: str) -> int:
    print(f"FAIL: {msg}", file=sys.stderr)
    return 1


def iter_files(root: Path):
    for p in root.rglob("*"):
        if p.is_file() and not p.is_symlink():
            yield p


def denied(path: Path) -> str | None:
    if path.name in DENY_NAMES:
        return f"basename {path.name}"
    parts = path.parts
    for tail in DENY_TAIL:
        if parts[-len(tail) :] == tail:
            return "/".join(tail)
    return None


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("root", type=Path)
    parser.add_argument("--i-mean-it", action="store_true")
    args = parser.parse_args()

    root = args.root.expanduser().resolve()
    home = Path.home().resolve()

    if not root.is_dir():
        return fail(f"{root} is not a directory")
    if root in {Path("/"), home}:
        return fail(f"agent root must not be {root}")
    if home == root or home in root.parents:
        return fail(f"{root} sits inside $HOME")
    if root == home or home in root.parents:
        pass
    if str(root).startswith(str(home) + os.sep) and not args.i_mean_it:
        return fail(f"{root} is under $HOME; isolate the workspace")

    hits = []
    for path in iter_files(root):
        why = denied(path)
        if why:
            hits.append(f"{path} ({why})")

    if hits:
        print("FAIL: credential paths inside agent root:", file=sys.stderr)
        for h in hits:
            print(f"  - {h}", file=sys.stderr)
        return 1

    print(f"PASS: {root} has no deny-listed credential files")
    return 0


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

Expected evidence, labeled because I am not running this against your tree:

# negative: must exit 1 and print .netrc / .pgpass / .docker/config.json
python3 tools/assert_agent_root.py fixtures/negative; echo exit:$?

# positive: must exit 0
python3 tools/assert_agent_root.py fixtures/positive; echo exit:$?

# homedir: must exit 1 even if the tree is “clean”
python3 tools/assert_agent_root.py "$HOME"; echo exit:$?

If the negative case prints PASS, the gate is wrong. Fix the gate. Do not “prompt the model to be careful.”

Prevent / detect / recover

Layer	Action	Who owns it
Prevent	Agent root is a dedicated directory with an allowlist of `src/`, `tests/`, and lockfiles. Homedir is not mounted. Shell tool working directory is that root.	Platform / agent harness
Prevent	CI runs `assert_agent_root.py` on the directory you pass to the agent, not on the git repo after a hopeful `.gitignore`	CI
Detect	Grep session exports and tool traces for canaries (`canary-netrc-token-NOTREAL`)	Security / SRE
Detect	Deny-list is necessary but weak; also block `read`/`exec` outside the root at the tool broker	Agent runtime
Recover	Rotate the canary’s real counterpart if a production file ever matched. Treat chat history as compromised. Wipe the session store.	Incident

.gitignore is not a trust boundary. Agents do not only see committed files. They see the working tree, and they see whatever you bind-mounted “for convenience.”

What never goes to a model

Say it in one list so nobody has to infer it from vibes.

Contents of .netrc, .pgpass, .npmrc, .git-credentials
~/.docker/config.json auths values, even when they look like base64 sludge
SSH private keys and kubeconfig user tokens
Live connection strings from pytest failures, SQLAlchemy repr(), or Spring application-local.yml
Prior chat transcripts that already quoted any of the above

Comments in Makefiles that say “uses netrc” are fine. The file those comments point at is not. If the agent needs to fix checkout.sh, give it a fake NETRC=/workspace/fixtures/netrc.example with canaries, not your laptop file.

Where a free, isolated server actually helps

The temptation is to enable a coding agent on the same box you use for git push and docker login. Free compute makes that temptation worse. You skip isolation because the experiment “should only take ten minutes.”

I use an isolated workspace for this lab: source plus fixtures, no homedir overlay, no production kube context. MonkeyCode’s free model access and free server option are relevant here as a disposable box for that workspace — not as a reason to rsync $HOME. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

If the server still mounts your developer dotfiles, the price being zero does not change the threat model. Isolation is the feature. The model is just the consumer on the far side of a path allowlist.

A public clone of the gate plus the two fixtures is enough to review the idea. You do not need my account, and you do not need a vendor UI, to fail the negative case.

Limitations, and who should not use this

Filename deny-lists miss secrets with polite names. local.settings.json, helm/values-prod.yaml, and terraform.tfvars will sail through unless you add content scanning. This script does not open files. That is intentional. It is a path invariant, not a secret scanner.

Symlinks: I skipped them on purpose so a malicious tree cannot make the walker follow ../../.netrc into an infinite mess. Your harness still must refuse readlink outside the root. Otherwise the gate is theater.

Do not use this approach if:

Your agent has an unrestricted shell. A deny-list on read is worthless next to cat ~/.netrc.
You need to share a real homedir with the agent “so it knows my tooling.” Teach it via a checked-in dotfiles subset with canaries.
You think a system prompt that says “never read secrets” is an invariant. It is not. Invariants live in CI and in the tool broker.

Also do not paste the negative fixture into a shared eval set that ships to a third-party trainer unless those canaries are the only secrets in the tree. Eval corpora become training corpora. You already knew that. Act like it.

The boundary question

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

CI should fail if the directory you will pass to an agent contains deny-listed credential paths, or if that directory resolves under $HOME. The tool broker should enforce the same realpath allowlist at runtime, including shell cwd. The model should see neither .netrc nor a log that already copied it.

If you only do the prompt, you are calling it engineering. You are not doing it.

Reproduce a Terraform State Password Leak With a Minimal JSON Fixture

jaryn — Fri, 18 Sep 2026 06:58:22 +0000

The apply failed. Staging RDS would not rotate. Someone dropped terraform show -json into a chat model and asked why the password in state still matched the old output.

The model quoted db_master_password back in the first paragraph. That is not a debugging win. That is a trust-boundary violation: a secret that belonged in the state backend just crossed into a model prompt log, and you cannot unsend it.

You needed a diff. Why did the whole state go with it?

This article is a lab walkthrough, not a production incident report. I am not claiming I found a live leak. I am claiming the JSON shape below is enough to fail a gate before any model, local or remote, is allowed to see infrastructure state.

The actual failure sequence

terraform apply errors on an RDS password rotate.
An engineer runs terraform show -json or copies terraform.tfstate.
The blob is pasted into an agent because “the plan is too noisy.”
The model echoes outputs.db_password.value while explaining the graph.
The prompt, the completion, and often the tool trace now hold a live credential.

Gitignoring *.tfstate does not help. This is not a commit problem. This is a paste problem.

.gitignore stops git. It does not stop a model.

Trust boundaries, not vibes

Treat the model as another principal. It is not your backend. It is not Vault. It is not terraform console.

Zone	What it is allowed to hold	What must never cross out
Terraform backend (S3, GCS, Terraform Cloud)	Full state, including `sensitive` values that Terraform still stores	Unauthenticated read, world-readable buckets
Engineer workstation	A local pull of state for apply/plan	Raw JSON into clipboard, chat, tickets, agents
Redaction gate (CI or pre-tool hook)	Paths, resource addresses, redacted hashes	Cleartext `outputs.*.value`, provider env, private keys
Model context	Resource addresses, error codes, sanitized diffs	Passwords, tokens, kubeconfig `client-key-data`, TLS PEMs
Model provider logs / traces	Whatever you already sent	Your ability to delete it on demand

Terraform’s sensitive = true is a UI flag. It hides values in terminal output. It does not remove them from state. If you did not know that, you are the audience for this fixture.

Ask the ugly question: if the model provider is subpoenaed tomorrow, is that RDS password in the export?

Lab fixture (synthetic, labeled)

Pin the shape, not a vendor myth. Modern Terraform state is format version 4. The file below is a lab object. Do not load it into a real backend.

{
  "version": 4,
  "terraform_version": "1.9.8",
  "serial": 7,
  "lineage": "lab-not-a-real-lineage",
  "outputs": {
    "db_password": {
      "value": "tfstate-canary-P@ssw0rd-9f3c",
      "type": "string",
      "sensitive": true
    },
    "endpoint": {
      "value": "staging-db.internal.example",
      "type": "string",
      "sensitive": false
    }
  },
  "resources": [
    {
      "mode": "managed",
      "type": "random_password",
      "name": "db",
      "provider": "provider[\"registry.terraform.io/hashicorp/random\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "none",
            "result": "tfstate-canary-P@ssw0rd-9f3c",
            "length": 24,
            "special": true
          },
          "sensitive_attributes": [
            ["result"]
          ]
        }
      ]
    }
  ]
}

Save it as fixtures/positive.tfstate.json.

The canary is the point. If a model completion, a tool trace, or a chat export later contains tfstate-canary-P@ssw0rd-9f3c, you have proof the boundary failed. No guessing. No “the model might have hallucinated a password.”

Negative fixture, fixtures/negative.tfstate.json: same graph, values replaced with ***REDACTED***, and sensitive_attributes left in place so the structure still looks like Terraform.

Expected evidence:

Positive file must fail the gate (exit 2).
Negative file must pass (exit 0).
A completion that repeats the canary is a failed control, not a clever explanation.

Gate the JSON, not the vibes

Here is a stdlib scanner you can drop in CI or in a pre-tool wrapper. Unexecuted against your backend until you run it. That is the honest label.

#!/usr/bin/env python3
"""Fail if Terraform state still carries cleartext secrets. stdlib only."""
from __future__ import annotations

import json
import re
import sys
from pathlib import Path

CANARY = "tfstate-canary-P@ssw0rd-9f3c"
SECRETISH = re.compile(
    r"(password|secret|token|private_key|access_key|client-key-data)",
    re.I,
)
PEM = re.compile(r"-----BEGIN (?:RSA |EC |OPENSSH )?PRIVATE KEY-----")
HIGH_ENTROPY = re.compile(r"^[A-Za-z0-9/+=_\-]{20,}$")


def walk(node, path: str, hits: list[str]) -> None:
    if isinstance(node, dict):
        for k, v in node.items():
            walk(v, f"{path}.{k}" if path else k, hits)
    elif isinstance(node, list):
        for i, v in enumerate(node):
            walk(v, f"{path}[{i}]", hits)
    elif isinstance(node, str):
        if node == CANARY or PEM.search(node):
            hits.append(path)
            return
        if SECRETISH.search(path) and node and node != "***REDACTED***":
            hits.append(path)
        elif SECRETISH.search(path) and HIGH_ENTROPY.match(node):
            hits.append(path)


def main(argv: list[str]) -> int:
    if len(argv) != 2:
        print("usage: tfstate_secret_gate.py <state.json>", file=sys.stderr)
        return 2
    raw = json.loads(Path(argv[1]).read_text())
    hits: list[str] = []
    walk(raw.get("outputs", {}), "outputs", hits)
    walk(raw.get("resources", []), "resources", hits)
    if hits:
        print("REFUSE: cleartext secret paths in terraform state:")
        for h in hits:
            print(f"  - {h}")
        return 2
    print("PASS: no canary / secret-shaped values in outputs or resources")
    return 0


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

Commands, as a reader-run recipe:

python3 tfstate_secret_gate.py fixtures/positive.tfstate.json
# expected: exit 2, path list includes outputs.db_password.value

python3 tfstate_secret_gate.py fixtures/negative.tfstate.json
# expected: exit 0

# What people actually paste — still in scope:
terraform show -json > /tmp/show.json
python3 tfstate_secret_gate.py /tmp/show.json

A one-liner if you do not want Python yet:

jq -e '
  .outputs | to_entries[]
  | select(.value.sensitive == true and (.value.value | type == "string")
           and .value.value != "***REDACTED***")
  | .key
' fixtures/positive.tfstate.json && echo "REFUSE" || true

If that prints db_password, the file is not model-safe. Stop.

What not to send to a model

Refuse the whole object if any of these are present in cleartext:

outputs.*.value when sensitive is true
random_password / tls_private_key result or private_key_pem
provider env: AWS_SECRET_ACCESS_KEY, GOOGLE_CREDENTIALS, KUBE_CONFIG_RAW
client-key-data, client-certificate-data, token inside any kubeconfig blob that landed in state
database URLs with postgres://user:password@
the canary string, always

Allow, after the gate passes:

resource addresses (random_password.db)
error codes from the apply log with secrets stripped
a redacted plan: actions, counts, resource types
hashes of values (sha256:…) if you need to prove “it changed” without proving “here it is”

Sanitize before the model, not after the completion. After is forensics. Before is control.

Prevent / detect / recover

Layer	Prevent	Detect	Recover
CI	Fail the job if a prompt pack, gist, or “debug bundle” contains `version: 4` plus `resources` plus secret-shaped strings	Gate exit 2 on `terraform show -json` artifacts	Drop the artifact from the bundle; do not “just redact in the ticket”
Agent harness	Tool wrapper: run the gate on any file whose name matches `.tfstate` or whose JSON has `terraform_version`	Canary match in stdout/stderr/tool traces	Kill the session; mark the trace as secret-bearing
Human paste	Refuse to paste `terraform show -json` into any chat	Clipboard check on `tfstate-canary-` in drills	Rotate the DB password and any key that appeared in outputs
Backend	Bucket policy, encryption, no public ACLs	CloudTrail / access logs on `GetObject` for state	Rotate credentials stored in state, then `terraform apply` to rewrite

Recovery is not “ask the model to forget.” Recovery is rotate, rewrite state, and treat the provider log as compromised for that secret’s lifetime.

Where a self-hosted model still fits

A local model does not make raw state safe. Same JSON, same leak, smaller blast radius. Smaller is not zero.

The useful split is mechanical:

Gate the file on the workstation or in CI.
Only then ask a model to explain a redacted plan.
Keep even that step inside a network you control if the redaction is imperfect — and it will be imperfect.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. I use MonkeyCode here only as one self-hosted option: its free model access and free server option are relevant when you want the redacted review to stay on your side of the boundary. The gate above does not depend on it. If you strip the product name out, the invariant is unchanged: no cleartext outputs.*.value in the prompt.

Do not send the positive fixture to any hosted model to “see what happens.” You already know what happens. The canary comes back.

Limitations, and who should not do this

This scanner is a tripwire. It is not a secret detector for all of Terraform.

Nested objects, null_resource triggers, and external data sources will hide strings the regex never sees.
sensitive_attributes records paths; it does not erase attributes.
Partial plans (terraform show -json tfplan) have a different schema (resource_changes[].change.after). Extend the walker or you will false-pass.
Remote state pulled with terraform state pull is still a local secret once it hits disk.
High-entropy matching will false-positive on IDs. Tune paths, not vibes.

Who should not use this approach:

Anyone hoping a model will manage production secrets. Wrong principal.
Teams with no Terraform state in the debugging path — use a different fixture.
People who will run the positive fixture against a public endpoint “as a demo.” That is how canaries die.
Air-gapped incident work that does not need a model at all. Then skip the model. Keep the gate.

If your process is “paste first, redact if someone complains,” you do not have a process.

Close the loop in CI, not in the chat

Put the canary in a scheduled drill. Put the gate on any job that builds an “AI debug bundle.” Put a harness check in front of file-read tools. Three layers, one invariant: Terraform state is not model input.

Which invariant belongs in CI, and which layer should enforce it? CI should refuse to ship a bundle that still contains format-version-4 state with cleartext outputs. The agent harness should refuse to read that file even if CI was skipped. The model should never be the layer that notices.

If the model is the first control that sees the password, the control already failed.

Audit a Browser HAR Before a Model Sees the Session You Captured

jaryn — Thu, 17 Sep 2026 05:03:39 +0000

The login form spun. 401, then 302, then 401 again. I opened DevTools, reproduced it once, and hit Export HAR. The file landed on my desktop as login.har. Forty-seven requests. One of them was the IdP token endpoint. I was one paste away from asking a model why the cookie refused to stick.

Would you have opened the file first?

I did not, not the first time I wired this fixture. The HAR held Set-Cookie, an Authorization: Bearer header, and a refresh token in a JSON body. That is not a stack trace. That is a credential export sitting on the wrong side of a trust boundary.

The failing sequence

Here is the event chain I keep reproducing in a lab folder. No production tenant. No real IdP. Just a file that looks like the one you almost pasted.

Browser records a login redirect.
DevTools writes HTTP Archive 1.2 to disk.
You copy the HAR, or a “sanitized” excerpt, into a model prompt.
The model provider now holds the session cookie, the bearer, and often the refresh token.
You rotate nothing, because it “was only debugging.”

Sound familiar? The failure is not that the model is clever. The failure is that a HAR is a full-fidelity wire dump, and dump formats do not care about your intent.

Trust boundaries, not vibes

A HAR crosses four boundaries I actually care about.

Layer	What it holds	Who can read it after a paste
Browser process	Live cookies, in-flight POSTs	You, extensions, the OS
Workstation disk	The `.har` file, editor swap, shell history	Backup agents, sync clients, the next intern
Clipboard / chat UI	Whatever you selected	Screenshot tools, paste logs
Remote model API	Prompt + attachments + provider logs	The vendor, operators, whoever they retain

The invariant I want is boring. No Cookie, Set-Cookie, Authorization, OAuth token, or password field may leave the workstation toward a model. If that sentence makes you flinch, good. That is the point.

What must not go to a model? Session cookies. Bearer tokens. Refresh tokens. client_secret. Authorization codes in query strings. Password fields in postData. CSRF tokens tied to a live session. Anything that lets the recipient become you.

What can go? Status codes. Hostnames you already publish. Redirect hop counts. A redacted method/path list. Timing. A synthetic reproduction script. That is usually enough to debug a 401.

Minimal fixtures (pinned, synthetic)

Pinned for this write-up: HTTP Archive 1.2, Python 3.12 stdlib only, jq 1.7 if you want a one-liner. The hosts are .test. The secrets are canaries. This is a regression fixture, not a claim that I found a live leak.

Negative fixture — should pass the gate. Static asset, no credentials:

{
  "log": {
    "version": "1.2",
    "entries": [
      {
        "request": {
          "method": "GET",
          "url": "https://app.example.test/assets/app.css",
          "headers": [{"name": "Accept", "value": "text/css"}],
          "queryString": [],
          "postData": {"text": ""}
        },
        "response": {
          "status": 200,
          "headers": [{"name": "Content-Type", "value": "text/css"}],
          "content": {"text": "body{margin:0}"}
        }
      }
    ]
  }
}

Positive fixture — must fail the gate. One login hop, three credential classes:

{
  "log": {
    "version": "1.2",
    "entries": [
      {
        "request": {
          "method": "POST",
          "url": "https://idp.example.test/oauth/token?code=AUTHCODECANARY",
          "headers": [
            {"name": "Authorization", "value": "Bearer eyJhbGciOiJub25lIn0.CANARY"},
            {"name": "Cookie", "value": "session=SESSCANARY"}
          ],
          "queryString": [{"name": "code", "value": "AUTHCODECANARY"}],
          "postData": {"text": "grant_type=authorization_code&client_secret=SECRETCANARY"}
        },
        "response": {
          "status": 200,
          "headers": [
            {"name": "Set-Cookie", "value": "session=SESSCANARY; HttpOnly; Secure"}
          ],
          "content": {"text": "{\"refresh_token\":\"REFRESHCANARY\"}"}
        }
      }
    ]
  }
}

Save them as fixtures/har_clean.har and fixtures/har_session.har. If your gate cannot tell them apart, you do not have a gate.

A workstation audit you can run

Label: this is a local fixture script, not a scanner I ran against anyone’s production HAR.

#!/usr/bin/env python3
"""Fail closed if a HAR still carries session material. Python 3.12."""
from __future__ import annotations

import json
import re
import sys
from pathlib import Path
from urllib.parse import urlparse, parse_qs

SENSITIVE_HEADERS = {
    "authorization",
    "proxy-authorization",
    "cookie",
    "set-cookie",
    "x-api-key",
    "x-auth-token",
}
SENSITIVE_PARAMS = {
    "access_token",
    "id_token",
    "refresh_token",
    "token",
    "password",
    "passwd",
    "code",
    "client_secret",
    "client_id",
    "api_key",
    "session",
}
BODY_RE = re.compile(
    r"(password|passwd|refresh_token|access_token|client_secret|id_token|session)=",
    re.I,
)

def _headers(obj: dict) -> list[tuple[str, str]]:
    out = []
    for h in obj.get("headers") or []:
        out.append((str(h.get("name", "")), str(h.get("value", ""))))
    return out

def audit(path: Path) -> list[str]:
    har = json.loads(path.read_text(encoding="utf-8"))
    hits: list[str] = []
    for i, entry in enumerate(har.get("log", {}).get("entries", []), start=1):
        req, resp = entry.get("request") or {}, entry.get("response") or {}
        url = req.get("url") or ""
        parsed = urlparse(url)
        qs = parse_qs(parsed.query, keep_blank_values=True)
        for name, values in qs.items():
            if name.lower() in SENSITIVE_PARAMS:
                hits.append(f"entry {i}: query {name} on {parsed.hostname}{parsed.path}")
        for collection, label in ((req, "req"), (resp, "resp")):
            for name, value in _headers(collection):
                if name.lower() in SENSITIVE_HEADERS and value.strip():
                    hits.append(f"entry {i}: {label} header {name}")
        for blob in (
            (req.get("postData") or {}).get("text") or "",
            (resp.get("content") or {}).get("text") or "",
        ):
            if BODY_RE.search(blob):
                hits.append(f"entry {i}: body matched credential pattern")
            try:
                data = json.loads(blob) if blob.strip().startswith("{") else {}
            except json.JSONDecodeError:
                data = {}
            if isinstance(data, dict):
                for key in data:
                    if str(key).lower() in SENSITIVE_PARAMS:
                        hits.append(f"entry {i}: json key {key}")
    return hits

def main() -> int:
    if len(sys.argv) != 2:
        print("usage: har_audit.py <file.har>", file=sys.stderr)
        return 2
    path = Path(sys.argv[1])
    hits = audit(path)
    if hits:
        print("FAIL: HAR still carries session material")
        for h in hits:
            print(f"  - {h}")
        return 1
    print("PASS: no session headers, token params, or password fields")
    return 0

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

Expected fixture output, local and synthetic:

$ python3 har_audit.py fixtures/har_clean.har
PASS: no session headers, token params, or password fields

$ python3 har_audit.py fixtures/har_session.har; echo exit:$?
FAIL: HAR still carries session material
  - entry 1: query code on idp.example.test/oauth/token
  - entry 1: req header Authorization
  - entry 1: req header Cookie
  - entry 1: resp header Set-Cookie
  - entry 1: body matched credential pattern
  - entry 1: json key refresh_token
exit:1

If you only have jq, this is the header half. It is not complete. It is a tripwire.

jq -r '
  .log.entries[]
  | . as $e
  | (
      ($e.request.headers[]? | select(.name|ascii_downcase|test("cookie|authorization|x-api-key"))),
      ($e.response.headers[]? | select(.name|ascii_downcase|test("set-cookie")))
    )
  | "HIT \(.name)"
' fixtures/har_session.har

A hit means stop. Do not “summarize the HAR for the model.” Summaries still leak the first 20 characters of a cookie, and those 20 characters are often enough.

Redact, then ask — never the reverse

I keep a drop folder the model is allowed to read. The HAR never goes there raw.

mkdir -p /tmp/model-inbox
python3 har_audit.py ./login.har && echo "refusing: gate must fail on a real login HAR"

What I actually send after a fail is a skeleton I type by hand:

IdP: idp.example.test
App: app.example.test
Hop 1: GET /login -> 302 to /oauth/authorize
Hop 2: POST /oauth/token -> 200
Hop 3: GET /app -> 401 (cookie not sent on API origin)
Question: is this a Secure+Domain mismatch or a SameSite=Lax POST?
No cookies, no bearers, no codes.

That is enough. If the model cannot debug a 401 without the cookie value, the model is not the bottleneck. Your reproduction is.

Prevent / detect / recover

Control	Layer	What it buys you	What it does not
Do not export production HARs	Process	No credential file exists	Useless if staging shares the IdP
`har_audit.py` on a pre-commit or drop folder	Workstation / CI	Fail closed before a model sees the file	Will miss novel header names
Allowlist prompt inbox	Agent harness	Model tools cannot `open()` `*.har`	Does not stop a human paste
Rotate session + refresh + client secret	IdP	Caps blast radius after a paste	Too late if you already pasted
Provider retention review	Legal / vendor	You know the retention story	Does not unsay a prompt

Prevent first. Detect in CI if .har files ever land in the repo. Recover by rotating, not by asking the model to “forget.”

I treat a self-hosted coding workspace as one more enforcement layer, not as magic. MonkeyCode is an open-source AI development platform I evaluate for that reason — keeping the model on my side of the HAR boundary, instead of shipping the capture to a public chat. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Operator-supplied for this piece: free model access and a free server option, which is relevant only after the gate is green. I still refuse to let the model vote on whether Set-Cookie is in scope.

Limitations, and who should not do this

This script is a deny-list. Deny-lists rot. A header named X-Session-Blob sails through. Multipart bodies, base64 cookies, and WebSocket frames inside a HAR are out of scope here. Redaction is not anonymization. Paths still identify tenants. Timestamps still identify people.

A local or self-hosted model does not erase the file. Prompts hit disk. Swap hits disk. Backups hit disk. If your threat is “a coworker’s laptop sync,” you need disk policy, not a smarter chatbot.

Who should not use this approach? Anyone whose plan is to HAR a production user and then “be careful.” Anyone debugging an incident that already needs legal hold — you do not run a hobby redactor over evidence. Anyone who thinks a passing gate means the HAR is safe to email. It is not. The gate only says the patterns I listed were absent.

Also skip this if you do not own the app. Exporting a session HAR from a site you do not control is how you accidentally steal someone else’s cookie. Including your own, in a shared browser profile.

What I put in CI versus what I enforce by hand

Numbered, because this is the only part that survives a week later:

Pre-commit: reject *.har unless it lives under fixtures/ and passes har_audit.py.
Agent allowlist: tools may read fixtures/ and /tmp/model-inbox, never ~/Downloads.
Human rule: if DevTools can see Set-Cookie, the model cannot see the file.
Recovery drill: rotate the canary session in the fixture repo on a schedule, so the rotate path is not theoretical.

The trend right now is to paste richer artifacts because models debug faster than we type. Faster is not a trust boundary. A HAR is a credential format that happens to end in .har.

So which invariant belongs in CI, and which layer should enforce it? I put “no session HAR in git or in the model inbox” in CI. I put “do not export production sessions” in the human layer, because no regex will save you from capturing the wrong browser profile. If you only pick one, pick the human rule. The script is there for the night you are tired and the 401 will not die.

Audit a git diff Before a Model Sees the Password You Deleted

jaryn — Wed, 16 Sep 2026 03:27:01 +0000

The patch looked harmless. A reviewer asked an agent to summarize a PR. The model got git diff origin/main...HEAD. In the deleted lines sat DB_PASSWORD=P@ssw0rd-from-staging. Nobody added a secret. They removed one. The model still saw it.

That is the failure. Not a novel exploit. A trust-boundary violation hiding in a minus line. Can your context packer tell the difference?

I did not pull this from a production incident. I keep a folder of failing patches because unified diffs are the most common thing teams feed a coding model, and deleted hunks are the least reviewed surface. If the packer ships the whole patch, the model inherits every secret that ever lived in that file during the branch.

The minus-line problem

Added lines get scrutiny. Deleted lines do not. Humans skim the green. Models consume both sides of a hunk. A revert of .env.local, a rollback of application.yml, or a “moved the token to CI” commit is a leak in disguise.

Ask the ugly question. If the password is gone from HEAD, is it gone from the prompt? Usually no.

Remote models make this worse: the secret leaves your network. Local or self-hosted models do not magically fix it. Prompt caches, debug logs, and operator consoles still sit on the other side of the same boundary. Free inference is not a privacy control.

Trust boundaries for a review agent

Treat the review path as four rooms. Secrets may exist in the workspace. They must not cross into model input.

[git working tree] --patch--> [context packer] --prompt--> [model runtime]
        |                           |                         |
   secrets OK                  MUST DENY                 never stores
   on disk                  secret-shaped            credentials by design

Three assets matter here:

Deleted credentials in unified diffs (- KEY=value).
Local override files that never belonged in a review (*.local, .npmrc, docker-compose.override.yml).
The packer’s own logs. If the packer prints the rejected prompt “for debugging,” you just moved the leak.

Threat actors are boring. A developer pasting a patch. A CI job that dumps git show. An agent that glob-reads **/* before the review prompt. None of them need to be malicious.

Fixtures: one must fail, one must pass

Label these as unexecuted templates. Pin the shape, not a CVE. I use Python 3.12 and a unified diff, nothing else.

Negative fixture (must fail the gate). A password appears only on a deleted line. HEAD is clean. The prompt is not.

--- a/.env.local
+++ b/.env.local
@@ -1,3 +1,3 @@
-DB_PASSWORD=P@ssw0rd-from-staging
+DB_PASSWORD=${DB_PASSWORD}
 LOG_LEVEL=info

Positive fixture (must pass). Public config only. No credential-shaped assignments in added or deleted hunks.

--- a/config/app.toml
+++ b/config/app.toml
@@ -1,3 +1,4 @@
 log_level = "info"
+feature_flags.refresh = true
 request_timeout_ms = 2500

Second negative fixture. An .npmrc auth token in an added line. Different file class, same invariant.

--- a/.npmrc
+++ b/.npmrc
@@ -1,2 +1,2 @@
 registry=https://registry.npmjs.org/
+//registry.npmjs.org/:_authToken=npm_1a2b3c4d5e6f

If your packer ships any of the negative patches to a model, the gate is missing. Do not call that “a finding in product X.” Call it a missing invariant in your pipeline.

A gate you can run before any model call

The rule is simple. Scan the patch the agent would receive. Fail closed on credential-shaped lines in both + and - hunks. Ignore file headers. Ignore hunk headers. Do not pretend this is DLP. It is a regression fixture.

Save as scan_diff_secrets.py:

#!/usr/bin/env python3
"""Fail closed if a unified diff still carries secret-shaped lines.

Unexecuted template. Tune patterns to your repo. Not a DLP product.
"""
from __future__ import annotations

import re
import sys
from pathlib import Path

SECRET_LINE = re.compile(
    r"""(?ix)
    (?:
        (?:password|passwd|secret|api[_-]?key|access[_-]?token|auth[_-]?token)
        \s*[=:]\s*\S+
      | _authToken\s*=\s*\S+
      | BEGIN\ (?:RSA|OPENSSH|EC)\ PRIVATE\ KEY
    )
    """
)

SKIP_PREFIXES = ("diff ", "index ", "--- ", "+++ ", "@@ ")


def offending_lines(patch: str) -> list[str]:
    hits: list[str] = []
    for raw in patch.splitlines():
        if not raw or raw.startswith(SKIP_PREFIXES):
            continue
        if raw[0] not in "+-" or raw.startswith(("+++", "---")):
            continue
        body = raw[1:]
        if SECRET_LINE.search(body):
            hits.append(raw)
    return hits


def main(argv: list[str]) -> int:
    if len(argv) != 2:
        print("usage: scan_diff_secrets.py <patch>", file=sys.stderr)
        return 2
    patch = Path(argv[1]).read_text(encoding="utf-8", errors="replace")
    hits = offending_lines(patch)
    if hits:
        print("REFUSE: secret-shaped lines in model-bound diff")
        for line in hits:
            print(f"  {line[:120]}")
        return 1
    print("ALLOW: no secret-shaped +/- lines")
    return 0


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

Wire it in front of the packer. Not after. Not “in the model system prompt.” After is a diary of the leak.

# Unexecuted template. Run in a throwaway clone.
git diff origin/main...HEAD > /tmp/review.patch
python3 scan_diff_secrets.py /tmp/review.patch
echo "exit=$?"

Expected evidence:

Fixture	Exit	Why
Deleted `DB_PASSWORD=...`	`1`	Minus line still enters the prompt
Added `_authToken=`	`1`	New secret in the review context
Public `app.toml` change	`0`	No credential-shaped assignment

If exit 1 does not block the HTTP call to the model, you built a linter, not a boundary. I want the packer to refuse. Do you?

Prevent, detect, recover

Layer	Action	What it actually enforces
Prevent	Allowlist files the packer may read (`.md`, `.toml`, `src/*`). Deny `.local`, `.env`, `.npmrc`, `id_rsa`, `.tfvars`, `*.pem`.	Secrets never become tokens.
Prevent	Run `scan_diff_secrets.py` on the exact bytes you would send.	Deleted hunks cannot sneak through.
Detect	Log hashes of refused patches, never the patch body, to the packer audit stream.	You can prove a deny without reprinting the password.
Recover	Rotate any credential that matched a refused pattern if the prompt might already have left the host.	The gate is not a time machine.

A system prompt that says “do not look at secrets” is not a row in this table. The model cannot unsee a minus line.

What still must not go to a model

Even a passing diff is not a blank check. Keep these out of prompts whether the runtime is remote, free, or in your rack:

Private keys and kubeconfigs (file contents, not just filenames).
Session cookies, Authorization headers, and signed URLs.
Production connection strings in stack traces.
Customer payloads sitting in fixture JSON.

A filename allowlist is cheaper than a regex. Regex is the backstop for the files you do send.

Where a self-hosted coding stack fits

The gate above is useful with any model. It stays useful if you strip every product name out of this article. The product question is only this: once the patch is clean, where does the prompt run?

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source AI development platform. Operator-supplied availability for evaluation includes free model access and a free server option. I am not attaching token quotas, hardware SKUs, or permanence claims here; those numbers rot, and a quota is not a trust boundary.

If you are evaluating a self-hosted coding stack, run the fixture against your context packer before you point a model at a real branch. Local inference can shrink the blast radius after the gate. It does not replace the gate.

Limitations — who should not use this

This scanner is a coarse regex over unified diffs. It will miss encodings, split strings, Kubernetes Secret YAML that uses data: base64, and secrets with unusual key names. It will false-positive on docs that say password=example. That is acceptable for a CI reject of model context. It is not acceptable as your only control for regulated data.

Do not use this approach if:

You need guaranteed DLP, redaction, or legal hold. Buy or build that separately.
Your agent reads files by glob and never produces a patch. Gate the glob, not git diff.
You plan to log refused prompts in plaintext “just for a week.” That week is the incident.

I would rather fail a review job than debug a leaked staging password in a model log. Which invariant belongs in CI, and which layer should enforce it: the packer, the model host, or both?

Build a CI Log Redaction Gate Before Incident Chat Hits a Model

jaryn — Sun, 13 Sep 2026 19:17:50 +0000

You know the 2 a.m. deploy that dies on docker push? Someone in the incident channel will say it. "Paste the CI log into the model. It will find the registry error faster than we will."

I opened the artifact anyway. Line 184 was not a registry error. It was echo "DEPLOY_TOKEN=$DEPLOY_TOKEN" from a debug step that never got reverted. The value was still live. Would you have spotted it before the prompt left your laptop?

That is the failure. Not a generic AI scare. A trust boundary moved, and nobody put a gate on it.

The boundary you actually crossed

A CI log is not a stack trace. It is a serialized execution trace from a privileged runner. The runner already saw deploy tokens, registry passwords, cloud OIDC assertions, and every echo a human added under stress.

Three hops. Three different owners.

flowchart LR
  Runner["CI runner\n(privileged env)"] -->|stdout / annotations| Store["Log backend\nGitHub, GitLab, Jenkins"]
  Store -->|browser, gh, curl| Human["Engineer clipboard\nor agent file-read"]
  Human -->|prompt / tool result| Model["Model context\nremote or self-hosted"]

Ask the ugly question. If the model runs on a server you control, does that make the paste safe? No. It only changes who can read the prompt later. The token still entered a context window, a swap file, and maybe a debug transcript.

What must never enter the prompt

I treat a CI log as hostile input until a gate says otherwise. Hostile does not mean malware. It means the file was produced by a job that was allowed to see secrets you are not allowed to republish.

Do not send these classes of lines. Not to a SaaS chat box. Not to a self-hosted assistant. Not to an MCP tool that "summarizes the failure."

Deploy and registry secrets: DEPLOY_TOKEN=, docker login, _PASSWORD=, npm_, ghp_, github_pat_.
Cloud long-lived keys and session material: AKIA, ASIA, aws_secret_access_key, STS-looking blobs.
Bearer and OIDC leftovers: Authorization: Bearer, ghs_, GitHub Actions id-token JSON.
Embedded credentials in URLs: https://user:pass@, x-access-token:.
Masking failures: values that look like *** on one line and plaintext on the next because add-mask ran too late.

Is a compile error fair game? Usually. Is a failed kubectl apply fair game? Only after you strip kubeconfig fragments and --token flags. Different layer. Same rule: if the runner needed a secret to produce the line, the model does not.

Fixture layout

I want a regression gate I can run on a laptop, in CI, and in front of any assistant. No live GitHub org. No production tokens. Canaries only.

ci-log-gate/
  gate.py
  fixtures/
    positive_compile.log
    negative_deploy_token.log
    negative_docker_login.log
  expected/
    positive.exit  -> 0
    negative.exit  -> 1

Label up front: this is an unexecuted template as published. Run it yourself. Do not take my word for the exit codes. I am not claiming I found a vulnerability in GitHub Actions, GitLab, or anyone's cluster. I am claiming the paste path has no invariant unless you add one.

Pinned runtime: Python 3.12, stdlib only (re, sys, pathlib). No extra packages. No network.

Step 1 — write the two logs you will actually test

Positive fixture. A real failure, zero secrets.

# fixtures/positive_compile.log
::group::Build
npm error code ELIFECYCLE
npm error errno 1
npm error app@1.4.2 build: `tsc -p tsconfig.json`
src/auth.ts(88,12): error TS2339: Property 'exp' does not exist on type 'unknown'.
##[error]Process completed with exit code 1.
::endgroup::

Negative fixture. A canary, not a credential. If this file ever appears in a model log, you rotate the canary and you treat the transcript as compromised.

# fixtures/negative_deploy_token.log
::group::Push
+ echo DEPLOY_TOKEN=canary-rotate-me-not-real
DEPLOY_TOKEN=canary-rotate-me-not-real
+ docker login ghcr.io -u robot --password-stdin
Error response from daemon: denied: denied
::endgroup::

Second negative, different shape, same class.

# fixtures/negative_docker_login.log
Evaluating ssh-agent...
##[debug]login with token ghp_CANARY_NOT_A_REAL_TOKEN_0000
remote: Invalid username or password.
fatal: Authentication failed for 'https://ghcr.example.invalid/org/app.git/'

Why two negatives? Because one regex that only catches DEPLOY_TOKEN= will miss ghp_. Gates that pass a single demo are theater.

Step 2 — fail closed in about sixty lines

#!/usr/bin/env python3
"""gate.py — refuse CI logs that still look like secret material."""
from __future__ import annotations

import re
import sys
from pathlib import Path

# Conservative. Prefer false positives on incident paste.
RULES: list[tuple[str, re.Pattern[str]]] = [
    ("deploy_token_assign", re.compile(r"DEPLOY_TOKEN\s*=\s*\S+", re.I)),
    ("github_pat", re.compile(r"\b(?:ghp|gho|ghu|ghs|ghr|github_pat)_[A-Za-z0-9_]+")),
    ("aws_access_key", re.compile(r"\b(?:AKIA|ASIA)[A-Z0-9]{16}\b")),
    ("bearer_header", re.compile(r"Authorization\s*:\s*Bearer\s+\S+", re.I)),
    ("url_userinfo", re.compile(r"https://[^\s/@:]+:[^\s/@]+@", re.I)),
    ("docker_password_stdin", re.compile(r"docker\s+login\b.*--password-stdin", re.I)),
    ("npm_token", re.compile(r"\bnpm_[A-Za-z0-9]{20,}\b")),
    ("x_access_token", re.compile(r"x-access-token:[^\s]+", re.I)),
]


def findings(text: str) -> list[tuple[str, int, str]]:
    hits: list[tuple[str, int, str]] = []
    for i, line in enumerate(text.splitlines(), start=1):
        for name, pat in RULES:
            if pat.search(line):
                hits.append((name, i, line[:200]))
    return hits


def main(argv: list[str]) -> int:
    if len(argv) != 2:
        print("usage: gate.py <log>", file=sys.stderr)
        return 2
    path = Path(argv[1])
    text = path.read_text(encoding="utf-8", errors="replace")
    hits = findings(text)
    if hits:
        print(f"FAIL {path} ({len(hits)} hit(s))")
        for name, line_no, snippet in hits:
            print(f"  [{name}] L{line_no}: {snippet}")
        return 1
    print(f"PASS {path}")
    return 0


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

Expected evidence, after you run it:

python3.12 gate.py fixtures/positive_compile.log
# PASS fixtures/positive_compile.log  ; echo $?
# 0

python3.12 gate.py fixtures/negative_deploy_token.log
# FAIL ... [deploy_token_assign] L3 ...
# FAIL ... [docker_password_stdin] L4 ... ; echo $?
# 1

python3.12 gate.py fixtures/negative_docker_login.log
# FAIL ... [github_pat] L2 ... ; echo $?
# 1

If the positive fixture ever fails, you tightened a rule too far. If a negative fixture ever passes, the gate is a lie. That is the whole test plan.

Step 3 — put the gate in front of the paste, not after the model

I do not want a human to remember this. Memory is not a control.

# Unexecuted wrapper. Point it at a downloaded run log, not at prod.
redact_or_die() {
  local src="$1"
  python3.12 gate.py "$src" || {
    echo "refusing to copy $src into clipboard or prompt" >&2
    return 1
  }
  # Only if you still need a human paste path:
  # xclip -selection clipboard < "$src"
}

Optional GitHub CLI path, also unexecuted, also fail-closed:

# gh run view 123456789 --log > /tmp/run.log
# python3.12 gate.py /tmp/run.log || rm -f /tmp/run.log

If an agent can cat the log file, the gate belongs in the tool wrapper, not in a style guide. A prompt that says "please do not read secrets" is not an invariant. A non-zero exit is.

What a free server buys you — and what it does not

I needed a place to iterate the gate without feeding a raw incident log to a random public chat box. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source AI development platform; the operator-supplied facts I am using are free model access and a free server option. That is the entire product claim here. No model names. No quota. No hardware story.

Why does that matter for this fixture? Because the evaluation question is a trust-boundary question, not a feature-matrix question.

Destination	Shrinks provider blast radius?	Stops secrets in the prompt?	Still writes transcripts / swap?
Public chat paste	No	No	Yes, on someone else's disk
Remote hosted agent with workspace tools	No	No, unless you wrap tools	Yes
Assistant on a server you control	Yes, for the provider hop	No	Yes, on your disk
No model until `gate.py` exits 0	N/A	Yes, for this class of leak	Nothing to write

A free server is useful when you want the model inside a domain you can wipe. It is useless as a substitute for redaction. Self-hosted is a different trust domain. It is not a different physics.

If you already run a local runtime, use that for the same loop. The gate does not care which assistant you were about to paste into. It cares whether line 184 still contains a token.

Prevent / detect / recover

Layer	Prevent	Detect	Recover
Runner	Delete debug `echo` of secrets. Mask before first print. Prefer OIDC over long-lived PATs.	Job diff review: new `echo $`, `set -x` near login, `curl -H Authorization`.	Rotate the secret the job used. Invalidate the run log if your platform allows it.
Log store	Retention + access control on job logs. Disable public reuse of failed-run artifacts.	Alert on `gate.py` hits when logs land in an internal bucket.	Purge the artifact. Treat downstream copies as live.
Human paste	Wrapper refuses clipboard copy on exit 1.	Canary token unique to the incident channel.	If the canary appears in a model transcript, rotate and assume prompt-cache exposure.
Agent / MCP	Tool allowlist cannot `cat` `*/.log` until the gate passes.	Tool-result scanner using the same `RULES`.	Drop the session. Wipe local transcripts on the server you control.
CI of the gate	Negative fixtures must fail. Pin Python 3.12.	`gate.py` on its own fixtures in PRs.	If a negative goes green, block merges. The invariant died.

Notice what is missing. There is no row that says "trust the model to ignore the secret." That row does not exist.

Limitations — who should not use this

This gate is a regex fence around a text log. That is a feature and a warning.

Do not use it as your only control if you are in a regulated environment that already requires a DLP product, customer-key encryption, or legal hold on CI artifacts. Regex will miss binary build logs, gzip-wrapped runner archives, multiline PEM blocks split every 64 characters, and secrets that were base64'd twice. It will also false-positive on documentation that discusses docker login --password-stdin. Good. Fail closed on incident paste. Tune later on a corpus you can actually share.

Do not use canary strings that resemble production token prefixes in a repo that publishes logs. canary-rotate-me-not-real is boring on purpose. Do not paste a live ghp_ into the negative fixture "just to be realistic." Realistic is how tokens escape.

Do not skip rotation because "it was only a self-hosted model." Disk, core dumps, and admin access still exist. If the line crossed into the context window, the secret's remaining lifetime is an incident-response question, not a product-tier question.

Which invariant belongs in CI?

Two invariants. They do not live on the same layer.

Invariant A: no job log that still matches RULES is eligible for clipboard, MCP, or agent file-read. Enforce that next to the assistant, or you will keep losing to 2 a.m. Slack advice.

Invariant B: the gate itself cannot go green on fixtures/negative_*.log. Enforce that in your CI, on every change to gate.py.

A is a runtime boundary. B is a regression boundary. If you only keep B, engineers will still paste the raw file. If you only keep A, someone will "fix" a noisy regex and silently disarm the control.

So: which layer should refuse the paste in your shop — the wrapper in front of the model, or the pipeline that produced the log? If the answer is "the model will be careful," you do not have an answer yet.

If you want a self-hosted workspace to exercise this gate against an assistant instead of a public chat box, MonkeyCode is open source and currently offers free model access plus a free server option. Run the negatives first. Then decide whether the model is allowed to see the file.

Reproduce a Bearer Leak From an OTel JSON Export You Fed to a Model

jaryn — Sat, 12 Sep 2026 17:16:19 +0000

The export looked harmless. A 48 KB trace.json from a local Jaeger query, one HTTP client span, p99 stuck at 1.8s. I was one paste away from asking a coding assistant why checkout stalled on POST /pay.

Then I grepped the file. http.request.header.authorization sat in span.attributes as Bearer eyJhbGciOi.... That is the whole incident. No production dump. No vendor bug report. A throwaway fixture I generated so the paste would fail before a model context window became a log sink.

Would you ship that JSON to a remote tokenizer? I would not. The failure is not "AI is risky." The failure is a missing trust boundary between an observability export and a prompt.

The trust boundary, drawn once

OpenTelemetry is a debug surface. A model is a third party, even when it runs on a box you own. Those are not the same room.

flowchart LR
  App[App SDK] -->|OTLP| Collector
  Collector --> Backend[Jaeger / Tempo]
  Backend -->|export JSON| Laptop
  Laptop -->|redact gate| Prompt[Prompt builder]
  Prompt -->|allowlisted attrs only| Model
  Laptop -.->|raw paste| Model

The dotted line is the bug. Everything left of redact gate may legally contain a Bearer token, a Cookie, a db.connection_string, or a session.id that maps to a person. Everything right of it should not.

Ask the ugly question early: which process is allowed to see Authorization? If the answer is "the collector, maybe the backend, never the model," you already have an invariant. The rest of this article is that invariant as a fixture.

Minimal failing export

I did not scrape a live cluster. I wrote a span that matches what HTTP instrumentations emit when header capture is on. Treat this as a lab fixture, not evidence of a CVE.

Pinned for the lab: Python 3.12, pytest==8.3.3. No OTel SDK required to fail the test.

{
  "resourceSpans": [{
    "scopeSpans": [{
      "spans": [{
        "name": "POST /pay",
        "attributes": [
          {"key": "http.method", "value": {"stringValue": "POST"}},
          {"key": "http.route", "value": {"stringValue": "/pay"}},
          {"key": "http.status_code", "value": {"intValue": 504}},
          {"key": "http.request.header.authorization",
           "value": {"stringValue": "Bearer eyJhbGciOiJIUzI1NiJ9.lab-fixture"}},
          {"key": "http.request.header.cookie",
           "value": {"stringValue": "sid=s%3Alab.fixture"}},
          {"key": "db.connection_string",
           "value": {"stringValue": "postgres://app:lab-pass@db.internal:5432/pay"}}
        ]
      }]
    }]
  }]
}

Save it as fixtures/trace.negative.json. That file must never become prompt context. If your assistant workflow cannot reject it, you do not have a gate. You have a habit.

Positive twin: fixtures/trace.positive.json. Same shape, no secrets. Keep http.method, http.route, http.status_code, net.peer.name, duration. That is the debug signal. The Bearer is not.

What actually leaks, and what does not

I keep a short allow/deny list next to the fixture. It is boring on purpose.

Attribute / field	Send to a model?	Why
`http.method`, `http.route`, `http.status_code`	Yes	Needed to reason about the stall
`http.request.header.authorization`	Never	Credential
`http.request.header.cookie` / `set-cookie`	Never	Session
`db.connection_string`, `db.user`, `db.statement` with literals	Never	Credential + possible PII
`enduser.id`, `user.email`	Never by default	Identifier
span `events` with exception `stacktrace`	Maybe	Can embed DSNs from config loaders
resource `service.name`, `service.version`	Yes	Identity of the binary, not the caller
`trace_id` / `span_id`	Team policy	Correlates to production traffic

Is trace_id a secret? Usually no. Is it a join key into a system the model should not see? Sometimes yes. I treat join keys as confidential when the backend is production.

Reproduce the leak with a 40-line gate

The gate is a pure function. No network. No model. If this function is green, you still have not proved the assistant is safe. You have proved the export is.

# redact_otel.py — lab fixture, not a production redactor
from __future__ import annotations

import json
import re
from typing import Any, Iterable

DENY_KEY_FRAGMENTS = (
    "authorization",
    "cookie",
    "set-cookie",
    "x-api-key",
    "api_key",
    "api-key",
    "secret",
    "password",
    "connection_string",
    "enduser.id",
    "user.email",
)

DENY_VALUE = re.compile(
    r"(?i)(bearer\s+[a-z0-9._\-]+|postgres://\S+|mysql://\S+|sid=\S+)"
)

REDACTED = "[REDACTED]"


def _key_denied(key: str) -> bool:
    k = key.lower()
    return any(frag in k for frag in DENY_KEY_FRAGMENTS)


def walk(node: Any) -> Any:
    if isinstance(node, dict):
        key = node.get("key")
        if isinstance(key, str) and "value" in node:
            if _key_denied(key):
                return {"key": key, "value": {"stringValue": REDACTED}}
            value = node["value"]
            if isinstance(value, dict) and "stringValue" in value:
                if DENY_VALUE.search(value["stringValue"] or ""):
                    return {"key": key, "value": {"stringValue": REDACTED}}
        return {k: walk(v) for k, v in node.items()}
    if isinstance(node, list):
        return [walk(x) for x in node]
    return node


def forbidden_hits(node: Any, acc: list[str] | None = None) -> list[str]:
    acc = acc if acc is not None else []
    if isinstance(node, dict):
        key = node.get("key")
        if isinstance(key, str) and _key_denied(key):
            val = node.get("value", {})
            text = val.get("stringValue", "") if isinstance(val, dict) else ""
            if text and text != REDACTED:
                acc.append(key)
        for v in node.values():
            forbidden_hits(v, acc)
    elif isinstance(node, list):
        for x in node:
            forbidden_hits(x, acc)
    return acc


def load(path: str) -> Any:
    with open(path, encoding="utf-8") as f:
        return json.load(f)

Pytest, two directions. Negative fixture must be caught. Positive fixture must survive.

# test_redact_otel.py
import json
from redact_otel import forbidden_hits, load, walk, REDACTED

def test_negative_export_is_rejected():
    raw = load("fixtures/trace.negative.json")
    hits = forbidden_hits(raw)
    assert "http.request.header.authorization" in hits
    assert "db.connection_string" in hits

def test_negative_export_redacts_bearer_and_dsn():
    raw = load("fixtures/trace.negative.json")
    cleaned = walk(raw)
    blob = json.dumps(cleaned)
    assert "eyJhbGciOi" not in blob
    assert "lab-pass" not in blob
    assert REDACTED in blob
    assert forbidden_hits(cleaned) == []

def test_positive_export_keeps_route_and_status():
    raw = load("fixtures/trace.positive.json")
    assert forbidden_hits(raw) == []
    cleaned = walk(raw)
    blob = json.dumps(cleaned)
    assert "/pay" in blob
    assert "504" in blob

Run it:

python -m pytest -q test_redact_otel.py

Expected on the negative file before walk: assertion finds http.request.header.authorization. Expected after walk: the JWT substring is gone. If your first run is all green without a negative fixture, the test is lying. Add the failing export first. Then make it fail closed.

Prevent / detect / recover

A redactor in a gist is not a control. Name the layer.

Layer	Prevent	Detect	Recover
SDK	Do not capture `Authorization` / `Cookie`. Turn header capture off unless a named allowlist exists.	CI grep for `OTEL_INSTRUMENTATION_HTTP_CAPTURE_HEADERS` and for `http.request.header.authorization` in golden traces	Rotate the token the span held; treat the export as a credential dump
Collector	Attribute processor drops deny-listed keys before storage	Collector debug log sampled without values; metric on dropped keys	Flush or re-process the bad batch; mark the backend index tainted
Export CLI	`jq` / this fixture as a required pipe before clipboard	Pre-commit or Make target: `pytest test_redact_otel.py`	Delete `trace.json` from disk and chat history
Prompt builder	Refuse to attach any `.json` unless `forbidden_hits` is empty	Unit test on the builder, not on the model	Invalidate the thread; do not "ask the model to forget"
Model host	Network egress allowlist; no default path to a public tokenizer	Prompt-size + attachment hash logged locally, not the body	Rotate anyway; the host is not your source of truth

Notice recover always includes rotate. Redaction after a paste is not recovery. The bytes already left.

Where a self-hosted assistant still sits behind this gate

I evaluate coding assistants the same way I evaluate log shippers: what crosses the boundary, and who can read the buffer.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source AI development platform with free model access and a free server option, which is enough to stand up a local prompt path and point this fixture at it. That is the only product fact this workflow needs. I am not pinning model names, quotas, or hardware here; those change, and a stale number is worse than silence.

Self-hosting moves the tokenizer. It does not delete Bearer eyJ... from trace.json. A teammate with disk access, a crash dump, a session recorder, or a "helpful" debug log of prompts will still see it. If you use a self-hosted path, run forbidden_hits in the prompt builder before the bytes hit localhost. Localhost is not a policy.

If you want one check against that path: export the negative fixture, attach it the way you would attach a Jaeger dump, and confirm the builder rejects it. If the builder cannot reject, do not debug production traces there. Debug the builder.

Commands I actually keep next to the fixture

Unexecuted until you wire them to your backend. Labels matter.

# 1) Confirm the raw export still contains a deny-listed key (lab file).
grep -n "authorization" fixtures/trace.negative.json

# 2) Fail closed in CI. No model invocation.
python -m pytest -q test_redact_otel.py

# 3) Optional clipboard pipe for humans who insist on interactive debug.
# Template — unexecuted. Replace jaeger-export.json with a file you own.
python - <<'PY'
from pathlib import Path
from redact_otel import walk, forbidden_hits, load
import json, sys
p = Path("jaeger-export.json")
data = load(p)
hits = forbidden_hits(data)
if hits:
    print("refusing export; keys:", hits, file=sys.stderr)
    sys.exit(2)
Path("jaeger-export.redacted.json").write_text(json.dumps(walk(data), indent=2))
print("wrote jaeger-export.redacted.json")
PY

Do not curl a production Jaeger into this. Copy a synthetic span first. If you cannot explain every attribute in the file, you are not ready to paste it.

Limitations — read these before you copy the regex

This approach is a regression fixture for a known shape: OTLP JSON with key / stringValue pairs. It is not a DLP product.

Nested protobuf, zipkin v1, Tempo parquet, or a screenshot of Grafana will bypass it. Different codec, different test.
Base64 blobs, JWTs split across events, and db.statement with inline emails need parsers you have not seen above. I did not pretend to write those.
Allowlisting http.route can still leak identifiers if your routes are /users/{email}.
DENY_VALUE is a coarse regex. It will false-positive on the word "bearer" in a comment span. Good. Fail closed, then add an allow.
A green pytest does not prove your assistant UI skipped the file input. Test the builder, or you tested a script nobody runs.

Who should not use this as their only control: teams under a legal hold that must retain raw traces; teams whose model already runs inside the same confidentiality domain and whose prompt store is production-grade; anyone hoping a redactor will make it acceptable to paste live customer traffic. It will not. Use a scrubbed staging trace.

Who should use it: platform and security engineers who already dump spans when latency spikes, and who have started feeding those dumps to a coding assistant. If that is you, the invariant belongs in CI, not in a wiki.

The boundary question

I want one line in the pipeline, not a culture speech. Does forbidden_hits run in CI on every golden trace and on the prompt builder, or only in a gist you remember after the leak?

The SDK should stop recording Authorization. The collector should drop it anyway. The prompt builder should refuse the file if either layer missed. Three layers, one invariant. Which of those three can you prove with a fixture tonight?

Audit WAF Block Logs Before a Model Sees the Cookie You Stopped

jaryn — Fri, 11 Sep 2026 15:12:22 +0000

The WAF did its job. The request never hit the app. Then I copied the block log into a coding model and asked a reasonable question: is this SQLi, or a noisy false positive?

The model answered. It also received a Cookie header, a Bearer token, and a session id hanging off the query string. The attacker never reached origin. I handed the session to whatever sits behind the prompt API anyway. Sound familiar?

This is a lab drill, not a production write-up. No live tenant was involved. The failure mode is still real: a control that blocks a request does not automatically produce a sanitized artifact. If you paste the artifact, you moved the trust boundary.

The paste is the privileged action

A WAF sits on the client-to-origin path. Your clipboard sits on the engineer-to-model path. Those are not the same boundary. Confusing them is how a blocked cookie becomes a prompt.

flowchart LR
  Client -->|HTTPS request| WAF
  WAF -->|allow / block| Origin
  WAF -->|block event| LogStore
  LogStore -->|export / copy| Engineer
  Engineer -->|prompt pack| ModelRuntime

Ask the ugly question out loud. Who is allowed to see Cookie? The WAF process, maybe the SIEM, maybe an on-call who already has prod access. A remote completion API is not on that list. A shared GPU box is not on that list either, even when nobody invoices you for it.

I treat three facts as non-negotiable in this drill:

Block logs are hostile input. They contain attacker payloads and whatever the browser attached.
Query strings are headers in disguise. Tokens show up there because someone was lazy in 2019 and the client never got patched.
"I only pasted one line" is not a control. One line is enough.

What a review pack is allowed to contain

I want a model to help classify a rule hit. I do not want it to reconstruct a session. So the prompt pack gets an allowlist, not a speech about being careful.

Allowed fields in this fixture:

ts, method, path with no query string, status, rule_id, action, latency_ms, proto

Denied on sight:

Cookie / Set-Cookie
Authorization
X-Api-Key / X-Auth-Token
JWT-shaped strings
access_token, id_token, refresh_token, sessionid, sid in a query
raw request bodies
the original URL with ? still attached
extra JSON keys the allowlist never named

Why deny extra keys? Because WAF exporters love "helpful" fields. raw_request. header_map. decoded_body. One extra key and your allowlist was theater.

Is source IP sensitive? Sometimes. I left it out of the allowlist on purpose. You can add it back if your IR runbook needs it and the model runtime is inside the same trust zone as the SIEM. That is a policy choice. It is not the default.

Lab fixture, pinned and labeled

Pinned runtime: Python 3.12. This template was not executed against a live WAF. It is a regression gate for a prompt pack. If you point it at production logs, you own the redaction policy, not this article.

Positive fixture — must fail. Structured event plus a raw combined-style line. Both leak.

# fixtures/positive.log
{"ts":"2026-09-11T02:14:08Z","method":"POST","path":"/login?access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJsYWIifQ.labfixturetoken","status":403,"rule_id":"sql-1","action":"block","latency_ms":12,"cookie":"session=abc"}
02:14:08 POST /admin HTTP/1.1 403 Authorization: Bearer lab-token-32chars Cookie: sid=1

Negative fixture — must pass. Same attack class. No credentials in the pack.

# fixtures/negative.log
{"ts":"2026-09-11T02:14:08Z","method":"POST","path":"/login","status":403,"rule_id":"sql-1","action":"block","latency_ms":12,"proto":"HTTP/1.1"}

Expected failure evidence on the positive file: non-zero exit, at least one finding named json_keys_outside_allowlist, path_contains_query, access_token_qs, cookie_header, authorization_header, or jwt_like. Expected evidence on the negative file: exit 0 and ok.

#!/usr/bin/env python3
"""Refuse to pack WAF/block logs that still contain secrets. Lab fixture."""
from __future__ import annotations

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

DENY_PATTERNS = [
    ("authorization_header", re.compile(r"(?i)authorization\s*[:=]\s*bearer\s+\S+")),
    ("cookie_header", re.compile(r"(?i)\bcookie\s*[:=]\s*\S+")),
    ("set_cookie", re.compile(r"(?i)set-cookie\s*[:=]")),
    ("jwt_like", re.compile(
        r"\beyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\b"
    )),
    ("access_token_qs", re.compile(
        r"(?i)(access_token|id_token|refresh_token|sessionid|sid)="
    )),
    ("api_key_header", re.compile(r"(?i)(x-api-key|x-auth-token)\s*[:=]\s*\S+")),
]

ALLOW_KEYS = {
    "ts", "method", "path", "status", "rule_id", "action", "latency_ms", "proto",
}


def findings_in_text(blob: str) -> list[tuple[str, str]]:
    hits: list[tuple[str, str]] = []
    for name, cre in DENY_PATTERNS:
        match = cre.search(blob)
        if match:
            hits.append((name, match.group(0)[:80]))
    return hits


def findings_in_line(line: str) -> list[tuple[str, str]]:
    try:
        obj = json.loads(line)
    except json.JSONDecodeError:
        return findings_in_text(line)
    if not isinstance(obj, dict):
        return findings_in_text(line)
    hits: list[tuple[str, str]] = []
    extra = sorted(set(obj) - ALLOW_KEYS)
    if extra:
        hits.append(("json_keys_outside_allowlist", ",".join(extra)))
    packed = " ".join(str(obj.get(k, "")) for k in ALLOW_KEYS if k in obj)
    hits.extend(findings_in_text(packed))
    path = obj.get("path")
    if isinstance(path, str) and "?" in path:
        hits.append(("path_contains_query", path[:80]))
    return hits


def scan(path: Path) -> list[tuple[int, str, str]]:
    out: list[tuple[int, str, str]] = []
    for i, line in enumerate(path.read_text(encoding="utf-8").splitlines(), 1):
        if not line.strip() or line.startswith("#"):
            continue
        for name, snippet in findings_in_line(line):
            out.append((i, name, snippet))
    return out


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--input", type=Path, required=True)
    parser.add_argument("--expect", choices=("pass", "fail"), required=True)
    args = parser.parse_args()
    hits = scan(args.input)
    if hits:
        for line_no, name, snippet in hits:
            print(f"FAIL line={line_no} rule={name} snippet={snippet!r}")
        failed = True
    else:
        print("ok")
        failed = False
    if args.expect == "fail" and not failed:
        print("expected findings, got a clean pack")
        return 2
    if args.expect == "pass" and failed:
        return 1
    return 0


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

Numbered run

Do not start by arguing about model vendors. Start by proving the gate fails closed.

Save the script as waf_log_prompt_gate.py and the two fixtures next to it.
Run the negative path first. If this fails, your allowlist is wrong, not the model.
Run the positive path. If this passes, the gate is lying and you will paste cookies again.
Only then export a real block event, strip it to the allowlist, and re-run with --expect pass.
Keep the original event in the SIEM. The model never needs the original.

python3 --version   # expect Python 3.12.x
python3 waf_log_prompt_gate.py --input fixtures/negative.log --expect pass
python3 waf_log_prompt_gate.py --input fixtures/positive.log --expect fail

If step 3 prints expected findings, got a clean pack, stop. You do not have a detector. You have a comment in a wiki.

Prevent, detect, recover

Layer	Prevent	Detect	Recover
WAF export	Disable `raw_request` / full header dumps on the default copy action	Alert when an export includes `cookie` or `authorization` keys	Rotate the session family in that log line, do not debate whether the model "used" it
Engineer laptop	Gate the prompt pack with the fixture above	Fail CI or a pre-commit hook on `prompt-pack.json`	Treat clipboard history as contaminated; clear it
Model runtime	Send allowlisted fields only	Log prompt hashes and field names, never values	Assume vendor or disk retention; rotate anyway
App session	Short-lived cookies, sender-constrained tokens where you can	WAF rule on token-in-query	Invalidate `sid` / refresh tokens from the timestamp of the paste

Notice what is missing: "ask the model to ignore secrets." That is not a control. Models do not enforce your privacy policy. They complete text.

Self-hosted inference moves the boundary. It does not delete it.

Remote model APIs are the obvious leak. People then switch to a box under their desk and relax. Why? Because "it is our GPU" feels like a security property. It is not. It is a location.

Disk snapshots, shared operator access, prompt caches, and the next intern's tmux session still see the pack. If you review WAF events with a coding assistant, redact before the bytes leave the log store. The runtime should receive the allowlisted JSON, nothing else.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source AI development platform with free model access and a free server option. I care about that here for one reason: you can keep the review of a sanitized block event on infrastructure you operate. That does not authorize a raw Cookie header on the prompt. If the gate in this article fails, do not send the file, including to a server you like.

A self-hosted option is a placement decision. The invariant is still "no session material in the prompt pack."

Limitations, and who should skip this

Regex is not a HTTP parser. Encoded cookies, split headers, chunked bodies, gzip, and protobuf exporters will walk around these patterns. Multipart uploads will too. Homoglyphs in header names will too. If your WAF writes binary objects into object storage, this script will not save you.

The allowlist also drops forensic detail on purpose. Path-plus-query can be the whole incident. If you are in active IR and you need the original bytes, do not use a coding model as the viewer. Use the SIEM, a ticket with access control, and people who already hold prod credentials.

Skip this approach if:

you do not own the log pipeline (you will fight the export format forever)
you need full PCAP or request-body reconstruction in the same window as model review
your "WAF" is a CDN dashboard you cannot strip before download
you want a magic prompt that makes leaking safe

This fixture does not prove a vendor trained on your data. It proves you were about to hand them the session. Those are different claims. Keep them separate.

Which layer owns the invariant?

I want the export button to be the enforcement point. CI on a prompt-pack file is the regression test. The model runtime is the last chance, and last chances fail.

So here is the boundary question I actually want answered in a review: does the WAF console refuse to copy denied fields, or do we keep relying on an engineer to run a Python gate after the clipboard already lost?

If you already evaluate self-hosted coding workspaces, put the gate in front of the prompt pack before the first completion — including on a free server. The interesting part is not the product. It is whether the cookie you blocked is still sitting in the JSON you were about to paste.