Variables for Personal Details (Without Oversharing)

TL;DR: Privacy prompt variables are the {{name}} slots you fill with a fact about yourself. Some personal details are safe to store there: a first name, a professional email, a city. Others should never become a saved variable, in any tool. This guide draws that line, verified against Prompt Architects' own code and privacy policy, and covers the naming mistakes that silently break a variable.

What Counts as a "Privacy Prompt Variable," and Why Do Personal Details Need Different Rules?

A variable, in the plain sense this post uses, is a named slot inside a prompt template (written {{first_name}} or {{work_email}}) that gets swapped for a stored value automatically whenever that template runs. Prompt Architects' own FAQ describes the mechanism directly: "Global variables are reusable values you define once and inject into any prompt using {{variable_name}} syntax." Create one, reference it inside any prompt, and it's replaced at enhancement time.

Most of the marketing copy around this feature, and most of the guidance already on this site, talks about variables for business facts: a brand name, a support inbox, a tone of voice. Those are low-stakes by design; nobody minds a workspace knowing its own support email. Personal details are a different category. A variable that holds your name, your contact information, or your location is a variable about a specific, identifiable human being, and the convenience that makes variables useful (fill it in once, it rides along automatically) is exactly what makes the wrong entry risky: it doesn't leak once, it repeats on every prompt that references it until you notice and remove it.

This piece is narrower than our guide to Personal Context, which covers the broader stored-profile feature, and our guide to building a full personal AI system, which covers variables as one of four pieces alongside context, templates, and a review habit. Here the focus is specifically on the personal-detail-shaped variables people are tempted to save (name, contact info, location, role) and where the line actually sits.

Which Personal Details Are Actually Safe to Save as a Variable?

The short version: anything you'd already hand over on a business card, a public bio, or a LinkedIn profile.

• Your first name, or a professional alias you already use publicly.
• A professional email address: the one you'd give a new client, not a personal inbox you don't share.
• Your job title or role: "freelance brand designer," "product manager at a mid-size SaaS company."
• A city-level location: "Austin, TX," not a street address.
• Your pronouns, if you want the AI to use them consistently across every generated draft.
• Links to your own public work: a portfolio site, a LinkedIn URL, a company page.

None of these cause real damage if they surface somewhere unexpected: a teammate's shared prompt, a support transcript, an AI answer to a completely different question. That's close to the actual test: a safe personal-detail variable is one you'd be unbothered seeing repeated back to you in public.

Which Personal Details Should Never Become a Variable, in Any Tool?

The reverse list matters more, because a saved variable resends its value every time a template calls it, and that's a much larger blast radius than a single mistyped prompt.

1. Your home address. A city is a bio detail; a street address is a location, and there's rarely a task that genuinely needs the second one filled in automatically.
2. A personal phone number. Same logic as the address: the professional email above almost always covers what a template actually needs.
3. Government ID or account numbers. A passport number, a national ID, a tax ID, a bank account or card number. None of these belong anywhere near a reusable prompt slot.
4. Medical or financial specifics. A diagnosis, a salary figure, a balance. Saving these as standing infrastructure, applied automatically to unrelated prompts, is a different risk category than mentioning one once in a single message you control.
5. Passwords, API keys, and security-question answers. A variable field is not a password manager and was never built to be one.
6. Someone else's personal information. A colleague's cell number, a client's private detail, a patient's information: anything that isn't yours alone to decide about. This is the easiest one to drift into by accident, usually by pasting a paragraph that happens to include someone else's details alongside the part you actually meant to save.

None of this is specific to Prompt Architects. The same list applies to ChatGPT's memory, Claude's Projects, or any tool that stores a reusable value and reapplies it automatically: the risk lives in the pattern of saving something once and having it resend automatically, not in any one vendor's implementation.

What's the Quick Test for Anything In Between?

Most of what people actually want to save falls somewhere between "obviously fine" and "obviously not." Three questions cover that middle ground:

1. Ownership. Is this fact only about you, or does it involve another identifiable person? If it's about someone else, it doesn't go in your personal variable at all: that's their decision to make, not yours, regardless of how convenient it would be to have it on hand.
2. Necessity. Does the task actually need this exact fact, or would a vaguer version do the same job? A template asking for "your city" rarely needs "your street address" to function; the more specific version is added risk with no added usefulness.
3. Blast radius. If this variable's value ever ended up somewhere you didn't intend (a mis-scoped team variable, a pasted output, a screen share), what's the actual damage? A first name is a shrug. A card number is not.

If a fact fails any one of the three, it doesn't belong in a saved variable. It stays a detail you type into the one prompt that actually needs it, used once, and left there.

Does Saving a Variable Send It to the AI on Every Future Prompt?

No, only a prompt that literally contains that variable's token triggers a lookup for it. This is worth being precise about, because it's the opposite of how a blanket, always-attached profile would behave, and it's verifiable directly in the app's own code rather than assumed.

The enhancement action collects variable references by scanning only the specific prompt text about to be sent (the current draft, any previously modified version of it, and any inline answers you've supplied) for {{name}} tokens. It then fetches stored values for exactly those ids and hands them to the model as a separate, out-of-band system note, never touching anything else sitting in your saved list. A variable you created last month but haven't referenced in today's prompt is never fetched, never sent, and never part of that request at all.

The practical upshot: the exposure surface for anything you save is exactly the set of prompts that reference its {{name}}, and nothing wider than that. That's a meaningfully narrower blanket than an always-attached profile, and it's a reason a variable can be a reasonable home for a personal-but-safe detail even where a broader, automatically-applied context slot might feel riskier for the same fact.

Is a Personal Variable Visible to Your Teammates?

Only if you scope it to "team," and this is the trap specific to variables that a plain would-this-be-fine-if-it-leaked test doesn't fully cover.

Every variable you create on an account with a team workspace carries a scope: private or team. A team-scoped variable is available to any teammate who references the same variable name from inside that shared workspace. That's the whole point of Shared Variables, and it's genuinely useful for the facts that are supposed to be shared: a brand name, a support inbox, a standard disclaimer. It is the wrong home for anything personal to you specifically, because being shared with the whole workspace is not a side effect here, it's the feature working as designed.

If you're working solo, this distinction doesn't come up. If your account has any team members at all, it's worth a five-minute audit of which of your variables are scoped which way before you assume a personal detail is staying between you and the model.

Why Do Some Variable Names Silently Fail?

Because the matching pattern is stricter than it looks, and there's no error message when a name falls outside it: the {{name}} just stays in your output as plain, unreplaced text.

Prompt Architects' variable matching accepts lowercase letters, digits, and underscores only, and the token must be written with no extra characters inside the braces. Tested directly against the app's own matching pattern:

Matches and substitutes:
  {{first_name}}     → replaced with its stored value
  {{work_email}}     → replaced with its stored value

Silently fails — stays literal, visible text in your output:
  {{firstName}}      ← a capital letter breaks the match (no camelCase)
  {{home.city}}       ← a dot breaks the match
  {{home-city}}       ← a hyphen breaks the match
  {{ first_name }}   ← a space right inside the braces breaks the match

Does NOT disable substitution — it substitutes AND leaks a stray brace:
  {{{home_city}}}     → "{Austin}" (not "{{home_city}}", not skipped)

The rule that falls out of testing every one of those cases: lowercase letters, digits, and underscores only, no spaces, and don't reach for a third brace expecting it to opt a variable out of substitution; it doesn't. Names also run 2 to 64 characters, and the value you store per variable is capped at 1,000 characters flat across every plan (a separate, larger cap applies only to a legacy AppSumo migration bucket, not to any of the four sellable plans, so don't treat that figure as a general limit).

What Happens to a Variable's Value Once You Save It?

It reaches Prompt Architects the same way any other prompt content does, governed by the same privacy policy (current as of this writing, last updated January 12, 2026) that covers your account generally. The policy doesn't list "variables" as a separately named data category; it names "Prompts," "Account Information," and a handful of others, and a variable's value is submitted through your account rather than itemized on its own line. If that distinction matters to you, read the current policy yourself rather than relying on this summary: policies get updated, and a specific carve-out for variable data may exist by the time you're reading this that didn't at verification time.

What the policy does say, in its own words: "We do not use your prompts to train AI models unless you explicitly opt in to such use. Your prompts are processed solely to provide you with enhanced versions and are not used for any other purpose without your consent." On security: "Encryption of data in transit using TLS/SSL" and "Secure storage with encryption at rest". On retention: "We retain your information for as long as your account is active or as needed to provide you services." On deletion: "We will delete your personal information within 30 days of receiving a valid request." And: "We do not sell your personal information."

The general lesson holds past any one vendor. Assume whatever you save gets processed by that provider on every request that references it, read what its policy actually says about training and retention before you trust a feature with anything personal, and prefer a tool that states its policy in plain language over one that doesn't address it at all.

A Safe Starter Set of Personal-Detail Variables

If you're setting up your first batch, here's a low-risk starting point that covers what most templates actually need:

Five variables, none of which would embarrass you if a teammate saw them, a support agent read them back to you, or an AI answer to an unrelated question happened to include one. If you want the naming and reuse habits that make a set like this easy to maintain at scale, our guide to reusable prompt variables for dev teams covers that from a team-scale angle, and the prompt hygiene checklist is worth running before you save anything new, not just before you send it.

Where Prompt Architects Fits, and Where the Decision Stays Yours

The mechanism is genuinely narrow and genuinely useful: a variable only gets sent when its exact token appears in the prompt you're about to run, private-scoped values stay private, and the naming rule is strict enough that a mistake fails silently rather than exposing anything by accident. None of that decides what you should put in a variable in the first place. That call is yours every time, and it doesn't get easier just because the value cap is generous or the feature is convenient.

If you take one habit from this, make it the three-question test: whose fact is this, does the task actually need it, and what's the damage if it ends up somewhere you didn't plan. If a personal detail passes all three, a variable is a reasonable, low-effort place to keep it. If it doesn't, it was never a variable problem to begin with: it was a one-time detail that belonged in a single prompt, typed once, and left there.