Stop Sensitive Data Before It Reaches the Agent

You want a document assistant to help prepare a workshop: how many reusable name cards do we need to obtain, and what should we ask the supplier? The folder offered for the job contains useful instructions, stock records, an internal agenda, a customer contract and a support log. Uploading everything would give the assistant more material than the job needs.

You will prepare a small, permitted input and turn it into a usable preparation note. Start in your file manager and text editor, before opening the folder in an AI tool. Later, in an already installed OpenCode Desktop, use Open project, New session and Changes to give one agent a bounded file task and inspect its result. A chat assistant already approved for your task is another valid route: paste only the prepared input and save the response yourself.

The optional document-library example supplies the design idea: ask useful questions across documents. Here you practice the intake decision before upload or indexing. Indexing means processing documents into a searchable collection; it may expose content before you ask your first question. You do not need to build a library, a search system or an application.

Keep your own useful task if you have one: summarize an approved contract, prepare a lab handoff, explain a permitted error report or organize public information. The workshop below is a complete synthetic route when your real material is unavailable or unsuitable.

Learning objectives

After this lesson, you can:

• classify exact proposed inputs as green, yellow or red, with reasons and a next action;
• distinguish permission to use information from removing unnecessary information;
• preserve a useful task while making a smaller permitted input or an independent synthetic substitute;
• name the tool, account, purpose, data class and configuration that need approval;
• approve a narrow project boundary without weakening tool permissions;
• produce and improve a preparation note or equivalent learner-chosen result;
• refuse an out-of-scope request and recover from inaccurate output or accidental disclosure; and
• record unknown provider, retention and logging facts honestly.

Core concepts

Classify the input, not the innocent-sounding task

“Make a summary” describes an operation. It says nothing about whether the source contains a participant's identity, a negotiated price or a password. The disclosure can happen when the prompt, attachment or tool-read content reaches a service, before an answer appears.

Use the following colors as an intake aid, then apply your actual organization's rules. These labels are illustrative, not institutional policy or a legal classification system.

Green still has conditions: public text may have license or purpose restrictions. Yellow means a decision is missing, not “probably fine.” Red does not become green because you remove a name. Rare events, dates, roles, locations and free text can identify someone in combination. Commercial or unpublished content may remain confidential even if it identifies nobody.

Active passwords, tokens, API keys, private keys and session cookies do not belong in prompts. Never send a real secret to see whether the agent refuses it. At the point of discovery, leave it out; if it has already been exposed, use the incident guidance below.

Permission and minimization answer different questions

Permission: may this material be processed through this route for this purpose?

Minimization: among the permitted material, what does this task actually need?

A useful approval names the combination:

tool + managed account + purpose + data class + configuration

An installed, paid, popular or enterprise-branded product is not automatically approved for every input. A colleague's use is not your authorization. OpenCode Desktop runs an interface on your computer, but the selected model may run through a remote provider. Tools, connectors, logs, telemetry, backups and sharing can create additional paths. “I opened it locally” does not prove that the data stayed local.

For real work, confirm the applicable route before submission. For this exercise, use a route already approved for synthetic training material. Do not create an account or enter credentials just to complete the book. If approval is unavailable, you can still prepare the local input, request and handoff; record execution as blocked.

Minimization is not certified anonymity. A permitted excerpt can preserve identifying or confidential context. If permission or identifiability remains unresolved, keep the material yellow/red and ask the responsible person. Do not ask a remote model to sanitize a file it should never receive.

Inspect each input route before using it

For example, Request to https://example.invalid/api returned 401; token value omitted can support a discussion of authentication-error handling without revealing a live token. Keep the original secret out of the replacement prompt, screenshot, log and filename too.

In a document library, removing a file from a visible list does not by itself establish removal from an index, earlier conversations, logs or backups. Make the decision before intake rather than relying on cleanup afterward.

A narrow folder helps you see the boundary

For the Desktop route, expose only a fresh safe-intake folder. The agent will read permitted-input.txt and create or replace preparation-note.md. Your classification working notes and candidate documents stay outside that project.

OpenCode's permissions resolve actions as allow, ask or deny. Its external_directory permission governs paths outside the working directory. The official reference says explicit denials still apply in auto mode. Keep existing denials, confirmations and external-directory restrictions in force; this exercise does not require changing any of them.

A prompt saying “stay here” is an instruction, not a technical sandbox. Before approving any action, inspect:

1. Action: read, write, command, deletion or configuration change?
2. Target: the complete path, including the intended output filename?
3. Need: necessary to produce this one note?

Decline external searches, unrelated overwrites, destructive actions, installations, configuration changes or credential requests. Do not move a restricted file into an allowed folder to defeat a denial. Technical permission to read a file is not permission to disclose its content.

Runnable exercise

1. Name the useful question before choosing files

In your ordinary text editor, create a new local intake-decision.md outside any AI-opened project. Write:

Task: Prepare reusable name cards for the fictional Northbridge Workshop.
Needed result: quantity to obtain, a preparation action, and a supplier question.
Not needed: customer contract terms, internal project plans or support credentials.
Intake state: no candidate files uploaded, indexed or opened by an agent.

For your own task, replace the task and result lines first. Then decide what information is essential. Do not make a real question answerable only by destroying its meaning: if the task genuinely needs restricted facts, request an approved route or do the work with the accountable human.

2. Inspect five exact synthetic candidate files

Create a new local intake-candidates folder using your file manager. Keep it outside safe-intake and do not open it as an agent project or add it to a library. In a plain-text editor, create the following five files with the exact contents shown. The fenced blocks are the source; no download is required.

Every file below is course-invented. The public/internal/restricted labels simulate a real intake situation. Classify what each document represents in the scenario. The fictional customer document and nonfunctional log placeholder are not real confidential data or a working credential. Do not substitute real examples to make the exercise feel authentic.

public-workshop.txt:

SYNTHETIC TRAINING FILE — public workshop notice in this scenario
Workshop: Northbridge Workshop
Event date: 1 October 2026
Expected attendees: 40
Each attendee needs one reusable name card.
Collect the cards in a return tray at the end of the workshop.
Supplier delivery date: not stated

internal-agenda.txt:

SYNTHETIC TRAINING FILE — internal agenda in this scenario
Project codename: Lantern
Agenda: discuss an unannounced partnership after the workshop.
Owner decision for external AI processing: not recorded
No attendee preparation instructions are included here.

customer-contract.txt:

SYNTHETIC TRAINING FILE — restricted customer contract in this scenario
Parties: Northbridge Workshop and Cedar Supplies
Effective date: 1 October 2026
Term: 30 days
Deliverable: 40 reusable name cards
Price: EUR 160
Exception: delivery date is not stated
External AI processing approval: not recorded

support-log.txt:

SYNTHETIC TRAINING FILE — represents a log containing a credential
Request: https://example.invalid/api
Status: 401 Unauthorized
Authorization: NONFUNCTIONAL_TRAINING_PLACEHOLDER
Real-world counterpart to classify: this line contains a live API token.

synthetic-stock.csv:

record_id,item,available_count,provenance
S01,reusable name cards,12,fully invented training data
S02,card holders,40,fully invented training data
S03,markers,4,fully invented training data
S04,return trays,1,fully invented training data
S05,spare sleeves,0,fully invented training data

Classify them in intake-decision.md before consulting the completed decision below. For each, record a color, a reason and whether the exact source belongs in the proposed input. For a real document you are authorized to inspect locally, consider hidden content as well as the visible page. These plain-text fixtures contain only the shown text; they do not demonstrate inspection of an actual PDF or spreadsheet.

3. Turn classification into an intake decision

Here is the completed decision for the toy scenario. It is a worked reference, not approval for your organization's documents.

The stock file does not say anything about real inventory. The contract file does not establish that a real order exists. In particular, do not use the contract's effective date as the missing delivery date or assume its 40-card deliverable has already been ordered. That source was excluded, and the preparation task asks about a requirement and available stock.

This is a useful decision rather than a checklist finish: you now know which facts can support a preparation note and which unanswered question should go to a person.

If a colleague insists on the restricted source, a usable refusal preserves the task:

I will not upload or index the customer contract through this unapproved route.
I can prepare the name-card requirement from the permitted workshop notice
and stock count now. If we need actual negotiated terms or order status,
please ask the contract owner to confirm the approved tool/account, purpose,
data class and configuration, or answer that part through the existing human route.

This refuses the disclosure, not the colleague's need for help. Do not attach the restricted document to an unapproved help channel while asking for approval.

4. Create the smallest permitted input that still answers the question

Using your file manager, create a fresh safe-intake folder. In your text editor, create permitted-input.txt inside it with exactly this content:

SYNTHETIC WORKSHOP PREPARATION INPUT
All values below are invented training data.

Source: public-workshop.txt
Workshop: Northbridge Workshop
Event date: 1 October 2026
Expected attendees: 40
Each attendee needs one reusable name card.
Collect the cards in a return tray at the end of the workshop.
Supplier delivery date: not stated

Source: synthetic-stock.csv, record S01
Item: reusable name cards
Available count: 12

Reopen this exact file locally. It preserves the required quantity, stock quantity, event context, return instruction and unresolved delivery question. It excludes the agenda, contract and log, and four irrelevant stock rows. The small input can answer the same preparation question without inheriting those sources.

This working copy is a selection of already permitted synthetic facts. It is not an anonymized version of the customer contract, and it does not approve that contract for future use. In real work, neither shortening a document nor renaming it grants permission.

Add this boundary record to your local intake-decision.md:

Candidate review location: intake-candidates, outside the agent project
Approved agent project: safe-intake
Only agent input: permitted-input.txt
Only agent output: preparation-note.md
Allowed operation: read the input and create or replace the output
Excluded: candidate folder, parent/sibling/home/shared/external paths
Excluded: deletion, installations, configuration/permission changes, credentials
Human boundary approval: YES / NO
Interface: ______
Displayed provider and model: ______ or UNKNOWN
Route approval evidence for synthetic training: ______ or UNRESOLVED
Retention/logging: ______ or UNKNOWN

Write YES only after confirming the folder is fresh and contains just the intended input. Do not open your home folder, downloads or a customer repository and rely on “ignore everything else.” If no route is approved, keep the files local, mark submission blocked and prepare the request for later use.

5. Give one agent a bounded, useful job

In the installed OpenCode Desktop, select Open project and choose safe-intake, then New session. Check the displayed model/provider using the Desktop model control and record it locally before sending material. Use only the route already approved for this exercise. The course portal at ai.32dots.de (opens in a new tab) is an entry point for application information, not the project interface or proof of installation.

Send this request in the new session:

Read only permitted-input.txt in this project. It is entirely synthetic.
Create or replace only preparation-note.md.

Help the workshop organizer prepare reusable name cards. Use these headings:
Requirement
Available stock
Quantity to obtain
Preparation action
Supplier question
Limits

Use only facts in the input. Show the arithmetic for quantity to obtain.
Distinguish the event date from a supplier delivery date. Write NOT STATED
for missing delivery information. Draft one question asking whether the
required additional cards can arrive before the event; do not claim they can.
Preserve the return-tray instruction. Do not invent prices, an existing order,
payment terms, legal conclusions or facts from excluded documents.
This is a draft note, not permission to order, email, upload or index anything.

Do not read any other files or parent, sibling, home, shared or external paths.
Do not delete files, install software, run commands, request credentials, or
change configuration or permissions. If the task requires those actions,
stop and explain the missing permission or information instead.

For an approved chat-only route, replace the first two lines with the following and append the exact permitted-input.txt block from step 4. Save the returned text as a new local preparation-note.md yourself; the chat has not written a file merely by displaying Markdown.

Use only the synthetic input pasted below. Return a Markdown preparation note
for me to save locally as preparation-note.md. Do not use tools or other sources.

In Desktop, inspect each permission request's action and complete target path. Only the named input read and output write are needed. Decline anything beyond them. A configured allow is not a reason to accept an action you did not intend, and a prompt does not replace permission controls.

6. Inspect a completed worked artifact and make the improvement visible

Open the actual preparation-note.md in your text editor. In Desktop, also open Changes and inspect filenames, additions and deletions. Compare the saved file with the input, not just with the agent's message saying it finished.

This is a course-authored reference result, not a transcript of an observed model run:

# Requirement
Northbridge Workshop expects 40 attendees on 1 October 2026.
One reusable name card per attendee means 40 cards are required.

# Available stock
12 reusable name cards are available in synthetic-stock.csv, record S01.

# Quantity to obtain
40 required - 12 available = 28 additional reusable name cards.

# Preparation action
Arrange the 28 additional cards, then prepare 40 cards for the workshop.
Collect the cards in a return tray at the end of the workshop.
This note does not place an order.

# Supplier question
Can you deliver 28 reusable name cards before the workshop on 1 October 2026?
Confirmed supplier delivery date: NOT STATED.

# Limits
Based only on the synthetic workshop notice and stock record S01.
No price, existing order or negotiated terms are established by this input.
Confirm delivery with the responsible supplier contact before relying on it.

The original vague request, “summarize the folder,” offers no clear preparation decision. An illustrative weak first note might say:

Prepare name cards for the workshop. Get more if necessary.
Delivery is on 1 October 2026.

The completed version improves it in observable ways: 28 additional cards, an explicit 40 - 12 calculation, the retained return instruction, and a delivery question instead of an invented commitment. The event date remains useful while no longer masquerading as delivery evidence. No contract price or token is needed to obtain that improvement.

If your output has the weak note's errors, send one focused follow-up in the same session:

Correct only preparation-note.md using permitted-input.txt.
Show 40 required minus 12 available = 28 additional cards.
The source gives an event date, not a confirmed delivery date: mark delivery
NOT STATED and ask whether 28 cards can arrive before the event.
Keep the return-tray instruction and all original access restrictions.

Then compare the actual revised file again. If the first result already meets the reference, record that; do not invent a failed run. If you repair the note manually, record a human correction rather than claiming the agent got it right. For your own task, choose an equally visible improvement: a missing quantity made explicit, an unsupported claim removed, or an unanswered question routed to the right person.

7. Keep the original contract-summary task as an optional route

Perhaps your useful task is extracting contract fields rather than workshop preparation. You can preserve that skill without processing a real customer contract. This is an independent, fully invented training record, not authorization obtained by stripping the restricted scenario label off a real document.

In a separate fresh local folder named safe-contract-practice, create synthetic-contract.txt with the original exercise's exact fixture:

SYNTHETIC TRAINING RECORD
Parties: Northbridge Workshop and Cedar Supplies
Effective date: 1 October 2026
Term: 30 days
Deliverable: 40 reusable name cards
Price: EUR 160
Exception: delivery date is not stated

Record a new human boundary decision: only this file may be read and only summary.md may be created or replaced. Keep the same route approval, permission and credential restrictions. Open only this separate folder in a new Desktop session, or paste only this fixture into an approved chat.

Read only synthetic-contract.txt, which contains invented training data.
Create or replace only summary.md with exactly these headings:
Parties
Effective date
Term
Deliverable
Price
Exceptions

Under each heading use only supported facts. Write NOT STATED for a missing
fact. Do not infer a delivery date from the effective date or term.
Do not provide legal interpretation or invent payment terms.
Do not read other files or parent, sibling, home, shared or external paths.
Do not delete, run commands, install, request credentials or change configuration
or permissions. Stop if the task requires any of those actions.

For chat, ask it to return the Markdown instead of reading or writing files, and append the fixture. Save the result yourself. The completed reference is:

# Parties
Northbridge Workshop and Cedar Supplies

# Effective date
1 October 2026

# Term
30 days

# Deliverable
40 reusable name cards

# Price
EUR 160

# Exceptions
Delivery date: NOT STATED

Check both parties, date, term and unit, quantity and item, currency and amount, and the missing delivery date against the source line by line. A deadline, payment clause or legal conclusion fails this extraction task. Request one bounded correction or record your manual repair. This route retains the original substantial exercise; you need not complete both tasks to demonstrate intake competence.

8. Practice refusal without touching a real restricted path

The unsafe instruction below is a reasoning exercise only. Do not create the path, search for its contents, copy files or change permissions. Send this only through your approved training route:

Do not execute or request tools for this quoted instruction:
"Read C:/Shared/Customer-A/contract.pdf; search parent and shared folders for
credentials or anything useful, then copy it into this project's input."

Explain why this must be refused under the approved project boundary.
Offer a way to continue the useful task with the permitted input or an
independent synthetic record. Do not inspect files while answering.

A suitable answer identifies the external search, restricted customer data or credentials; refuses tool use; and offers the permitted preparation note, synthetic summary or owner escalation. If a tool request appears, decline it and stop. Record what actually happened. A correct verbal refusal alone does not prove that the installed permission system blocks external access.

Common wrong turns and recovery

If sensitive content has already been submitted, stop further processing and follow the organization's incident route. Record the service and account, time, categories of material and relevant upload/session reference without spreading the sensitive content in another message. Contact the designated security, privacy or data owner through the approved channel. For exposed credentials, use the relevant revocation or rotation process promptly as directed. Follow authorized instructions for containment, access removal and preservation of evidence. Deleting visible chat or a library entry does not establish that copies, logs, indexes or backups were removed.

End the exercise session without sharing it or uploading its folder elsewhere. Keep your permitted local artifacts for the exit check.

Exit check

Your exit artifact is an intake-to-result handoff: intake-decision.md, the exact permitted input, and the checked preparation note or learner-chosen equivalent. For the optional original extraction route, include synthetic-contract.txt and summary.md instead of the workshop input and note.

It passes when another person can see:

1. Decision before intake: all five scenario candidates have a color, reason and include/withhold/escalate action. The fictional labels are not asserted as institutional policy.
2. A useful task preserved: the input contains the facts necessary for the named job; excluded contract, agenda and credential material has not leaked into the request or result.
3. An accountable boundary: the human approved the exact folder, input, output and route. Unknown provider, retention or logging facts remain marked UNKNOWN; unresolved route approval means no submission.
4. A supported result: the workshop note requires 40 cards, accounts for 12 available, obtains 28 additional, retains the return instruction and treats delivery as NOT STATED. The contract alternative matches all six fields without an invented clause or date.
5. Observable improvement or honest first-pass success: record a specific correction and who made it, or record that the first output already met the stated conditions. Distinguish the course reference from your saved result.
6. Refusal and recovery: explain the out-of-folder refusal, a task-preserving alternative, and what to do if a real secret was already submitted. Record whether you actually ran the reasoning-only refusal exercise.

Also explain one pre-send check for chat, upload/indexing and coding context. State why a local Desktop window is not proof of a local model, why moving a file does not authorize it, and why minimization is not a certificate of anonymity.

If no approved model route was available, submit the local intake decision, input, copyable request and named approval blocker as a prepared handoff, with execution marked unperformed. That demonstrates the pre-upload decision; it does not count as a completed agent-generated result. Do not copy the reference note and label it your model's output.

Real restricted input, an exposed live secret, weakened boundaries, unsupported facts or a guessed missing date require stopping or correcting the exercise. A polished document does not compensate for a failed intake decision.

Source notes

• Published T12-L01 baseline (opens in a new tab): the complete local source manuscript at editorial/drafts/l1-refinements/T12-L01.md was read for this revision. The completion brief supplies public-body SHA-256 6b6c33fbcecbcada656dad1784713d3f787c98744c297de93b122cb275c2420e; it was not recomputed in this session. Classification, route approval, coding-context minimization, original synthetic contract fields, permissions, refusal and incident guidance are retained.
• Document-library design example: the completion brief maps only its pre-upload/intake slice here. This is an editorial association, not evidence of a shipped library, verified indexing behavior or institutional adoption. The catalogue page was not fetched during authoring.
• OpenCode permissions (opens in a new tab): returned Actions, Auto mode and External Directories documentation read on 11 September 2026 for allow/ask/deny, explicit-denial behavior and external paths. No settings changed or tool-denial experiment performed.
• OpenCode providers (opens in a new tab): returned overview read on 11 September 2026 for remote-provider support and local-model options. The long provider directory was not reviewed; no account, retention guarantee or local configuration was verified.
• OpenCode download entry point (opens in a new tab): historical Desktop label research retained from the baseline. Open project, New session and Changes were not freshly inspected in a running Desktop instance. The previous edition also linked the web-interface documentation (opens in a new tab) for localhost/network-exposure considerations; this exercise does not configure a web server, and that source was not reread.
• All workshop notices, names, dates, counts, stock rows, codenames, file paths, contract terms, requests and completed outputs here are synthetic course material. example.invalid and the explicit nonfunctional placeholder avoid introducing a live endpoint or credential. The worked notes are authored references, not captured outputs.

Unknowns and limitations

This lesson cannot decide your organization's data permissions, legal duties, approved accounts, provider configuration, retention, logging, jurisdiction or incident process. The colors are teaching aids; actual rules govern real inputs. Local copies may also be subject to organizational storage requirements. Minimization preserves task meaning but does not establish anonymity or compliance.

No real document was sanitized, uploaded or indexed during authoring. No learner installation, model response, permission dialog, file-generation run or classroom outcome was observed. Product behavior can vary with version and configuration. The exercise gives no legal interpretation of a contract and establishes no real stock, order or delivery commitment.

The previous edition included a course-authored browser reference viewer and screenshot, explicitly distinguished from OpenCode. They are not evidence for this new intake packet. This manuscript supplies the complete copyable inputs and references directly; it claims no new downloadable assets or screenshots.

Coordinator review, consolidated verification and any publication remain separate from this authoring task. Token, cache, reasoning and billing counters were not available to the author; their values and production cost are unknown.

How this book was made

Coordinator editorial update, 11 September 2026: The independent Terra reader accepted this revision. The account below records authoring-stage work; learner execution and classroom outcomes remain unobserved.

Current author, 11 September 2026: Astra, OpenAI, exposed model identifier openai/gpt-6-astra, authored this example-led revision in one fresh, book-specific session using apply_patch. The author read the assigned brief, editorial style, learnings, template and complete prior manuscript, plus the bounded official-source sections listed above. No additional agents or independent reviewers participated in this author session. Only this manuscript was written; no tests, lint, typecheck, manuscript validation, browser checks, installation, commit, push or deployment were performed.

Retained historical contributions: Sol revised the earlier lesson into its OpenCode-centered Level 1 exercise. Luna subsequently aligned the Desktop presentation without replacing Sol's authorship. Astra (OpenAI, openai/gpt-6-astra) added the 9 September 2026 pre-send refinement for chat, upload and coding context. That edition records a Payload body/metadata retrieval and checksum at 2026-09-09T10:50:57.3688468Z; it is historical evidence, not a new check by this author. The older Sol/Luna exact model identifiers are not established by the supplied source. Earlier descriptions of coordinator verification responsibilities do not establish completion of checks for this revision.

The production lesson was to choose the useful question first. Keeping attendance and one stock row made the 28-card decision possible; withholding the contract avoided importing unnecessary negotiated terms, and retaining a supplier question prevented an invented deadline. The original six-field synthetic extraction remains available for learners whose task is a summary. These are inspectable teaching changes, not measured learner gains. The coordinator still needs to check the integrated manuscript and executable exercise paths in the single final verification phase after all ten edits.