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. It's good at its job. It scans BigQuery, Cloud SQL, and Cloud Storage. Plus S3 and Azure Blob. It ships 200+ built-in detectors. Its de-identification API does reversible tokenization. Joins stay intact. Pricing sits on a public page. Run Google Cloud? Turn it on.

We do a different job. We tokenize datasets at ingest. Agents query tokenized data over MCP. Detokenization is a gated, audited step. We check each tool call. It's checked against the agent's current access. We seal each decision into a hash chain. You can verify it without trusting us. Most buyers we talk to run both. Below is the honest split. It has the rows Google wins.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

Someone will ask you to prove an access log wasn't edited. One day, they will. Cloud Audit Logs are retained. Ours are chained and signed. 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. Your keys, always. See the architecture.
You need to pull an agent's access mid-session. The very next tool call should fail. Not wait out a token. How Auth does it.
The detokenization call is the risk. Ours is a privileged, logged vault step. It carries a scope ceiling. Plus an access tier tied to the asking agent.

Pick Google Cloud DLP when

You need sensitive-data discovery across a big estate. Think constant profiling of BigQuery, Cloud SQL, Cloud Storage, Vertex AI tuning jobs, S3 and Azure Blob. We are not a discovery tool. We 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. Google charges nothing extra beyond BigQuery compute.
You need FPE-FFX. The token has to look like a credit card number. That keeps an old system happy. We don't do that. Ours are TOK_ prefixed HMAC values.
Your estate is Google Cloud. Your security team already owns Security Command Center. Discovery comes bundled. One bill covers it. No new vendor to onboard.

Bottom line: Google finds and de-identifies the data. We govern which agent may touch it. We keep proof of what happened, too. Run GCP? Run both. Do 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. We use the date above. Did we get this wrong? Email support@myorg.ai. We'll fix it and credit you.

What matters	DataShield	Google Cloud DLP	Edge
Audit evidence	SHA-256 hash chain with Ed25519-signed checkpoints, themselves chained. It names the failure: tampering, insertion, deletion, or truncation. Try the verifier.	Events land in Cloud Audit Logs. Retention and export both work fine. We found no cryptographic tamper evidence, though. Not for the log itself.	◆
Agent authorization	Each checked tool call passes a scope ceiling. Plus a declared access tier. Plus a revocation re-check before dispatch. Revocation lands mid-session, not after.	IAM roles sit on the DLP API. Content policies return ALLOW or BLOCK on content risk. That's a new question, though. It's not whether this agent may call this tool.	◆
Break-glass	Scoped, time-boxed emergency access for agents. It 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. HMAC commitments stand in for actor identities. So the chain still verifies after erasure.	Not a stated function. Their scan tells you where the subject's data sits. Deleting it across the estate is your job, still.	◆
Tokenization and de-identification	Deterministic, join-preserving tokens, vault-reversible too, applied at ingest. Plus quasi-identifier generalization. Dates become year, decade, or age band. ZIPs become 3 or 4 digits. Phones, SSNs and emails get partial masking. Each column gets a measured cardinality-reduction score. Detokenization is a gated, logged step.	Three written-down methods. Deterministic encryption with AES-SIV. FPE-FFX. HMAC-SHA-256 hashing. The first two reverse, in fact. 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. No rows leave it, ever. We label columns against 129 field classes. That covers PII, PHI, financial data and secrets. The catalog carries a business glossary. Plus typed lineage and stewardship queues. That's PostgreSQL today, not your whole estate. SaaS apps, cloud stores and endpoints aren't ours. We've named other database vendors on our roadmap. We haven't built them yet.	Constant data profiling. Across BigQuery, Cloud SQL, Cloud Storage. Plus Vertex AI tuning jobs. Amazon S3 and Azure Blob Storage too. Plus 200+ predefined detectors.	◇
Re-identification risk analysis	We generalize quasi-identifiers. Dates become year, decade, or age band. ZIPs become 3 or 4 digits. Phones, SSNs and emails get partial masking. We report a cardinality-reduction score per column. There's no k-anonymity or l-diversity math here, though. 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 carry scope ceilings. Per-call metering ties back to the agent.	No MCP surface in the docs, none found. Content policies integrate with Gemini Enterprise. New infoTypes detect Anthropic, Gemini and OpenAI API keys.	◆
Deployment	Self-hosted, in your own cloud or data center, your call. Or on a dedicated single-tenant server we run. Your keys, always.	A Google Cloud API. Hybrid jobs and content methods accept data from anywhere. But the service and the keys stay put. In Google Cloud, always.	◆
Maturity signals	Auth, Guardian and Lighthouse are live in production. Guardian and Lighthouse since April 2026. SOC 2 isn't certified yet. We say so, plainly.	Shipping since 2018, as Cloud DLP. Inside Google Cloud's compliance reach. A release note most weeks, too.	◇
Pricing	Published model, scoped instant quote, no sales wall.	Fully posted per-GB rates. Scanning runs $0.03/GB. Storage jobs run $1.00/GiB. Content methods run $3.00/GiB inspected. Google's own page warns costs can climb fast.	◈

◆ DataShield leads◇ Google Cloud DLP leads◈ comparable

Google Cloud claims come from cloud.google.com. From its product, pricing and release-notes pages. We checked them on 13 September 2026. We link them below, not just a 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 isn't a tamper-evident log. Ours is a hash chain with signed checkpoints. The verifier tells you what went wrong. Not just that it did. EU AI Act Article 12 reviewers care about that. So does HIPAA §164.312(b). 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 checked tool call gets re-checked. Against current access, each time. It fails closed. An IAM change is eventually consistent. The in-flight call rarely notices. How Auth does it.

One control plane across clouds

Sensitive Data Protection reaches S3 and Azure Blob to scan. That's more than people expect. But the rule stays put. The tokens stay put, too. So does the proof. All 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 shipped this since 2018. It shows. The detector library is huge. Still growing, too. Source-code types. Document context types. Image objects, like passports and licence plates. In August 2026 they added new detectors. For Anthropic, Gemini and OpenAI API keys. Discovery scans your whole org, on a schedule. This covers Vertex AI tuning jobs, since February 2026. Risk analysis gives you k-anonymity, l-diversity, and k-map estimation. You just pay for the BigQuery compute. Their de-identification reverses. It keeps referential integrity, too. It covers FPE-FFX, which we don't have. The rates are public, per GB. There's a free first gibibyte. We score pricing a tie, and mean it.

Here is the push-back, though. All of that runs 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 just an IAM-gated API call. The real question is elsewhere. What evidence exists six months later? Was the agent making it allowed to? Did nobody trim the record? Google's August 2026 content policies return ALLOW or BLOCK. Based on how risky the content looks. That's a handy control, sure. It isn't the same as an access tier, though. One attached to an agent whose access you revoked at 4pm. Gartner has a telling number. Most unauthorized agent transactions through 2028 will be internal policy violations. Not attacks. Finding the PII doesn't 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 each vendor call, including ours.

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

DataShield: yes, it can. Each record commits to the one before it. We sign and chain the checkpoints. It tells deletion from truncation from tampering. Run it against a sample chain at /verify. Google: DLP events flow into Cloud Audit Logs. You can retain and export them. We found no posted tamper-evidence check, though. Not for the log itself. Ask them how you'd spot a removed entry.

What happens to a revoked agent mid-session?

DataShield re-checks access on each tool call. Revocation bites on the next call, right away. With Google, you're relying on IAM instead. Ask how long a running job keeps its DLP permissions. After you remove the role, that is. And whether the in-flight call fails or completes.

How does GDPR erasure interact with the audit trail?

DataShield crypto-shreds the subject's key material. Then it issues an ISO 27560 consent receipt. HMAC commitments stand in for actor identities in the chain. So the proof still checks out after the subject is gone. Sensitive Data Protection has no erasure function. It shows you where the data is. You delete it yourself. That's a fair split 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 scan and detectors are cheap and good. We are not a scanning tool. We become the choice when the estate spans clouds. Or when the setup must be self-hosted. Or when the job is proving an agent's actions. Not finding the data. Run their scan. Tokenize at ingest here. 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, though. Their content methods de-identify what you pass them. Per request. Statelessly, each time. We tokenize the dataset once, at ingest. So the agent's MCP queries never see a raw value. Reversing one is a gated step. It ties to that agent's current access. It leaves an audit record you can verify later.

Does DataShield have SOC 2?

Not yet. We won't imply otherwise, ever. Google Cloud's compliance reach is far larger than ours. That's fair to weigh. Auth is live now. It ships with a public threat model. Plus a verifier anyone can run. Guardian and Lighthouse have run since April 2026. Design-partner terms include source escrow. That way a small vendor isn't a single point of failure. Details on the security page.

Google's positioning: "Discover and protect your sensitive data." Plus "200+ predefined detectors." Plus 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. No Sensitive Data Protection surcharge applies. - Sensitive Data Protection pricing, 13 Sep 2026
Deterministic encryption (AES-SIV) and FPE-FFX are reversible. Both keep referential integrity. HMAC-SHA-256 hashing is not reversible. - Google pseudonymization docs, 13 Sep 2026
Content policies reached General Availability on 31 August 2026. They return an ALLOW or BLOCK verdict. They integrate with Gemini Enterprise, too. 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 →