Name Every Door Before the Prompt Leaves

You should hold a prompt until you can name every room it will enter, because each room is a new trust boundary. A model service, a hosted server, and your own log pipeline are three different rooms even when one vendor offers all three. Free access does not shrink those rooms, and a friendly price does not change who can read what you paste. The useful habit is to label the payload, refuse the hot fields, and only then decide whether a remote run is acceptable.

The mistake usually starts with convenience, which feels like one door when the path is really a hallway. You paste a stack trace to explain a bug, and the trace still carries a connection string from the process environment. You attach a config snippet to show a path, and the snippet still carries a token that your linter never flagged. You then ask a hosted model to edit that same tree on a remote server, so one gesture crosses two boundaries.

Treat that gesture as a transfer, not as a chat, and the threat model becomes easier to draw on paper. Your laptop is the room you control, while the model endpoint is a room you only rent for a reply. The server is a third room, because it stores files and runs commands after the chat window has already closed. Logs form a fourth room, since retention and support access often outlive the session that created them.

If you cannot say which of those four rooms will see a given field, you are not ready to send the field. A request identifier can move, while the authorization header on the next line cannot, even though both arrived together. A file path can reveal a customer name or a private repository that you never intended to publish. You can keep the exception type and the line number, and you should drop the headers, the query string, and the body.

MonkeyCode enters this walkthrough only as one option where a free model path and a free server option may sit behind those doors. Disclosure: This article was prepared as part of MonkeyCode's product outreach. You should read the current terms yourself before you rely on either offer, because availability language goes stale faster than most posts. This article does not name models, quotas, hardware, or a promised duration, because those details were not verified from a primary page here.

If a product page advertises a token grant or a free machine, treat that page as the source of truth. Check the page on the day you start, because a number copied from an old thread is not evidence. A screenshot without a date is not a contract, and a recycled paragraph cannot enroll you. You can use the offer after you confirm it, and the security decision stays the same when the invoice is zero.

The fields you should never send are the ones that grant access, identify a person, or reconstruct a private system. A cloud key, a session cookie, a private key block, and a database URL all sit in the first class. Customer names inside a frame, raw request bodies, and unredacted support notes sit in the second class. Internal hostnames, tenant bucket names, and full environment dumps sit in the third class even when they look like ordinary debugging detail.

A useful analogy is a hotel hallway rather than a locked diary, because each door has a different reader behind it. The model door is read by a service that produces text, and that service may retain prompts under a policy you have not opened. The server door is read by a machine image that can copy your tree into a workspace you do not administer. The log door is read later by search tools, billing jobs, and sometimes a person who is debugging your debugging.

You need a local gate that fails closed, because a careful intention does not survive a tired paste at the end of the day. Copy the candidate text into a fixture, run the classifier, and read the verdict before you open a chat box. The classifier does not need to understand your product, since pattern refusal is enough to stop the obvious leaks. Rewrite the fixture until the verdict is clean, and allow only that clean fixture to cross any remote boundary.

A gate that fails closed

The script below is a proposed local gate, and you should run it on your own samples before you trust its patterns. It knows three outbound destinations, and it refuses to treat your laptop as a destination because the laptop is the source. It looks for assignment-style secrets, private key banners, common connection URLs, a familiar cloud key shape, bearer tokens, and email addresses. A match prints the rule name and returns a nonzero status, which is the signal your wrapper should treat as stop.

#!/usr/bin/env python3
"""Proposed local gate. It labels outbound text and never calls a model."""

import re
import sys
from pathlib import Path

DESTINATIONS = ("model", "server", "logs")

RULES = [
    (
        "assignment_secret",
        re.compile(
            r"(?i)\b(?:api[_-]?key|secret|token|password|passwd)\b\s*[:=]\s*\S+"
        ),
    ),
    (
        "private_key",
        re.compile(r"-----BEGIN (?:RSA |OPENSSH |EC )?PRIVATE KEY-----"),
    ),
    (
        "connection_url",
        re.compile(r"(?i)\b(?:postgres|mysql|mongodb|redis|amqp)://\S+"),
    ),
    ("cloud_key_shape", re.compile(r"\bAKIA[0-9A-Z]{16}\b")),
    ("bearer_token", re.compile(r"(?i)\bBearer\s+\S+")),
    (
        "email_address",
        re.compile(r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b"),
    ),
]


def classify(text):
    found = []
    for name, pattern in RULES:
        if pattern.search(text):
            found.append(name)
    return found


def main():
    if len(sys.argv) != 3:
        print("usage: boundary_gate.py <model|server|logs> <file>")
        return 2
    destination = sys.argv[1]
    path = Path(sys.argv[2])
    if destination not in DESTINATIONS:
        print("refuse destination=unknown")
        return 2
    text = path.read_text(encoding="utf-8")
    hits = classify(text)
    if hits:
        for name in hits:
            print(f"refuse field={name} destination={destination}")
        return 1
    size = len(text.encode("utf-8"))
    print(f"allow destination={destination} bytes={size}")
    return 0


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

You can create two fixtures and compare them with the same command shape, which keeps the ritual boring enough to repeat. The hot fixture should fail for model, server, and logs, because a secret stays hot in every rented room. The clean fixture should pass those same three destinations, and the allow line should mention only a byte count. If the hot fixture ever exits zero, you have a broken pattern, and you should fix the gate before you fix the prompt.

mkdir -p fixtures
cat > fixtures/stack_hot.txt << 'EOF'
CheckoutError: timeout in charge_card
Authorization: Bearer ya29.example-not-a-real-token
[email protected]
DATABASE_URL=postgres://app:[email protected]:5432/shop
EOF
cat > fixtures/stack_clean.txt << 'EOF'
CheckoutError: timeout in charge_card
status=504
hint=upstream timed out before capture
EOF
python3 boundary_gate.py model fixtures/stack_hot.txt
python3 boundary_gate.py server fixtures/stack_hot.txt
python3 boundary_gate.py logs fixtures/stack_hot.txt
python3 boundary_gate.py model fixtures/stack_clean.txt
python3 boundary_gate.py server fixtures/stack_clean.txt
python3 boundary_gate.py logs fixtures/stack_clean.txt

Imagine a synthetic checkout trace that includes a bearer token, a customer email, and a postgres URL on three lines. You want help with the exception class, so you keep the class name, the status code, and the function name in the clean fixture. You delete the bearer line, you replace the email with a placeholder, and you replace the URL with the word database. You then run the gate against model, server, and logs, and you send the prompt only after all three runs exit zero.

That sequence is the whole method, and it is deliberately slower than pasting the terminal straight into a chat box. The slowness is the control, in the same way a badge reader is slower than an open lobby. You are not hiding the bug from the model, and you are hiding credentials from every room but your own. A model can still explain a timeout when the token and the mailbox are gone, because the failure shape remains.

There is a second decision after the gate, and it concerns what the server is allowed to hold even when the prompt is clean. A clean prompt can still travel with a dirty tree if you upload the real repository to a machine you do not run. Environment files, shell history, and editor swap files skip the prompt check unless you point the script at them too. Run the same script over those files before any sync, and keep the remote copy limited to what you already chose to share.

Where the gate stops

This gate has sharp limits, and you should say them out loud before you trust a green exit code. Regular expressions miss secrets that are split, encoded, or named in a way the rules do not expect. They also miss private meaning with no classic shape, and they can flag a harmless email you meant to keep. A clean result means those known patterns were absent, and it does not mean the text is safe for every legal regime.

You should not use this approach as your only control if you handle health records, payment data, or material under a written retention contract. You should not use it if a green script would persuade you to skip reading the host policy. You should not use it if your team needs centralized revocation, audit exports, or a reviewer who did not write the prompt. In those settings you need an approved data-loss process, and a local fixture check is only a rehearsal.

A free server option changes the cost conversation, and it does not change the custody conversation in any important way. Someone else still schedules the machine, images the disk, and decides how long a forgotten workspace remains mounted. You can enjoy the lower cost after the gate is green, and you should still assume the room can be inspected. If that assumption feels too strict for the data in front of you, keep the run on the laptop and send nothing.

When you want a remote practice room, confirm current free model access and the free server option on MonkeyCode's own page. Enroll only after that check, then send a fixture this gate has already marked clean for every destination. If the page no longer matches what you expected, believe the page and keep the payload local until the terms are clear. The boundary work remains useful even if you never create an account, because the four rooms exist on every host.