Writer Privacy: Auditing Personal Exposure Without Killing Your Voice

Writers put themselves in the work. That is not the problem.

The problem is everything that gets dragged in with the voice by accident. Street addresses hiding in photo metadata. Old API keys lingering in public repos. Family names tucked into examples. Email patterns clear enough to build a fake version of you. A neighborhood revealed one casual reference at a time until the map starts drawing itself.

Authenticity and exposure are not the same thing, but a lot of writers still treat them as twins.

You can say you grew up in Brooklyn without giving someone your building. You can say the kids were at school without naming the school. You can say the work happened at home without handing over the coordinates. The reader needs the emotional truth. They do not need the attack surface.

That distinction matters more now because aggregation is cheap. People used to leave breadcrumbs across years of posts, interviews, newsletters, GitHub repos, and casual photos and trust that the friction would protect them. That friction is gone. A machine can connect the fragments faster than most writers can remember what they have already made public.

The fragments are usually more ordinary than dramatic. Not secrets in the movie sense. Just enough loose detail to become leverage.

A public repo with a carelessly committed key. A photo uploaded with location data intact. A few anecdotes that narrow home, routine, family structure, and habits at the same time. A visible email cadence that makes a spoof easier to believe. None of it feels fatal alone. Together it becomes a usable profile.

That is why writers are softer targets than they like to admit. The job trains you to be public, personal, and vivid. It does not automatically train you to think like somebody hunting for angles.

Run the AI Audit on Yourself First

The most useful thing you can do before anyone else does it for you is ask an AI to build your profile from your own public material.

Collect a representative sample: a few articles, your bio, your GitHub URL if you have one, any public social profiles. Then run this:

I'm going to share my public writing, bio, and online presence.
Act as an OSINT investigator building a profile on this person.

From the material I provide, determine what you can infer about:
- Home location or neighborhood (approximate)
- Family structure and ages
- Daily routine and movement patterns
- Financial situation signals
- Technical stack and tools
- Physical presence patterns (office, coffee shop, commute)

Then do two things:
1. List every inference, even weak ones, with the source fragment that enabled it
2. Flag which pieces were most likely published by accident rather than by choice

Do not soften the findings. Treat this as a real investigation.

What comes back will be uncomfortable. That is the point. You are looking for the pattern the sentences make when read together — not the danger in any single post. This prompt surfaces the aggregation problem faster than you can find it manually, and it shows you exactly which casual details are doing the most damage.

Run it again after you clean things up. The before and after is the audit.

The GitHub Problem

Writers who build things have a specific exposure most pure writers don't. Code is public by default if you're not careful, and code carries secrets that prose never does.

The easy version of this mistake: committing an API key, a database URL, or a .env file that should never have been in version control. Deleting the file later does not fix it — the key is still in the commit history, and the history is permanent and public.

Check your history before you assume you're clean:

# Scan commit history for anything that looks like a secret
git log --all --full-history -p | grep -E "(api_key|secret|password|token|key=|auth)" -i | head -50

For a more thorough sweep, truffleHog scans the full git history for high-entropy strings — the pattern that secrets produce in code:

pip install trufflehog
trufflehog git file://. --only-verified

If you find something, rotate the key immediately — the repo history being public means the key is already compromised. Then rewrite the history to remove it. git filter-repo is the modern tool for this (filter-branch is deprecated):

# Install
pip install git-filter-repo

# Remove the specific file from all history
git filter-repo --path path/to/file-with-secret --invert-paths

# Force push the rewritten history
git push origin --force --all
git push origin --force --tags

That is not a fun afternoon. Running a .gitignore that excludes .env files from the start is a better afternoon.

The .gitignore a writer-builder should have running from day one:

# Secrets — never in version control
.env
.env.local
.env.*
*.pem
*.key
*_key.json
credentials.json
config/secrets.*

# OS noise
.DS_Store
Thumbs.db

# Editor state
.vscode/settings.json
.idea/

# Dependencies — these get rebuilt, not committed
node_modules/
__pycache__/
*.pyc

Also worth running once: check what Google has already indexed from your repos.

# Search for your email in GitHub-indexed content
# Run in a browser — replace with your actual details
site:github.com "[email protected]"
site:github.com "YOURAPIKEY_PREFIX"

# Check what personal info your public profile exposes
curl -s https://api.github.com/users/yourusername | \
  python3 -m json.tool | grep -E "(email|blog|location|bio|company)"

If something comes back you did not intend to be public, the GitHub profile settings are the fast fix. The indexed version takes longer to drop out of search results — Google's cache is slower than your ability to remove the source.

Photo Metadata

Every photo your phone takes embeds GPS coordinates, device model, and timestamp in the file's EXIF data. Upload that photo to a blog post or a GitHub README and anyone who downloads it can extract your exact location at the moment you took the shot.

Check what your photos are carrying:

exiftool your-photo.jpg | grep -E "(GPS|Location|Latitude|Longitude)"

Strip it before publishing:

exiftool -all= your-photo.jpg

If you use a Mac, Preview will also strip EXIF on export. The point is to build the habit — strip before upload, not after you realize the mistake.

The Cold Eye Review

Once a year, pull everything you can find about yourself from a search engine's perspective. Your name, your pen name if you use one, your domain, your GitHub handle. Read it as a stranger who wants to find you, not as the person who wrote it.

Ask:

• What neighborhood does this material place me in?
• What school, gym, coffee shop, or routine shows up across multiple posts?
• What do my examples say about who I live with?
• What does my posting schedule reveal about my hours?
• What does the combination of my technical stack and my personal essays say about my financial situation?

The danger is almost never in one post. It is in the pattern. The cold eye review is how you see the pattern before someone else does.

The Specificity Is the Work. The Attack Surface Is Not.

None of this means sterilizing the work.

The specificity is the work. A Brooklyn childhood is more alive than a generic urban childhood. A particular coffee shop has more texture than "a place I go to write." The emotional truth requires specific detail.

The audit is not about removing the voice. It is about separating the details that give the work blood from the residue that makes other people's jobs easier. Readers come for the signal. They do not need your operational mistakes along with it.

Good privacy practice stops rewarding anyone patient enough to turn your public life into a search problem. The voice survives. The attack surface shrinks.

Those are not the same thing, and keeping them separate is a skill worth building once and running quietly forever.

---

GhostInThePrompt.com // The work needs a pulse. It doesn't need your coordinates.