Before sending a document, screenshot, log, dataset, or source file to an AI service, reduce the request to the minimum permitted evidence. Replace real values with synthetic equivalents when possible. Remove direct and indirect identifiers. Inspect filenames, metadata, and surrounding context. Then review the exact outgoing input.
If the task still requires restricted or sensitive material after that pass, do not treat redaction as automatic permission. Use an approved institutional route or ask an authorized person.
Permission comes before sanitization
Sanitization reduces exposure. It does not create permission.
Begin with the assignment and course AI rules. Confirm:
- whether AI assistance is allowed for this task;
- which service or account is approved;
- whether course material may leave the institution’s system;
- whether another person’s information or work is present; and
- whether use or disclosure must be recorded.
Stop if an answer is unknown and the uncertainty affects permission, privacy, intellectual property, or academic integrity.
Identify what the question actually needs
“Why did this program fail?” rarely requires an entire desktop screenshot or repository. The useful evidence may be:
- the exact error text;
- the command that produced it;
- a short, relevant code fragment;
- the expected behavior;
- the observed behavior; and
- the runtime or tool version.
Write the question before selecting the evidence:
Question: Why does this fictional Python script report that config.yaml is missing?
Minimum evidence: command, working directory, synthetic path, exact error,
and the code that constructs the path.
Not needed: student name, course number, grades, private repository URL,
browser tabs, access token, unrelated files, or the complete assignment.
This step often removes more risk than later pixel-level redaction because unnecessary material never enters the outgoing input.
Check five information categories
1. Secrets and access material
Never share passwords, authentication tokens, recovery codes, private keys, session cookies, database credentials, or private invitation links. A placeholder such as TOKEN_REMOVED is enough to show where a secret was used.
If a real secret has already appeared in a prompt, screenshot, log, or public location, removing it from a later copy does not make the original secret safe. Revoke or rotate it through the authorized system and record the incident without copying the secret again.
2. Direct identifiers
Names, student IDs, email addresses, phone numbers, and account usernames can identify a person directly. Replace them with neutral fictional values unless identity is necessary and authorized.
The U.S. Department of Education’s definition of personally identifiable information in education records includes both direct identifiers and indirect identifiers that can identify someone through linkage with other information.
3. Indirect identifiers and combinations
Removing a name may leave a person identifiable through a rare course section, precise date, research topic, local path, employer, team role, or combination of details.
Ask whether someone familiar with the context could infer the person or class. Replace exact context with a synthetic equivalent when the exact value does not affect the technical question.
4. Restricted content and other people’s work
An unpublished assignment, solution key, instructor feedback, peer submission, research dataset, or private repository may remain restricted even after names are removed. Redaction addresses identification risk; it does not resolve copyright, course policy, confidentiality, research rules, or another person’s consent.
5. Hidden or surrounding information
A screenshot can show browser tabs, notifications, bookmarks, filenames, account avatars, timestamps, and other windows. A document can contain comments, revision history, embedded objects, author fields, or hidden sheets. A log can include environment variables and full local paths.
Prefer selected text over a screenshot when the visual layout is irrelevant. Prefer a new plain-text reproduction over an original document when formatting and metadata are irrelevant.
Replace before you redact
Synthetic replacement is often clearer than covering pieces of a real artifact.
Risky input:
/Users/real-name/UWF/CS-121/private-project/config.py
API_TOKEN=live-secret-value
FileNotFoundError: /Users/real-name/UWF/CS-121/private-project/config.yaml
Minimal synthetic input:
/Users/student/practice-project/config.py
API_TOKEN=TOKEN_REMOVED
FileNotFoundError: /Users/student/practice-project/config.yaml
Then provide only the relevant code:
from pathlib import Path
config_path = Path.cwd() / "config.yaml"
print(config_path.read_text())
The synthetic version preserves the path-construction problem without exposing the real student, institution, repository, or credential.
Review the exact outgoing input
Create a short record titled AI sharing check — [task] and answer four questions:
- What is the smallest question being asked?
- Which evidence is necessary, and why?
- What was removed or replaced?
- What permission, policy, or sensitivity issue remains?
Use stop, approved route, or share minimal input as the decision. Keep the record only when it helps you explain the decision; do not preserve sensitive source material inside the record.
Before sending, read the final prompt and every attachment from beginning to end. Check pasted text, filenames, image edges, code comments, sample values, URLs, and metadata visible in the selected interface.
Know when sanitization is not enough
Stop and use another route when:
- the real identity is necessary to the question;
- a complete private document is required;
- the task depends on a restricted dataset or unpublished assessment;
- another person’s work cannot be removed;
- the institution requires an approved service you do not have; or
- the remaining combination of facts can still identify a person.
The agent-surface decision guide can help when permitted data must stay on a local or managed system. Service location does not replace the course and institutional rules.
The Department of Education explains that FERPA protects education records maintained by covered educational institutions and that rights transfer to eligible students under defined conditions. This article uses its identifier definitions as a useful privacy check; it does not claim that FERPA governs every file a student controls or answer a specific legal question. Consult the institution’s privacy office or authorized policy source when that distinction matters.
Common mistakes
- Redacting after uploading. Review and minimize before the material leaves its authorized location.
- Removing only the name. Combinations of context can still identify someone.
- Assuming synthetic data must look realistic. It only needs to preserve the technical condition being investigated.
- Sharing a screenshot when text is enough. Screenshots expose surrounding context.
- Treating a private service as permission. Course, institutional, and account rules still apply.
- Pasting a live secret to ask whether it is a secret. Remove it and rotate it if exposed.
Do this now
Take one fictional error report. Rewrite it using a synthetic username, project name, path, and placeholder secret. Keep only the error, command, expected behavior, observed behavior, and relevant code. Review the final input once without opening the original.
Log what you learned
Save the four-question sharing check only if it helps you repeat the decision. Record the final action and any unresolved policy question. For the technical structure of a minimal diagnostic report, continue with Write a Reproducible Bug Report.