Head-to-head · updated 13 September 2026

DataShield vs Google Cloud DLP: who proves the agent was allowed to re-identify?

Google Cloud DLP is now called Sensitive Data Protection, and it is very good at its job. It profiles your BigQuery, Cloud SQL, Cloud Storage, S3 and Azure Blob estate, it ships 200+ built-in detectors, and its de-identification API does reversible tokenization that keeps joins intact. The pricing is on a public page. If you run Google Cloud, turn it on.

We do something else. Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. Every governed tool call is checked against the agent's current authority, and each decision is sealed into a hash chain you can verify without trusting us. Most buyers we talk to end up running both. Below is the honest split, including the rows Google wins.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

Someone will one day ask you to prove an agent's access log wasn't edited. Cloud Audit Logs are retained. Ours are chained and signed, and the verifier names the failure. Run it yourself.
Your agents live in more than one cloud, or in your own racks. We run self-hosted or dedicated single-tenant, with your keys. See the architecture.
You need to pull an agent's authority mid-session and have the very next tool call fail, not wait out a token. How Auth does it.
The detokenization call is the risk. Ours is a privileged, logged vault operation with a scope ceiling and an authority tier attached to the agent that asked.

Pick Google Cloud DLP when

You need sensitive-data discovery across a big estate. Continuous profiling of BigQuery, Cloud SQL, Cloud Storage, Vertex AI tuning jobs, S3 and Azure Blob. We are not a discovery tool and won't pretend to be.
You want re-identification risk analysis. Their k-anonymity, l-diversity and k-map estimation jobs are the real thing, and Google charges nothing extra for them beyond BigQuery compute.
You need FPE-FFX, so the token has to look like a credit card number to keep an old system happy. We don't do that. Ours are TOK_ prefixed HMAC values.
Your estate is Google Cloud and your security team already owns Security Command Center. Discovery comes bundled, the bill is one bill, and there is no new vendor to onboard.

Bottom line: Google finds and de-identifies the data. We govern which agent may touch it and keep proof of what happened. If you run GCP, run both. If your agents run anywhere else, start here.

Feature by feature: cloud-native DLP against an agent control plane

Competitor cells describe what Google's public docs and pricing page say as of the date above. If we've mischaracterised something, email support@myorg.ai and we'll correct it, credited.

What matters	DataShield	Google Cloud DLP	Edge
Audit evidence	SHA-256 hash chain with Ed25519-signed checkpoints that are themselves chained. Verification names the failure: tampering, insertion, deletion, or truncation. Public verifier.	Activity lands in Cloud Audit Logs with retention and export. We found no cryptographic tamper evidence for the log itself.	◆
Agent authorization	Every governed tool call passes a scope ceiling, a declared authority tier, and a revocation re-check before dispatch. Revocation lands mid-session.	IAM roles on the DLP API. Content policies return ALLOW or BLOCK on content sensitivity, which is a different question from whether this agent may call this tool.	◆
Break-glass	Scoped, time-boxed emergency access for agents that auto-revokes and can't be quietly deleted from the log.	Not offered. You'd build it from IAM conditions yourself.	◆
GDPR erasure	Crypto-shred of per-subject key material plus ISO 27560 consent receipts. Actor identities are HMAC-committed, so the chain still verifies after erasure.	Not a stated function. Discovery tells you where the subject's data sits; deleting it across the estate is your job.	◆
Tokenization and de-identification	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 a privileged, logged operation.	Three documented methods: deterministic encryption with AES-SIV, FPE-FFX, and HMAC-SHA-256 hashing. The first two reverse. All three keep referential integrity. Plus masking, bucketing and date shifting.	◇
Sensitive-data discovery	We scan, profile and classify a live PostgreSQL source in place, with no rows leaving it. Columns get labelled against 129 field classes covering PII, PHI, financial data and secrets, and the catalog carries a business glossary, typed lineage and stewardship queues. That is PostgreSQL today, not your whole estate: SaaS apps, cloud stores and endpoints are not ours, and the other database providers are declared but not built yet.	Continuous data profiling across BigQuery, Cloud SQL, Cloud Storage, Vertex AI tuning jobs, Amazon S3 and Azure Blob Storage, with 200+ predefined detectors.	◇
Re-identification risk analysis	We generalize quasi-identifiers (dates to year, decade or age band; ZIPs to 3 or 4 digits; partial phones, SSNs and emails) and report a measured cardinality-reduction score per column. We do not compute k-anonymity or l-diversity, and we won't say we do. Google does.	KAnonymityConfig, LDiversityConfig and KMapEstimationConfig jobs. No DLP surcharge; you pay the BigQuery compute.	◇
MCP and agents	Native MCP endpoints on Auth, Ontology, and Lighthouse. MCP tool tokens with scope ceilings, and per-call metering attributed to the agent.	No MCP surface in the docs. Content policies integrate with Gemini Enterprise, and new infoTypes detect Anthropic, Gemini and OpenAI API keys.	◆
Deployment	Self-hosted in your own cloud or data center, or on a dedicated single-tenant server we operate. Your keys.	A Google Cloud API. Hybrid jobs and content methods accept data from anywhere, but the service and the keys stay in Google Cloud.	◆
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.	Shipping since 2018 as Cloud DLP, inside Google Cloud's compliance envelope, with a release note most weeks.	◇
Pricing	Published model, scoped instant quote, no sales wall.	Fully published per-GB rates. Discovery at $0.03/GB, storage jobs at $1.00/GiB, content methods at $3.00/GiB inspected. Google's own page warns costs can get very high.	◈

◆ DataShield leads◇ Google Cloud DLP leads◈ comparable

Google Cloud claims are drawn from cloud.google.com product, pricing and release-notes pages, last checked 13 September 2026. We link them below rather than paraphrase from memory.

Three things you get here that you won't get from a cloud DLP API

Proof the log wasn't edited

A retained log is not a tamper-evident log. Ours is a hash chain with signed checkpoints, and the verifier tells you what went wrong, not just that something did. That's the property EU AI Act Article 12 and HIPAA §164.312(b) reviewers care about. Try it in your browser, no signup.

Authority that changes mid-flight

An analyst leaves on a Friday. Their agent is still grinding through a 40-minute job. With DataShield the next governed tool call is re-checked against current authority and fails closed. An IAM change is eventually consistent and the in-flight call rarely notices. How Auth does it.

One control plane across clouds

Sensitive Data Protection reaches S3 and Azure Blob for discovery, which is more than people expect. But the policy, the tokens and the evidence still live in one vendor's cloud. Ours run wherever you put them. See the architecture.

Where Google Cloud DLP is genuinely stronger

Let's be blunt about the parts we lose. Google has been shipping this since 2018 and it shows. The detector library is enormous and still growing: source-code types, document context types, image objects like passports and licence plates, and in August 2026 they added detectors for Anthropic, Gemini and OpenAI API keys. Discovery profiles your whole org on a schedule, including Vertex AI tuning jobs since February 2026. Risk analysis gives you k-anonymity, l-diversity and k-map estimation for the price of the BigQuery compute. Their de-identification reverses, keeps referential integrity, and includes FPE-FFX, which we do not have. And the rates are public, per GB, with a free first gibibyte. We score pricing a tie and mean it.

Here is the push-back. All of that operates on data at rest and on content you hand the API. None of it knows which agent is asking. A projects.content.reidentify call is an IAM-gated API call; the interesting question is what evidence exists six months later that the agent making it was allowed to, and that nobody trimmed the record. Google's August 2026 content policies return ALLOW or BLOCK on how sensitive the content is. That is a useful control and it is not the same control as an authority tier attached to an agent whose access you revoked at 4pm. Gartner expects most unauthorized agent transactions through 2028 to be internal policy violations, not attacks. Finding the PII does not answer a policy violation. Proving who touched it does.

Questions worth asking both of us

These are the questions we'd want answered if we were buying. Ask them on every vendor call, including ours.

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

DataShield: yes. Each record commits to the one before it, checkpoints are signed and chained, and verification tells deletion from truncation from tampering. Run it against a sample chain at /verify. Google: DLP activity flows into Cloud Audit Logs, which you can retain and export. We found no published tamper-evidence mechanism for the log itself. Ask them how you'd detect a removed entry.

What happens to a revoked agent mid-session?

DataShield re-checks authority on every governed tool call, so revocation bites on the next call. With Google you're relying on IAM. Ask how long a running job keeps its DLP permissions after you remove the role, and whether the in-flight call fails or completes.

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 after the subject is gone. Sensitive Data Protection has no erasure function; it shows you where the data is and you delete it. That is a reasonable division of labour, but someone has to own the second half.

Is this a Cloud DLP alternative, or something you run next to it?

Next to it, if you're on GCP. Their discovery and detectors are cheap and good, and we are not a discovery tool. We become the alternative when the estate spans clouds, when the deployment has to be self-hosted, or when the obligation is proving an agent's actions rather than finding the data. Run their discovery, tokenize at ingest here, and let Auth decide who gets to reverse it.

We need to de-identify data for Vertex AI. Why not just use the DLP API?

You can, and for one-off training-set prep you probably should. The gap shows up at run time. Their content methods de-identify what you pass them, per request, statelessly. We tokenize the dataset once at ingest, so the agent's MCP queries never see a raw value, and reversing one is a privileged operation tied to that agent's current authority with an audit record you can verify later.

Does DataShield have SOC 2?

Not yet, and we won't imply otherwise. Google Cloud's compliance envelope is far larger than ours and that's a fair thing to weigh. Auth is live a public threat model and a verifier anyone can run. Guardian and Lighthouse have been in production since April 2026. Design-partner terms include source escrow so a small vendor isn't a single point of failure. Details on the security page.

Google's positioning: "Discover and protect your sensitive data", with "200+ predefined detectors" and coverage "anywhere, on or off cloud". — cloud.google.com, 13 Sep 2026
Published rates: discovery $0.03 per GB profiled, storage jobs $1.00/GiB, content inspection $3.00/GiB, content transformation $2.00/GiB, first gibibyte free. — Sensitive Data Protection pricing, 13 Sep 2026
Risk analysis runs KAnonymityConfig, LDiversityConfig and KMapEstimationConfig jobs with no Sensitive Data Protection surcharge. — Sensitive Data Protection pricing, 13 Sep 2026
Deterministic encryption (AES-SIV) and FPE-FFX are reversible and preserve referential integrity; HMAC-SHA-256 hashing is not reversible. — Google pseudonymization docs, 13 Sep 2026
Content policies reached General Availability on 31 August 2026, returning an ALLOW or BLOCK verdict and integrating with Gemini Enterprise. Vertex AI tuning-job profiling landed 23 February 2026. — Sensitive Data Protection release notes, 13 Sep 2026
≥80% of unauthorized agent transactions through 2028 will be internal policy violations rather than attacks. — Gartner, 2026

Other head-to-heads

Cloud-native

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 →