In 2009, if you brought your own laptop to work, the IT department treated you like a security incident. By 2015, “bring your own device” was official policy at most companies. Nothing about the laptops changed. What changed was the infrastructure around them: identity standards, device management, sandboxed apps. Once the plumbing existed, the weird idea became the obvious one.
Personal data is at the 2009 stage. Today, every AI service builds its own private picture of you, and bringing your own is not really possible. This essay is about the piece of plumbing that changes that — the Model Context Protocol — and what it looks like to use it in practice.
The problem MCP solves
An AI assistant is only as good as its context. Everyone who uses these tools daily learns this within a week: the first ten minutes of a session go to re-explaining who you are, what you are working on, what you like, and what you have already tried.
The assistants' answer to this is built-in memory, and it works — inside one product. ChatGPT's memory does not help you in Claude. Claude's context does not follow you to a coding assistant or a travel-planning tool. Each service accumulates its own copy of you, none of them complete, none of them portable, all of them owned by someone else.
Before late 2024, connecting your own data source to an AI meant writing a custom integration for each assistant — one for OpenAI's function-calling format, another for Anthropic's, another for whatever came next. Every data source times every assistant. Integration math like that is why personal context stayed siloed: nobody builds N×M bridges.
One port for context
The Model Context Protocol, open-sourced by Anthropic in November 2024 and since adopted across the industry — including by OpenAI — replaces the N×M mess with a single standard interface. A data source implements MCP once, and any assistant that speaks the protocol can connect to it.
The USB-C analogy is used a lot, and it is accurate in a specific way that is worth spelling out. Before USB-C, every device had its own charger, and the cable drawer in your house was a museum of dead standards. USB-C did not make chargers better. It made them interchangeable — and interchangeability changed who held the power. You stopped caring which brand of charger you owned, because they all fit.
MCP does the same thing to personal context. When any assistant can plug into your data source, your context stops being a feature of the assistant and becomes a possession of yours. You stop caring which assistant you use this year, because your context fits all of them. That is what “portable asset” means in practice: the value stays with you when the tools change.
What an MCP connection actually is
Strip away the abstraction and an MCP connection is refreshingly concrete: it is a URL that your AI client knows how to call, plus a menu of things it can ask for.
The menu comes in three parts. Tools are functions the assistant can call on demand — Personal Hub's server exposes seven, including get_profile_summary (a compact overview of what you have shared), search_context (find something specific without loading everything), and get_recent_changes (fetch only what changed since last time). Resources are data loaded automatically when the session starts, so the assistant knows your basics before your first message. Prompts are suggested interactions, like “get to know me.”
Two details matter more than the rest. First, the read tools are read-only: nothing an assistant does through the connection can modify your vault. When an AI learns something new about you mid-conversation, the most it can do is file a suggestion, which sits in a queue until you approve, edit, or dismiss it. Second, the connection serves only what you selected when you set it up. It is not a pipe into your data; it is a window onto the specific fields you chose. The full technical reference is in the Personal MCP documentation.
Connecting a hub to Claude or ChatGPT
Here is the actual workflow, because it is shorter than the explanation of it.
- In Personal Hub: open the Share page and choose the service you want to connect. You pick what to share, field by field — nothing is shared by default. Your name and interests but not your birthday; purchase categories but not amounts; whatever split you want. The hub generates a connection for exactly that selection.
- In Claude: either connect through Claude's connector directory (an OAuth flow — find Personal MCP, click Connect, approve what to share), or go to Settings → Connectors, add a custom connector, and paste your connection URL.
- In ChatGPT: Settings → Connectors → Advanced, enable Developer Mode, add a connector, paste the URL. (Requires a paid plan.)
- Anywhere else: any client that supports remote MCP servers takes the same URL.
From then on, the assistant starts every conversation already knowing what you chose to tell it. No pasted context blocks, no “as I mentioned before.” And the connection stays live: update your preferences in your hub once, and every connected assistant picks up the change on its next read.
Why per-connection encryption matters
There is an obvious objection to everything above: a hub that serves your context to AI services sounds like a honeypot. One database with everyone's most personal context is exactly the thing you would not want to exist — if it were readable.
So the encryption design carries the weight, and it is worth understanding even if you never look at the code. Your vault — the master copy of your data — is encrypted on your device with a key derived from your password, and that key never leaves your browser. We store ciphertext; we cannot read your vault. That part never changes, connection or no connection.
When you connect an AI service, something separate happens: each connection gets its own key, generated in your browser, and its own encrypted copy of only the fields you chose. During an active AI request, the shared copy — never your vault — is decrypted briefly in server memory to answer the query, and the key is discarded immediately after.
The consequences of this design are the practical points:
- Connections are isolated. Claude's key cannot decrypt what you shared with ChatGPT. Different services can see entirely different slices of you.
- Revocation is real. Disconnecting a service deletes its encrypted copy and invalidates its connection, immediately. There is no “request deletion and hope” step.
- The blast radius is capped. If one connection's key were compromised, the exposure is the fields you chose for that one connection — not your vault, not your other connections.
One honest caveat belongs here: once your data reaches an AI service, it is subject to that service's own privacy policy. MCP controls what leaves your hub and lets you cut off access; it cannot reach into Claude or ChatGPT and control what happens next. Choose what you share with that in mind. The full accounting of what is encrypted where — including the trade-offs — is on our security page.
The bigger picture
“Bring your own device” won because the alternative was carrying two phones. “Bring your own data” will win because the alternative is maintaining a separate, partial, unportable copy of yourself inside every AI product you use — re-teaching each one from scratch, and losing everything each time you switch.
The protocol layer now exists. What it enables is a genuine shift in ownership: your context becomes something you hold and grant access to, rather than something platforms accumulate about you. We laid out the full argument for why that shift matters in The Case for Data Sovereignty, and what it means for AI memory specifically in AI Will Remember You.
If you want to try it, Personal Hub is free to start — build a small profile, connect it to the assistant you already use, and ask it what it knows about you. The first personalized answer is the moment the idea clicks.