← Back to all posts

Is MCP Safe for Sensitive Data? What Actually Happens When AI Agents Access Your Records

By Rami Akeela, Ph.D., Founder & CEO, Nera Systems

Short answer: it depends entirely on what "safe" means to you. Most AI integrations available today, including the Model Context Protocol (MCP) servers now shipping from billing platforms, CRMs, and ERPs, protect your data from unauthorized people. Almost none of them protect your data from the model itself. If your compliance requirement is "control who can access this," that distinction may not matter. If your requirement is "this data can never reach a third-party AI model in a readable form," it's the only thing that matters.

This is the question worth understanding before connecting any AI tool to financial records, health data, deal terms, or anything else you'd hesitate to hand a vendor unsupervised.

How most AI-to-data connections actually work today

When a company connects Claude, ChatGPT, or another AI client to its billing system, CRM, or database through MCP, the typical flow is simple: the AI agent requests a record, the server checks whether the request is authorized, and if it is, the full record, plaintext, unredacted, gets returned directly into the model's context. The model reads it the same way a human would reading a screen.

This is true across most of the SaaS platforms that have shipped AI integrations in 2025 and 2026. Billing platforms return complete invoice and customer records to whatever AI client is connected. Payment platforms expose payment history and account data the same way. CRM and support platforms do the same with contact records and tickets. The safeguard in every case is the same: authenticate the client, scope its permissions, and in some cases recommend that a human review actions before they execute. None of this prevents the model from seeing the data once a request is authorized. It only governs who's allowed to ask.

That's a reasonable tradeoff for a lot of data. Nobody needs cryptographic guarantees to let an AI summarize open support tickets. It becomes a different question when the data is a patient chart, a cap table, or a set of financial statements still under audit.

The three tiers of AI data protection, and why they're not the same thing

Most conversations about "AI data security" collapse three different guarantees into one. They're worth separating, because each answers a different question about who the data is actually hidden from.

Approach What it protects against Does the model see plaintext?
Permission-based governance Unauthorized people or systems requesting the data Yes, once a request is authorized
Infrastructure-level confidentiality (secure enclaves, confidential computing) The cloud provider, host, or other tenants observing the data Yes, the model processes plaintext inside a protected hardware boundary
Model-level isolation The model itself, and by extension the AI vendor, ever receiving readable data No, by design

Permission-based governance is the industry default. It answers "who can ask for this," not "what happens to it once someone does." It's implemented through API keys, OAuth scopes, and role-based access control, standard, well-understood security practice, but it doesn't change what the model receives. This is the approach behind most AI integrations shipping today across billing, CRM, and ERP software, including platforms from Chargebee, Stripe, HubSpot, Snowflake, ServiceNow, Zendesk, and others that have added AI-agent connectivity in 2025 and 2026.

Infrastructure-level confidentiality is a step further and often gets described in language that sounds like the first tier, but is a stronger and more specific claim. Technologies like hardware-based secure enclaves, the approach behind vendors like Opaque Systems, decrypt data only inside an isolated, verified execution environment, so the cloud provider, the host operating system, and other tenants on the same infrastructure cannot see it. This is a real and valuable guarantee. It is not the same as "the model never sees the data." Inside that protected boundary, the model computes on the actual plaintext values. What's excluded is everyone outside the boundary, not the model doing the computation.

Model-level isolation is the least common and the hardest to build. Here, the data is never presented to the model in a readable form at any point, not briefly, not inside a protected enclave, not anywhere. Some privacy-infrastructure vendors are working in this direction. Protopia AI's Stained Glass Transform, for instance, converts data into randomized representations before a model ever sees it, representations that are irreversible by design, so the original value can't be reconstructed from them. That works well for tasks where the model only needs to produce a judgment or a classification, flagging an anomaly, recognizing a pattern, sorting a category, without ever needing to state the underlying value back. It's a different problem when the task itself requires the model to compute on and report exact figures: a variance between two quarters, a specific dollar amount, a sum that has to match a client's actual books. An irreversible transform that's optimized per-task isn't built for that kind of exact, interactive numerical work. Nera Systems is built specifically for it.

How specific platforms map to these tiers

Platform Category What happens to your data
Billing platforms with AI/MCP integrations (e.g., Chargebee, Stripe, Zuora) Permission-based governance Full records returned to the connected AI client once a request is authorized
CRM/ERP platforms with AI/MCP integrations (e.g., HubSpot, ServiceNow, Zendesk, NetSuite, Workday) Permission-based governance Full records returned to the connected AI client once a request is authorized
Data platforms (e.g., Snowflake Cortex, Databricks) Permission-based governance, with access controls inherited from the underlying data layer Query results returned to the agent as plaintext, filtered by existing row/column-level permissions
CRM with configurable masking (e.g., Salesforce Agentforce) Partial infrastructure-level protection Fields configured for masking are withheld; anything not configured for masking reaches the model as plaintext
Tokenization vendors (e.g., Skyflow) Partial, field-level isolation Fields predefined as sensitive are tokenized before reaching the model; all other fields and surrounding context reach the model as plaintext
Confidential-computing vendors (e.g., Opaque Systems) Infrastructure-level confidentiality Data is decrypted to plaintext inside a hardware-protected enclave; the model processes it there, the surrounding infrastructure cannot
Representation-transform vendors (e.g., Protopia AI) Model-level isolation, for classification/judgment tasks Values are transformed into irreversible representations before the model computes on them; validated for task accuracy (classification, pattern recognition), not for exact-value computation like financial variance or sums
Nera Systems Model-level isolation The model never receives the underlying data in a readable form. Usable directly by a finance or compliance team today, no engineering build required to get there

This is not an exhaustive list of every AI-to-data integration on the market, new ones are shipping every quarter, but it's representative of where most current approaches sit. If you're evaluating a platform not listed here, the question to ask its vendor is simple: not "do you have guardrails," but "does your model ever receive our data in a form it can read, and if not, who is it actually hidden from?"

What is query isolation?

Query isolation is an architecture in which the AI model that processes a request never receives the underlying data in a readable form. Instead of passing records, documents, or database results directly into the model's context, the system structures the request so the model can compute an answer without the actual values ever existing anywhere the model can read them. The result reaches the user. The raw data never passes through the model to get there.

This is the third tier described above, and it's a meaningfully different guarantee than permissioning or infrastructure confidentiality. It answers a question those approaches don't: what happens if the thing you need to keep out isn't a hacker or an unauthorized employee, but the AI model and the vendor behind it? (That distinction, a promise not to look versus an inability to look, is the subject of The Two Perils of AI Risk.)

For industries where that question matters, healthcare, financial services, private equity, accounting, pharma, real estate, "our infrastructure has access controls" and "our infrastructure has confidentiality protections" are both reasonable answers to a security questionnaire. Neither answers whether the AI model itself ever saw the patient's chart, the deal terms, or the unaudited financials. Query isolation is built specifically to make that question answerable with "no."

Nera Systems applies query isolation through its ChatApp, built specifically for regulated enterprises running structured, numerical analysis, financial statements, portfolio data, compliance reporting, on top of frontier models like Claude, Gemini, and GPT, without the underlying data ever reaching the model in the clear. (For the broader architecture, see What Is Confidential AI.)

The practical difference shows up in two places: what the task actually requires, and who can use the result. Protopia's transform is validated for tasks where the model produces a classification or a judgment, not a value, which is a real and useful guarantee for the problems it's built for. It's not the same guarantee a spreadsheet-level question needs: "what's the variance between these two numbers" requires the actual numbers to survive the computation, not a task-accurate approximation. Skyflow and Opaque, meanwhile, are infrastructure: a tokenization vault or an enclave runtime that an engineering team integrates into an application that doesn't exist yet. That's the right choice for a company building a custom AI product from scratch. It's also weeks of engineering work before anyone on a finance or compliance team gets an answer to a question.

Nera skips that step. A firm's own analyst opens the ChatApp and asks a question directly against real financial statements, portfolio data, or compliance records, the same way they'd use any AI chat tool, and gets an answer back without ever routing the request through an engineering build. Take a mid-sized accounting firm doing quarterly close: reconciling variance across a dozen client accounts used to mean pulling numbers into spreadsheets by hand, because the client data was under an engagement letter that made uploading it to a consumer AI tool a non-starter. With Nera, the same team asks the same questions directly against the real numbers, the analysis that used to take days happens in one sitting, and the client's financials never exist anywhere the model could read them.

That's the choice this reduces to for a regulated enterprise evaluating options: build the isolation layer yourself and then build the application on top of it, or start using it today. Nera's current customers are accounting and financial-analytics teams, with the same architecture extending into financial services, private equity, healthcare, pharma, CPG, and real estate as the pattern repeats: any team sitting on data too sensitive for a frontier model, with a real analytical question they can't currently ask.

Why this matters more as AI agents do more

A pattern worth watching: as agent frameworks take on more autonomous work, orchestrating multi-step tasks, acting on data rather than just answering questions about it, the number of moments where sensitive data could reach a model doesn't shrink. It grows. Every additional step an agent takes on your behalf is another point where data might flow through a model's context. Agentic AI raising the stakes on data exposure isn't a reason isolation matters less. It's the reason it matters more.


Rami Akeela, Ph.D., is the founder and CEO of Nera Systems. He has spent more than 20 years in hardware, security, and cryptography, previously founding DZK and co-founding Fabric Cryptography. Nera Systems builds AI infrastructure for regulated enterprises using query isolation, an architecture in which the AI model never receives the underlying data. Learn more at nera.systems.

Frequently asked questions

Is MCP inherently insecure?
No. MCP is a protocol, not a security posture, comparable to how HTTP itself is neither secure nor insecure until you look at what's built on top of it. Its safety in any given deployment depends entirely on the permissioning, guardrails, and data-handling architecture of the specific MCP server and client involved, not on MCP itself.
Does connecting an AI tool to my billing or CRM system expose my data to the model?
In most current implementations, yes. Once an AI client is authorized to query a connected system, the records it retrieves are typically returned in full to the model's context. This is standard practice across most billing, CRM, and ERP platforms that have shipped AI integrations, and it's a reasonable tradeoff for lower-sensitivity operational data. It's a different calculation for regulated or highly sensitive records.
Is tokenization the same as query isolation?
No. Tokenization typically applies to a defined set of fields a company flags as sensitive, replacing those specific values with placeholder tokens before the model sees them. Everything outside that defined field set, including surrounding context, still reaches the model as plaintext. Query isolation applies to the data as a whole, not a predefined subset of fields.
Does confidential computing mean the AI model never sees my data?
Not exactly, and this is a common point of confusion. Confidential computing (secure enclaves, trusted execution environments) protects data from the cloud provider, the host system, and other tenants sharing the same infrastructure. Inside the protected enclave itself, the model does process the data in a readable form to perform inference. It's a strong guarantee against external observers, not a guarantee that the model itself never received plaintext.
What industries need model-level data isolation, not just access controls?
Any industry where the AI vendor or model provider itself needs to be excluded from seeing the underlying data, not just unauthorized third parties. This typically includes healthcare, financial services, private equity, accounting, pharma, and other sectors handling regulated or contractually protected data, where the identity of who can see the data, not just who is authorized to ask for it, is itself the compliance question.