Head-to-head · updated 13 September 2026

DataShield vs AI gateways: which layer does the obligation land in?

An AI gateway is probably already in your stack. It should be. Kong, LiteLLM, Portkey (now Prisma AIRS) and TrueFoundry handle model routing, failover, rate limits, spend caps, and inline redaction. As of this year, MCP registries too. We don't do any of that. We're not trying to.

The gateway checks the pipe. DataShield checks the data. We tokenize datasets at ingest. Agents query tokens over MCP, not raw values. Turning a token back into real data is a privileged, audited step. We check each checked tool call against the agent's current access. We seal each call into a hash chain. An auditor can check it without our help. This is a complement page. Most of our design talks assume a gateway is already there. It's about which duties land in the pipe, and which land in the data.

DataShield vs AI gateways at a glanceEight questions regulated buyers ask us. Scored from the gateways' own documentation. DataShield vs AI gateways at a glance Eight questions regulated buyers ask us. Scored from the gateways' own documentation. DataShield AI gateways Tamper-evident audit chain you can verify Sensitive values removed from the dataset itself Authority re-checked on every tool call GDPR erasure that keeps the chain valid Break-glass access for agents Inline blocking and prompt redaction Model routing, failover, spend caps MCP tool control shipped partial / roadmap not offered Sources at the bottom of this page.

The short version

Pick DataShield when

  • The risk you're carrying is the raw PII sitting in your datasets, before any prompt is written. A proxy can only redact what flows past it. We remove the value from the dataset itself.
  • Someone will eventually ask you to prove an agent's access log wasn't edited. Gateway audit logs are rows in Postgres or ClickHouse. An admin can update them. Ours is a hash chain, with signed, chained checkpoints. Run the verifier.
  • You need to pull an agent's access mid-session. You want the very next checked tool call to fail closed. No waiting on a token refresh.
  • You have a GDPR Article 17 erasure to answer. The subject's values sit scattered through logs, traces, and caches. Crypto-shred gives you an answer that keeps the audit chain valid.

Pick an AI gateway when

  • You need inline blocking. If a request has to stop in flight, that's a proxy's job. We don't have an inline product. Kong's AI PII Sanitizer and Prisma AIRS both do this. We don't.
  • Model routing and cost control are the problem: failover, token-aware rate limits, spend caps, semantic caching. LiteLLM reports 140+ providers and a Rust gateway at 0.66ms p99 overhead. We offer none of this.
  • You want to start in an afternoon. LiteLLM's OSS tier is free forever, and installs with pip. TrueFoundry starts free. We're a data-platform deployment.
  • Your estate already runs on Kong or Palo Alto. The path of least resistance is the incumbent's MCP registry.

Bottom line: run both. A gateway in front of raw PII is a filter. A gateway in front of tokenized data is defense in depth. Only one of those two things survives a detector miss.

Feature by feature

Competitor cells describe what Kong, LiteLLM, Portkey/Prisma AIRS and TrueFoundry's public sites and docs say. We use the date above. If we got something wrong, email support@myorg.ai. We'll fix it and credit you.

What mattersDataShieldAI gatewaysEdge
Point of controlThe data layer and the MCP tool boundary. We tokenize datasets at ingest. Protection travels with the data, not the route.An inline proxy, on traffic between apps or agents and model providers. Control starts where the request passes through.n/a
Data at restTokenized and generalized datasets, with masking-by-default SQL views. Deterministic, join-preserving, vault-reversible tokens. Plus quasi-identifier generalization: dates become year, decade or age band; ZIPs become 3 or 4 digits; we mask phones, SSNs and emails in part. Each quasi-identifier column gets a cardinality-reduction score.Not addressed. Raw PII stays in every source dataset. The gateway sees it only if it gets routed there.◆
Missed detectionA detector miss has nothing to reveal. The sensitive value isn't in the queryable dataset to begin with.A miss means the value reaches the model, the traces, and the gateway's own logs and caches. Redaction fails open.◆
Inline blocking and redactionNo inline SKU. Traffic that never touches our MCP surface isn't checked by us. We do not proxy your LLM traffic, but we do gate each value that leaves a checked dataset for a prompt. We redact a PII or PHI column with no set rule. A PHI dataset refuses any AI endpoint not marked BAA or ZDR approved. That's a gate on our own data path, not an inline product.Core strength. Kong's AI PII Sanitizer covers 20 categories across 9 languages, with placeholder or synthetic swaps. Prisma AIRS adds threat guardrails. LiteLLM wires up external Presidio containers.◇
Audit evidenceSHA-256 hash chain with Ed25519-signed checkpoints. We chain the checkpoints too. A check tells apart tampering, insertion, deletion, and a cut-off tail. Try the verifier.Request logging and watch dashboards. We found no posted crypto proof against tampering from any gateway in this field.◆
Agent authorizationEach checked tool call passes a scope ceiling. Plus a set access tier, and a re-check that access wasn't pulled, before it runs. Then we meter it and seal it into the chain.Route and tool allowlists, virtual keys, team budgets. TrueFoundry is furthest along, with tool-level RBAC and Cedar policies. LiteLLM has MCP guardrails but no central tool ACL.◆
Break-glassScoped, time-boxed emergency access for agents. It auto-revokes. No one can quietly delete it from the log.Not offered by any gateway we looked at.◆
GDPR erasureCrypto-shred of per-subject key material, plus ISO 27560 consent receipts. We HMAC-commit actor identities. The chain still checks out once the subject is gone.Redaction is one-way. No erasure story is posted for values the detector missed and then logged. Enkrypt's gateway even auto-unredacts responses inline, which round-trips cleartext.◆
MCP and agentsNative MCP endpoints on Auth, Ontology, and Lighthouse. Auth issues MCP tool tokens with scope ceilings. Per-call metering is tied to the agent.Now table stakes across the field. Kong shipped an MCP Registry inside Konnect. LiteLLM routes MCP servers through the same gateway. TrueFoundry ships a purpose-built MCP gateway.◈
Model routing and costNot offered. This is the gateway's job, and we say so on sales calls.Strength. Failover, semantic caching, spend caps, per-team budgets. LiteLLM publishes 140+ providers and 0.66ms p99 overhead on its Rust gateway.◇
DeploymentSelf-hosted, in your own cloud or data center. Or on a dedicated single-tenant server we run. Your keys.Varies. LiteLLM self-hosts via pip, Docker, or Kubernetes. Kong offers Konnect SaaS, plus self-hosted and hybrid. TrueFoundry covers on-prem, VPC, hybrid and cloud. Prisma AIRS is SaaS, under Palo Alto.◈
Maturity signalsAuth, Guardian and Lighthouse are live in production. Guardian and Lighthouse have run since April 2026. SOC 2 isn't certified yet, and we say so plainly.Much older and much larger. Kong is an API incumbent. LiteLLM reports 240M+ Docker pulls and 53K+ GitHub stars. Portkey now sits inside Palo Alto Networks.◇
PricingPublished model, scoped instant quote, no sales wall.Partly posted. LiteLLM has a free forever OSS tier, with Enterprise quote-only. TrueFoundry starts free, with Pro from $499/month. Kong's AI Gateway page routes to a request-pricing form. A legacy figure of around $34.25 per million requests could not be re-confirmed for 2026. Prisma AIRS is quote-only after the rebrand.◈

◆ DataShield leads◇ AI gateways leads◈ comparable

We draw gateway claims from konghq.com, litellm.ai, portkey.ai and truefoundry.com. Last checked 13 September 2026. Kong's per-request figure is a legacy number we couldn't confirm this year. Treat it as an order of magnitude, and put the question to them.

Three things you get here that you won't get from a gateway

Protection that exists before the proxy does

A gateway can only act on traffic it sees. Tokenization happens at ingest. The sensitive value is gone from the dataset, whether a request ever routes through anything. Deterministic tokens still join, so your analytics survive. How the data layer works.

Logs that are evidence, not just records

Gateway audit logs are application rows in Postgres or ClickHouse. An admin with write access can change them. Under EU AI Act Article 12, that's worth roughly nothing. Ours is a hash chain with signed checkpoints. The verifier tells you what went wrong, not just that something did. Run it in a browser tab.

The virtual key that outlives the analyst

Someone's access is pulled at 16:00. Their agent is halfway through a long batch. The gateway keeps routing, because the virtual key is still valid. Here, we re-check the next checked tool call against current access. It fails closed. How Auth does it.

Where AI gateways are genuinely stronger

Almost everything about the request path. Routing across providers. Failover when one goes down. Semantic caching, token-aware rate limits, spend caps per team. And the power to actually stop a request in flight. Kong's sanitizer handles 20 PII categories in 9 languages. LiteLLM's numbers are real, and its OSS tier costs nothing. TrueFoundry runs on-prem, and now ships tool-level RBAC with Cedar policies, which is closer to our turf than anything else in the field. Every one of these products is older, bigger, and easier to install than we are. The whole field went MCP-native inside twelve months. If you have no gateway, get one before you call us.

So where's the argument? Redaction at the proxy is late and lossy. It sees only routed traffic. It catches only what the detector knows to look for. The placeholders it leaves behind don't join or add up. It's also one-way. There's no path back for a fair use, and no erasure story for the values that got logged. And none of it touches the raw PII already sitting in your warehouse. Through 2028, Gartner expects most bad agent actions to be policy breaks from inside, not attacks. That's a governance problem wearing a filtering problem's clothes. A filter can't tell you whether the agent was allowed to make the call. A log you can edit can't prove what it did.

Questions worth asking both of us

Ask your gateway vendor these. Then ask us the same ones.

What stops an agent from bypassing DataShield entirely?

Nothing, and we won't pretend otherwise. We are not an inline proxy. We don't intercept prompt traffic. The answer is that bypassing us doesn't buy the caller much. We tokenize datasets at ingest, so an agent that skips every check still finds tokens, not raw values. Reaching a checked tool still needs a valid MCP tool token, issued by Auth with a scope ceiling attached. The protection lives in the data, not in the pipe. If you need traffic stopped in flight, that's what the gateway is for. We assume you have one.

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

DataShield: yes. Rows commit forward. We sign and chain checkpoints to each other, so a missing checkpoint surfaces too. A check reports which failure it found. The chain at /verify is live. Try to fool it. Gateways: we found request logging and watch dashboards across Kong, LiteLLM, Portkey/Prisma AIRS and TrueFoundry. But no posted tamper-proof mechanism. Ask any of them to check a chain live.

What happens to a revoked agent mid-session?

We check current access on each checked tool call. The call right after a pull fails, not the call after the next token refresh. Gateway virtual keys and budgets get checked at the proxy. We found no write-up of a mid-session access downgrade in any of their public docs. Ask for the number: after you pull access, how many more calls can that key make?

How does GDPR erasure interact with the audit trail?

We crypto-shred the subject's key material and issue an ISO 27560 receipt. We delete nothing from the chain, and it still checks out, because actor identities in it are HMAC commitments. On the gateway side, ask the harder version of the question. A subject's values were missed by the detector six months ago. Now they sit in request logs, traces, and the semantic cache. What's the deletion step? What does it do to the logs you rely on for audit?

Do we have to choose between you?

No, and most of the teams we talk to don't. The gateway checks the pipe. We check the data. Running LiteLLM or Kong in front of tokenized datasets beats running it in front of raw ones, hands down, because a detector miss stops being an incident. The only time this turns into a real either-or is when a buyer believes gateway redaction is their whole compliance program. It isn't. But that's an argument about scope, not about products.

Does DataShield have SOC 2?

No. Auth ships live, with a posted threat model and a verifier anyone can run. Guardian and Lighthouse have run in production since April 2026. Design-partner terms include source escrow. And because the stack self-hosts, our uptime isn't your uptime. Security page.

Other head-to-heads

Partial overlap

DataShield vs MintMCP

An MCP-only gateway with SSO and allowlists. Against tokenized data and a verifiable chain.

Complement

DataShield vs Lakera

Prompt-layer defence and data-layer governance solve different halves.

Direct

DataShield vs Skyflow

A privacy vault with an inline gateway, versus agent authorization and evidence.

All

Every comparison

Eleven vendors, one honest scorecard each.

Keep your gateway. Then see what sits underneath it. Break a live audit chain. Revoke an agent mid-session. Query a tokenized dataset. Demo Center access is free with a work email.

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 →