Top 5 Approaches to Agent Personalization Without PII Leakage

An agent that personalizes well is an agent that has seen too much. The classic failure mode looks innocent: a support copilot greets a returning customer by name, references their last three orders, and quietly bakes that record into a prompt, a log line, an embedding, and a third-party model's context window. None of that was governed. None of it is reviewable. And when a regulator or a customer asks where their data went, the honest answer is "into several systems we don't fully control." Personalization and PII leakage are the same engineering decision viewed from two angles.

Sanity Context (previously Agent Context) exists to make that decision deliberate. Sanity is the AI Content Operating System, an intelligent backend designed to keep agent workflows governed, reviewable, and safe inside the editorial loop, so the content an agent retrieves is structured, current, and free of personal records by construction. This article ranks five approaches to agent personalization that keep PII out of the retrieval path, the prompt, and the model. We move from the weakest pattern (hope and redaction) to the strongest (structured, content-grounded personalization where the personal layer never enters the agent's context at all).

5. Prompt-time redaction and PII scrubbing

The most common starting point, and the weakest, is to let personal data flow into the agent and scrub it on the way in. A regex or named-entity recognizer strips emails, names, and account numbers from the prompt before it reaches the model, and a similar pass runs over logs. It is cheap, it ships in an afternoon, and it gives a team something to point at in a compliance review.

Where it does well: catching the obvious, high-frequency formats. Credit card numbers, email addresses, and phone numbers have stable shapes, and a good scrubber removes them reliably. For a low-stakes internal tool, that may be enough.

Where it fits poorly: redaction is a filter on a leak you have already decided to allow. The PII is still assembled into the prompt before the filter runs, still potentially cached upstream, and still leakable through the long tail of formats a regex never anticipated. A customer who writes "my wife Dana booked under her maiden name" defeats entity recognition entirely. Worse, redaction strips the very signal that made the interaction personal, so you trade personalization for safety rather than getting both.

A concrete example: a billing agent scrubs the account number from a user's question but the retrieved knowledge article it pulls back was itself authored with a sample customer's real data, because nobody governed the source content. The leak moved upstream of the filter. This is the core problem with redaction as a strategy. It treats PII as something to catch in flight rather than something to keep out of the content layer in the first place, which is exactly where Sanity's Content Lake keeps the agent's grounding material structured and free of personal records.

4. Vector database with metadata filtering

One step up, teams put their knowledge into a dedicated vector database and use metadata filters to keep personalized retrieval scoped. Each document gets tags (tenant, role, region), and queries pass a filter so an agent only ever retrieves chunks the current user is allowed to see. Pinecone, Weaviate, and similar stores make this pattern fast and horizontally scalable.

Where it does well: multi-tenant isolation and recall at scale. If you have millions of chunks across thousands of customers, a purpose-built vector store with namespace and metadata filtering is genuinely good at returning the right neighbor set quickly, and the filter gives you a defensible access boundary.

Where it fits poorly: the vector store is downstream of your content, not your content. Someone has to build and maintain the pipeline that chunks source documents, generates embeddings, writes metadata, and re-syncs when anything changes. PII protection lives in that glue code, which means it is exactly as correct as the last engineer who touched the ingestion job. When a document is edited or a customer is deleted, embeddings go stale until a separate job catches up, and stale embeddings are where deleted personal data quietly survives.

A concrete example: a customer exercises their right to erasure, the source record is deleted, but the embedding generated from it lingers in the index for hours because the re-index job runs nightly. With Sanity, dataset embeddings are tied to the content itself, so updates propagate within minutes and there is no separate vector pipeline to keep honest. The personalization boundary lives with the content, not in a parallel system you have to reconcile.

3. Agent platforms with managed retrieval

Managed agent platforms such as Kapa.ai, Mendable, and similar "we will do retrieval for you" services take the pipeline off your plate entirely. You point them at your docs and support content, they handle chunking, embeddings, and serving, and you get an agent that answers grounded questions out of the box. For a team that wants a documentation assistant next week, this is the fastest path.

Where it does well: time to value and operational simplicity. The vendor owns the retrieval quality, the scaling, and a lot of the prompt engineering. For public-facing documentation with no per-user personalization, the PII surface is naturally small because the corpus has no personal data in it.

Where it fits poorly: the moment you want real personalization, you have to feed user context into a system you do not control, and that context often leaves your boundary to reach the platform's models and logs. Governance of what the agent is allowed to say, and with whose data, sits in the vendor's console rather than in your own editorial review. You are trusting a third party's data handling for the most sensitive part of the interaction.

A concrete example: to personalize answers, you pass a user's plan tier, recent tickets, and account flags to the platform on every call. That payload is now in someone else's request logs and possibly their model provider's. With Sanity Context, the agent connects through the Sanity Context MCP endpoint to a Content Lake you own, and personalization is expressed as which governed content the agent retrieves, not as a stream of personal records shipped to an external service.

2. Content backend plus AI bolt-on

Structured content backends like Contentful, Strapi, and Payload give you a real schema for your knowledge, then add AI through an app framework, a LangChain integration, or a plugin. This is a meaningful improvement on raw vector stores because the content has shape: a product document is a product document, with typed fields, references, and an editorial workflow, and you can model the non-personal facts an agent should ground on separately from any personal record.

Where it does well: editorial governance of the source material. Content has owners, review states, and structure, so the corpus an agent retrieves from is something humans actually maintain. Keeping PII out becomes a modeling decision: you simply do not put personal records in the documents the agent can see.

Where it fits poorly: retrieval is still bolted on rather than native. The semantic search lives in an external service wired up through an app or plugin, so you are back to maintaining an embedding pipeline and reconciling it with the content backend. Hybrid retrieval, combining keyword precision with semantic recall, usually means standing up and tuning a separate search stack alongside the CMS.

A concrete example: a team models clean, PII-free product and policy documents in their CMS, then exports them nightly to an external vector service for the agent to query, and spends as much time on the sync as on the content. Sanity collapses that gap. The Content Lake is both the structured content store and the retrieval surface, so the governed, personal-data-free content an agent grounds on is queried directly rather than copied into a parallel system that can drift.

1. Structured, content-grounded personalization in the Content Lake

The strongest approach inverts the problem. Instead of pushing personal data into the agent and defending against leaks, you keep personalization in the content layer and never let personal records enter the agent's context at all. Sanity is the Content Operating System for the AI era, and on this pattern the agent personalizes by choosing which governed, non-personal content to retrieve for a given segment, role, or entitlement, rather than by being handed a dossier on the user.

What makes this work is native hybrid retrieval inside the Content Lake. A single GROQ query blends semantic recall and keyword precision using text::semanticSimilarity() and match(), combined with score() and boost(), so you get relevance without standing up a separate search stack. dataset embeddings are tied to the content, so when a document changes or is deleted the retrieval surface updates within minutes, which is the property right-to-erasure actually requires. There is no parallel index quietly retaining personal data.

Governance is the other half. Editors stage agent instructions in the Studio and roll them out through Content Releases, reviewing how the agent will behave before it ships, the same way they stage the website. Knowledge Bases turn datasets, websites, PDFs, and support databases into agent-readable documents on that same retrieval path, and Agent Actions express schema-aware workflows without ad hoc prompt plumbing.

A concrete example: a returning customer's tier and locale select which governed content variants the agent retrieves, so the answer is personalized while the personal identifier never leaves your systems and never reaches the model. The personal layer and the retrieval layer stay separate by design, which is what makes leakage a modeling choice you have already made, not an incident waiting to happen.