You now know how to choose a route. Before you send anything real down that route, you need to see the boundary your request crosses — because the moment a prompt leaves your computer, it is subject to someone else's logging, retention, and terms.

This lesson is not meant to frighten you away from the tools. It is meant to leave you with one durable habit: know what you are sending, know who can keep it, and keep secrets and other people's data on your side of the line unless there is a good reason and an approval.

What actually leaves your machine

When OpenCode (or any agent) sends a request through OpenRouter to a provider, the payload can include far more than the sentence you typed:

• your literal prompt and follow-up messages,
• the files or file excerpts the agent attached for context,
• tool results: terminal output, test logs, error messages, directory listings,
• retrieved snippets: documentation, web content, database rows the task pulled in,
• metadata: model identifier, timestamps, token counts, and sometimes account or organization labels.

An agent loop multiplies this. A single "fix the checkout bug" task can send dozens of requests, each carrying fresh slices of your codebase and logs. None of this is hidden — it is how the model gets the context it needs — but it means your privacy decision is not about one message. It is about the whole working set the agent shares across a session.

The data-boundary diagram

Your machine: full project, secrets, user dataShaped request: prompt + selected files + tool outputOpenRouter: forwards, logs routing factsProvider: runs inference under its data policyProvider logsResponse returns to you

Three choices govern every crossing, and all three are yours:

1. What you include. The agent can only send what it can see — so the file set you grant it is a privacy decision (Class 09's "smallest useful file set" rule is a privacy rule too). 2. Which route you pick. Providers differ in logging and retention; some routes offer zero-data-retention handling where prompts are not stored after serving the request. 3. What your organization allows. Team, client, school, or employer rules may restrict which data may reach external services at all — regardless of what the provider promises.

Provider selection is a privacy decision

Price and speed got the attention in Lesson 10.2. Now add the privacy column, and treat it as equal:

• Read the retention terms for the provider on your chosen route, not just OpenRouter's page. The provider that runs inference sets the logging terms for the content it processes.
• Prefer zero-retention options for sensitive work where available — routes where the provider does not store prompts or completions after serving them.
• Remember the same-model trap: the identical model served by two providers can carry two different data policies. Changing providers to save a fraction of a cent can silently change who keeps your prompts.
• Log your own routing facts. For important work, record which model and provider handled it and when. That record is what lets you answer "where did this code go?" weeks later — the same provenance habit Class 06 recommended.

When in doubt, check the provider's current documentation before sending sensitive material. Retention options change; the habit of checking does not expire.

Secrets and data that need approval

Some things need no deliberation. Never paste these into an external prompt, file attachment, or tool result you will send:

• API keys, tokens, passwords, private keys, session cookies.
• Your .env contents or anyone else's credentials file.
• Private keys, certificates, or signing secrets.
• Production database connection strings or dumps.

This connects directly to the approval boundaries from Class 06: credentials, production systems, money movement, and other people's data always require deliberate human review before an agent acts — and the same review applies before that data is sent anywhere.

For everything else, use three buckets:

Practical moves that cost nothing: keep secrets in environment variables the agent reads by reference rather than pasting values into prompts; strip or synthesize user data before using it as context; grant the agent the narrowest file set that still lets it do the task.

A calm way to decide in the moment

Run this thirty-second check before a sensitive request:

1. What am I about to send? Glance at the attached files and recent tool output — not just your prompt. 2. Which bucket is each item in? Safe, needs approval, or stays local. 3. Is the route worthy of the most sensitive item? If anything needs approval, confirm the provider's retention terms and your organization's rule before sending. 4. Can I shrink it? One relevant function beats the whole repository; synthetic data beats real user rows.

If any step fails, the safe move is boring and correct: narrow the file set, anonymize the data, switch to a stricter route, or keep the task local.

Practical exercise: classify sample data

Classify each of these as safe to send, needs approval, or must remain local. Write one sentence of reasoning per item:

1. A public utility function from your open-source side project. 2. Your project's .env file containing a production API key. 3. A support ticket containing a customer's name, email, and order history. 4. An unreleased pricing algorithm your employer considers confidential. 5. A synthetic checkout dataset you generated for testing. 6. A stack trace containing a session token pasted from a production log.

Done looks like: six classifications with six reasoning sentences.

Quick verification: for every item you marked "needs approval," name the approval (whose rule?) and the reduction (what would you strip or narrow before sending?). If you cannot name both, move the item to "must remain local" until you can.

Common failure mode: approving the whole file because one function inside it is relevant. Send the excerpt, not the file — the agent rarely needs the rest.

Check your understanding

1. List three things besides your typed prompt that can leave your machine in a routed agent request. 2. Why can the same model have different privacy implications through different providers? 3. What is a zero-data-retention option, and when should you prefer one? 4. What must never be pasted into an external prompt, no matter how convenient?