Head-to-head · updated 13 September 2026

DataShield vs Cortex Search: who gets to read what the index already swallowed?

Snowflake Cortex Search is the retrieval half of RAG, sold as a feature of the warehouse you already own. Their docs are direct about it: it gives you "low-latency, high-quality 'fuzzy' search over your Snowflake data." You pick a source query, Snowflake picks an Arctic or Voyage embedding model, and you get hybrid keyword plus vector search with semantic reranking. No vector database to run. No embedding pipeline to babysit. If your documents already sit in Snowflake, this is the cheapest good retrieval you will ever switch on.

We do the same job from a different angle. DataShield is a self-hosted data plane and control plane for agents, and RAG is one part of it. Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. Embeddings are computed locally with nomic-embed-text, so no text leaves your machines to be vectorized. Every governed tool call is re-checked against the agent's current authority, and every decision is sealed into a hash chain you can verify without trusting us. Most Snowflake shops will run both. Below is the honest split, including the rows Cortex Search wins outright.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

The documents hold PHI, card data or secrets, and you want the sensitive values swapped for tokens before anything gets embedded. The index then holds surrogates, not the real thing.
Someone will ask you to prove an agent's retrieval log was not edited. An auditor, a regulator, or Article 12 of the EU AI Act. Our chain answers with math. Run the verifier.
Different readers must see different rows. A Cortex Search service searches with owner's rights, so the index can return rows the asking user could not read in the source table.
The rule says the data, the embeddings and the keys stay on your side. We are self-hosted. Snowflake is not, and no region setting changes that.

Pick Cortex Search when

Your corpus already lives in Snowflake. There is no pipeline to build, no data to move, and no second bill to explain.
You want managed embeddings and semantic reranking with nobody on staff tuning an index. Four embedding models, one command, done.
Scale is the hard part. A single service indexes up to 400 million rows, and the refresh runs on Dynamic Tables mechanics you already understand.
You want retrieval, text-to-SQL, charts and a Python sandbox behind one agent API, with a vendor your procurement team has already cleared.

Bottom line: Cortex Search is very good at finding the right passage fast. It is not trying to be the layer that decides which agent may read it, hide the sensitive value before it gets embedded, or prove later what happened. If your corpus is public or internal-safe, use theirs. If it is regulated, the index itself becomes the risk, and that is our part of the job.

Feature by feature

Competitor cells describe what Snowflake's public site, docs, and press releases say as of the date above. If we have mischaracterised something, email support@myorg.ai and we will correct it, credited.

What matters	DataShield	Cortex Search	Edge
Retrieval quality and scale	Hybrid retrieval on Postgres pgvector: a tsvector keyword leg and a vector leg, 768 dimensions from nomic-embed-text. Good, plain, and ours to tune. We publish no accuracy benchmark, because we have not run one worth publishing.	Managed hybrid search with semantic reranking and four embedding models, including a 32,000-token multilingual option. A service indexes up to 400 million rows and serves 20 queries per second by default. This is a real engineering asset and we are not going to pretend otherwise.	◇
Who can read the index	Retrieval runs under the agent's own tool token. Corpus visibility is explicit: personal or org-visible, moved by an audited promote or demote. Chunk views apply read-time masking, and the keyword index is rebuilt from the masked text so search cannot be used to probe for a hidden value.	Services search with owner's rights. Snowflake's own docs warn that any role able to query a service "may query any of the data the service has indexed, regardless of that role's privileges on the underlying objects," including rows behind row-level masking policies. Per-user row filtering is not how it works.	◆
Data handling and tokenization	Deterministic, join-preserving, vault-reversible tokens applied at ingest, plus quasi-identifier generalization (dates to year, decade or age band; ZIPs to 3 or 4 digits; partial phones, SSNs and emails) with a measured cardinality-reduction score per column. Detokenization is admin-tier, tenant-scoped, and refused if the audit write fails.	The Cortex Search docs we read describe no PII or PHI detection, tokenization or generalization step before text is embedded. Platform masking policies exist in Horizon, and the owner's-rights note above tells you how far they reach into a search service.	◆
Where embeddings are computed	Locally, by a model that runs on your own hardware. No chunk text is sent to a third party to be turned into a vector. For a PHI corpus that is the difference between a short review and a long one.	Snowflake computes them for you on Snowflake infrastructure, billed as EMBED_TEXT tokens. That is a feature for most buyers and a blocker for a few. Voyage is a third-party model family served inside the platform.	◆
Prompt egress	We do not proxy your LLM traffic. We do gate every value that leaves a governed dataset for a prompt, and a PHI dataset refuses an endpoint without a BAA. A classified column with no configured treatment is redacted rather than passed through.	Cortex Agents call models inside Snowflake, which keeps traffic on the platform. We found no published per-column egress gate or BAA-aware endpoint refusal for prompt assembly.	◆
Audit evidence	SHA-256 hash chain with Ed25519-signed checkpoints that are themselves chained. Verification returns clean, attested damage, or tampered, and names the failure: tampering, insertion, deletion, or truncation. Try the verifier.	The Cortex AI Gateway gives "a centralized, end-to-end record of agent activity." Agents ship threads, logs and traces. The managed MCP doc says nothing about audit logging. We found no published tamper-evidence mechanism.	◆
Agent authorization	Every governed tool call passes a scope ceiling, a consented-tool allowlist, an authority tier, a metering guard, and a revocation re-check before dispatch. The call fails closed.	Snowflake OAuth plus role-based access control, with tool discovery gated by grants on the MCP server object. SQL execution defaults to read-only, which is a sensible default. The unit of authority is still the role, not the call.	◆
Break-glass	Scoped, time-boxed emergency access for agents, admin and IP-allowlist gated, auto-revoking, and impossible to quietly remove from the log.	Not described in their public material.	◆
GDPR erasure	Crypto-shred of per-subject key material, cited to ISO/IEC 27040 and Article 17, plus ISO 27560 consent receipts. The audit chain still verifies afterwards.	Delete the row and the service picks it up on its next refresh, at the lag you set. That removes the row. It does not destroy key material, and it says nothing about vectors already served into a model context.	◆
MCP and agents	More than 200 MCP tools across Ontology, Auth, Corpus and Lighthouse, with tool tokens carrying scope ceilings, RFC 8693 delegation with an enforced ceiling, and per-call metering attributed to the agent.	A managed MCP server with five tool types and a cap of 50 tools per server, plus Cortex Agents, which orchestrates search, text-to-SQL, charts, a Python sandbox and web search. The July 2026 Cortex AI Gateway governs agent access across more than 100 MCP servers.	◈
Deployment	Self-hosted in your own cloud or data center, or a dedicated single-tenant server we operate. Docker images for Auth, Ontology, Corpus and Lighthouse, with a signed deploy manifest Guardian verifies. Ed25519 audit-signing keys can live in your KMS or HSM. HMAC tokenization keys sit in your environment today, not in a KMS.	SaaS only, on AWS, Azure or GCP. Virtual Private Snowflake is still Snowflake-operated. The managed MCP server is not supported in government regions.	◆
Maturity signals	Auth, Guardian and Lighthouse are live in production (Guardian and Lighthouse since April 2026). SOC 2 not yet certified, and we say so.	Public company, thousands of enterprise accounts, platform-level certifications, and named reference customers such as Thomson Reuters and Sanofi. We cannot match that and will not try.	◇
Pricing	Published model, scoped instant quote, no sales wall.	Consumption across several meters at once: warehouse compute for refresh, EMBED_TEXT tokens, serving compute per GB per month, and storage. Dollar rates are not on the page. You are sent to the Service Consumption Table.	◆

◆ DataShield leads◇ Cortex Search leads◈ comparable

Snowflake claims are drawn from docs.snowflake.com, snowflake.com, and Snowflake's own press releases, last checked 13 September 2026. We link them below rather than work from memory.

Three things you get here that you won't get from a warehouse-native retrieval service

Tokens go in, not secrets

An index is a copy. Once a social security number is chunked, embedded and served, it lives in more places than you can point at. We take the value out at ingest and park the vault outside the query path. What gets embedded is a surrogate. A hijacked agent pulls back a token that resolves to nothing it can use. How the data plane works.

Proof that leaves with you

Retrieval logs matter now. An examiner will ask which agent read which document in March, and whether the record was edited since. Ours is a hash chain with signed checkpoints, and the verifier says what broke, not just that something did. It keeps verifying after export, after a migration, in front of someone with no login to your platform. Try it in your browser, no signup.

Authority that can change mid-flight

An analyst leaves on a Friday. Their research agent is 20 minutes into a 40-minute job over the policy corpus. With DataShield the next governed tool call is re-checked against current authority and fails closed. Not at the next token refresh. The next call. How Auth does it.

Where Snowflake Cortex Search is genuinely stronger

Let us be fair about the thing we are up against. Cortex Search is a serious managed retrieval service. You point it at a query, it handles chunking, embedding, refresh and reranking, and it scales to 400 million rows without you learning a new database. The model menu goes from a 768-dimension English default up to a multilingual model with a 32,000-token window. Refresh reuses Dynamic Tables mechanics, so the behaviour is already familiar to your team. Around it sits Cortex Agents, which strings retrieval together with text-to-SQL, charts, a Python sandbox and web search behind one API. Then the Cortex AI Gateway, announced 28 July 2026, adds access policies and an end-to-end record of agent activity across more than 100 MCP servers. If the data is already in Snowflake, building your own retrieval stack to match this is a strange way to spend a quarter.

Here is the push-back that matters, and it is one sentence from their own documentation. A Cortex Search service "performs searches with owner's rights," so any role that can query the service can reach anything the service indexed, including rows behind masking policies that role could never read in the source table. That is a reasonable trade for a product built to make search fast. It is a poor trade when the caller is an agent, because an agent does not know it is holding something it should not have, and it will happily quote it into an answer. Add three more gaps that regulated buyers feel: nothing in the Cortex Search docs tokenizes or generalizes sensitive fields before the text is embedded, the audit story is a record rather than a proof, and there is no way to run any of it on your own hardware. We built for the case where those three things are the requirement, not the nice-to-have. For everything else, honestly, use theirs.

Questions worth asking both of us

These are the questions we would want answered if we were the ones buying. Ask them on every call, ours included.

Can you cryptographically prove an audit log entry wasn't deleted?

DataShield: yes. Each record commits to the one before it, checkpoints are Ed25519-signed and chained, and the verdict tells deletion apart from truncation and from tampering. Try it on a sample chain at /verify. Snowflake: the Cortex AI Gateway keeps an end-to-end record of agent activity, and agents produce threads, logs and traces. We found no published tamper-evidence mechanism. Ask them to show one, and ask who can write to the table.

What happens to a revoked agent mid-session?

DataShield re-checks authority on every governed tool call, so revocation lands on the very next call and the context drops to anonymous. Snowflake evaluates role grants, and pulling a grant stops new work, but we could not find published mid-session revocation semantics for an in-flight Cortex Agent or MCP session. Ask how long a compromised agent keeps working after you cut its access.

How does GDPR erasure interact with the audit trail?

DataShield crypto-shreds per-subject key material and issues an ISO 27560 consent receipt. Actor identities in the chain are HMAC-committed, so the evidence still verifies once the subject is gone. With Cortex Search you delete the source row and wait for the refresh lag you configured. That is a delete, not key destruction, and it leaves open what to do about text a model already saw. Ask for the mechanism, not the workflow.

Does Cortex Search apply row-level security per user?

Not in the way most people assume, and this is the question to ask first. Their docs say services search with owner's rights, and that a role able to query a service can reach data the service indexed even where that role has no privilege on the underlying objects, including rows behind masking policies. The usual fix is attribute filters you pass at query time, which means your application is now the access control. Our answer is different: sensitive values are tokenized before indexing, so the index does not hold the thing you were protecting.

We are all-in on Snowflake. Do we rip out Cortex Search?

No, and anyone who tells you to is selling harder than they are thinking. Keep it for the corpora where speed matters and the content is internal-safe. Add us where the corpus is regulated, where the reader is an agent you cannot fully trust, or where the evidence has to verify outside the platform. Plenty of teams will sensibly run both. We also have a page on the governance layer next door: DataShield vs Snowflake Horizon.

Can you index data that lives in Snowflake today?

Not as a catalog provider. Our in-place scan and profile is GA for PostgreSQL only, and Snowflake, BigQuery, Databricks and S3 are declared with no handler built yet. We would rather say that now than have you find out in week three. What works today: ingest the documents you want agents to read from files, URLs or S3-compatible storage, extract PDF, DOCX and EML text, tokenize at ingest, and serve retrieval over MCP under Auth.

Does DataShield have SOC 2?

Not yet, and we will not imply otherwise. Snowflake carries platform certifications we cannot match, and for some buyers that settles it. What we offer instead is a published threat model, a verifier anyone can run, and design-partner terms that include source escrow so a small vendor is not a single point of failure. Details on the security page.

Cortex Search "enables low-latency, high-quality 'fuzzy' search over your Snowflake data," combining vector search, keyword search and semantic reranking, with managed Arctic and Voyage embedding models from 768 to 1024 dimensions and a materialized result limit of 400M rows. — docs.snowflake.com, 13 Sep 2026
"Cortex Search Services perform searches with owner's rights," and "any role with sufficient privileges to query a Cortex Search Service may query any of the data the service has indexed, regardless of that role's privileges on the underlying objects," including rows behind row-level masking policies. — docs.snowflake.com, 13 Sep 2026
The Snowflake managed MCP server exposes five tool types (CORTEX_AGENT_RUN, CORTEX_SEARCH_SERVICE_QUERY, CORTEX_ANALYST_MESSAGE, SYSTEM_EXECUTE_SQL, GENERIC), caps a server at 50 tools, defaults SQL execution to read-only, and is not supported in government regions. — docs.snowflake.com, 13 Sep 2026
Cortex Agents is GA and orchestrates Cortex Search, Cortex Analyst, a Python code execution sandbox, chart generation, custom tools, MCP connectors and web search, billed across orchestration tokens, index size, warehouse compute and external tool calls. — docs.snowflake.com, 13 Sep 2026
Cortex AI Gateway, announced 28 July 2026, governs first- and third-party agents "with support for more than 100 MCP servers" and provides "a centralized, end-to-end record of agent activity." — Snowflake press release, 28 Jul 2026
Snowflake's pricing page lists four editions and defers all dollar rates to an external Service Consumption Table, so Cortex Search cost must be assembled from several consumption meters rather than read off a page. — snowflake.com, 13 Sep 2026

Other head-to-heads

Same market

Get free Demo Center access

You've seen the proof

Ready for a number? Scope your deployment and we'll price it against your own economics.

Get your quote →