Head-to-head · updated 13 September 2026

DataShield vs Obot: the gateway governs the pipe, but who governs the data?

Obot is, in fact, a good MCP gateway. It's MIT licensed, so you can read each line before you trust it. The Rancher Labs founders know how platform teams work. You get just one governed front door. It reaches each MCP server a person can use. You get sandboxed execution on Kubernetes too. You get central credentials and a curated registry. Obot Sentry hunts down shadow agents already running on your engineers' laptops. We like it a lot. We'd install it ourselves.

We do a different job. A gateway governs the pipe, plain and simple. DataShield governs the data and the record. We tokenize datasets right at ingest. Agents then query tokenized data over MCP. Turning a token back into real data is a privileged, audited step. Each governed decision lands in a hash chain you can verify yourself, without trusting us. Most teams who like Obot should run both. Here's the honest split, including the rows Obot wins.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

You may need to prove an agent's access log wasn't edited. An examiner or EU AI Act Article 12 could ask. Hashing each payload isn't the same as chaining the records. Ours is a chain with signed checkpoints. Run the verifier.
The obligation sits on the data, not just the call. We tokenize datasets at ingest. A leaked result set then holds tokens, not names. How the data layer works.
You need mid-session revocation for agents. You also need a break-glass procedure. Both should survive a hand-off to an auditor.
A right-to-erasure request must not cost you your audit history. Crypto-shred handles both at once.

Pick Obot when

You want an MIT-licensed core you can self-host for free. Read it in full. Fork it if we disappoint you. That's a real answer to lock-in. We don't match it.
The problem today is MCP sprawl. Dozens of servers, scattered OAuth grants, no single front door. Obot hosts them sandboxed in Docker or Kubernetes. It adds egress rules and one endpoint.
Shadow AI discovery matters. Obot Sentry enrolls workstations and inventories devices. It captures local tool calls from Claude Code, Cursor, Codex and VS Code. We don't do endpoints at all.
Your team already lives in Kubernetes and Helm. You want your LLM proxy, token spend, and model access policies in one console.

Bottom line: Obot is the better way to connect and sandbox your MCP estate. DataShield is the layer that survives the audit, the erasure request, and the contractor who left on Friday. They're not the same purchase. For most regulated teams, the honest answer is both.

Feature by feature

Competitor cells describe what Obot's public site, docs, and release notes say. We use the date above. If we got something wrong, email support@myorg.ai. We'll fix it and credit you.

What matters	DataShield	Obot	Edge
Audit evidence	SHA-256 hash chain with Ed25519-signed checkpoints. The checkpoints are themselves chained. Verification names the failure: tampering, insertion, deletion, or truncation. Try the verifier.	Correlated audit logs across MCP, LLM gateway, and Sentry. Obot encrypts bodies at rest. Only an Auditor role can decrypt them. Their own schema post hashes each call's arguments and content with SHA-256. That proves a body matches its row. Records aren't chained to each other. A removed row leaves no gap.	◆
Log retention	The chain is yours. It sits in your own database, for as long as you keep it. We handle erasure with crypto-shred, not deletion.	Default retention is 90 days. For longer, you export JSONL to S3, GCS, or Azure, one-time or scheduled. Their own guidance says keep tool events at least 90 days. Under HIPAA or PCI-DSS, keep them longer.	◆
Agent authorization	Each governed tool call passes a scope ceiling. It also carries a declared authority tier. It gets a revocation re-check before dispatch. This ships in Auth, live in production.	Server and tool access go by user or IdP group. Model access policies and agent auth scopes run on API keys, bounded by the owner's permissions. Tool-call enforcement arrived in v0.25.0 as a Sentry pre-tool hook. It fails closed. They label it experimental, not for live use.	◆
Mid-session revocation	Authority is re-read on the next governed tool call. A revoked agent stops there. It doesn't ride its token to expiry.	API key scopes carry expiry dates. We found no description of what happens to an open session when you revoke it. That's worth asking on the call.	◆
Break-glass	Scoped, time-boxed emergency access, just for agents. It auto-revokes and can't be quietly removed from the log.	Nothing in their own public docs describes a break-glass path.	◆
GDPR erasure	Crypto-shred of per-subject key material, plus ISO 27560 consent receipts. Actor identities are HMAC commitments. The chain still checks out, even after a subject is erased.	Not addressed in public, at all. Exported JSONL in three clouds makes the question harder, not easier.	◆
Data handling	We tokenize datasets at ingest. The tokens are deterministic, join-preserving, and vault-reversible. We also generalize quasi-identifiers. 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 privileged, logged step.	Request filtering and central credential custody. Obot encrypts payloads in the log. We found no PII or PHI classification. We found no tokenization or masking of values in transit.	◆
MCP hosting and registry	Native MCP endpoints on Auth, Ontology, and Lighthouse. We govern the servers you run. We host nothing for you and have no catalog.	Sandboxed MCP servers run in Docker or Kubernetes, with domain egress rules. Composite servers too. Git-backed MCP and Skills registries. MCP Tunnels reach private networks over an outbound WebSocket.	◇
Shadow AI discovery	None. We govern what's registered, not what's hiding.	Sentry device enrollment, plus CLI scans. These find agents, MCP servers, and Skills through config files, network logs, and OAuth tokens. Most of this market only talks about this. Obot ships it.	◇
Open source	Not open source, no. Design-partner terms include source escrow. That way, a small vendor is never a single point of failure.	MIT licence on the whole core: roughly 1,000 GitHub stars, 212 forks. Audit it. Fork it. Run it free for up to 100 users on the Community tier.	◇
Deployment	Self-hosted or dedicated single-tenant. Your keys, your credentials, your evidence.	Docker for evaluation, Kubernetes for production, external Postgres, cloud KMS encryption, or hosted Obot Cloud. It's easy to run, day to day.	◈
Maturity signals	Auth, Guardian and Lighthouse are live. Guardian and Lighthouse have run since April 2026. SOC 2 isn't certified yet, and we say so. We have design partners, not marquee logos.	Founded 2025. $35M seed co-led by Mayfield and Nexus. Built by Rancher Labs alumni, shipping fast at v0.25.0. We found no SOC 2, ISO, or HIPAA claim on their site, docs, or repo.	◈
Pricing	Published model, scoped instant quote, no sales wall.	Community is free to self-host up to 100 users or devices. Cloud is free to try. Enterprise is quote-only with no public figures. Hard to beat free as an entry point.	◇

◆ DataShield leads◇ Obot leads◈ comparable

Obot claims come from obot.ai, docs.obot.ai, and the obot-platform/obot repository. They also come from the v0.24.0 and v0.25.0 release posts. Last checked 13 September 2026. Links are below, not a paraphrase from memory.

Three things you get here that you won't get from an MCP gateway

A chain, not just a hash

Obot's own audit schema post is sharper than most vendors on this. It still stops one step short. Hashing a call's arguments and content proves a body matches its row. It says nothing about whether the row is still there. Our records commit forward to each other. Checkpoints are Ed25519-signed and themselves chained. The verifier names the failure: deletion, truncation, insertion or tampering. Run it in your browser, no signup.

Data that's already safe to query

A pipe can log a call and still hand over a full name. We tokenize datasets at ingest instead. The tokens are deterministic, join-preserving, and vault-reversible. We also generalize quasi-identifiers. 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. The agent gets a dataset it can join and aggregate. The raw value was never in the queryable surface. Turning a token back into real data is a privileged, audited step. How the ontology layer does it.

An answer for the awkward Friday

A contractor's access ends at five. Their agent is halfway through a batch run. We re-read authority on the next governed tool call. It fails closed instead of running to token expiry. Someone may genuinely need emergency access at 2am. Break-glass covers that: scoped, time-boxed, and auto-revoking. It's written into the chain, where nobody can quietly erase it. How Auth handles both.

Where Obot is genuinely stronger

Say your estate is forty MCP servers running on laptops, with forty sets of OAuth tokens. Obot fixes that faster and cheaper than we do. The whole core is MIT licensed. Your security team can read it instead of taking a datasheet's word. Sandboxed execution with domain egress rules is the right default. MCP Tunnels solve private-network reach without opening a single inbound port. That's the kind of detail you only get from people who have run real systems before. Sentry hunts shadow agents on developer machines. That's the most useful thing in this category right now. We don't have anything like it. Their engineering pace is high: two big releases in six weeks.

The push-back is about what a gateway can reach. It governs traffic that routes through it, and nothing else. That's a real gap. Some things stay invisible. The batch job with its own database credential is one. So is the notebook on a data scientist's machine. So is the server Sentry hasn't enrolled yet. All of them still touch the same records. Tokenizing at ingest keeps the data safe no matter which path finds it. The other gap is proof. Ninety days of retention by default, then JSONL files in a bucket: that's a fair answer. It's a weak one for an examiner asking about March. Anyone with write access can edit files in object storage. Nothing in the format stops them.

Questions worth asking both of us

These are the questions we'd put to a vendor in our seat. Put them to us too.

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

DataShield: yes. Rows commit forward. We sign and chain checkpoints, so removing one is detectable too. Key rotation fails closed. A failed verification tells you what kind of failure it found. Try it on the sample chain at /verify. Obot: their schema includes SHA-256 hashes of each call's arguments and content. That's good hygiene. It proves a payload matches its record. We found no claim of record-to-record chaining or signed checkpoints. Ask them this: how would they tell a deleted row from one that was never written?

What happens to a revoked agent mid-session?

Each governed tool call re-reads the agent's current authority before dispatch. The call after a revocation fails closed. Obot issues agent auth scopes on API keys with expiry dates. The owning user's permissions bound these. That's sensible design. We couldn't find a description of mid-session behavior in their docs. Ask it as an authority question, not a credentials one. After you revoke access, ask this: does the very next tool call in an open session get re-authorized? Or does the session just ride?

How does GDPR erasure interact with the audit trail?

We crypto-shred the per-subject key material and issue an ISO 27560 receipt. We don't touch any log row. None needs it. Actor identities in the chain are HMAC commitments, not names. Obot's public docs don't cover erasure. Scheduled JSONL exports go to S3, GCS, or Azure. Copies of the trail then live in more places. A deletion request now has to reach them too. Ask what their runbook is.

Isn't an open-source gateway enough governance on its own?

For the pipe, often yes, and fair enough. The license is a real advantage. The limit is coverage. A gateway governs what routes through it. Some things sit outside the policy and the log. One is a direct credential. Another is a batch job outside the proxy. A third is a laptop-local server Sentry hasn't enrolled. Sentry is the most serious attempt we've seen at closing the laptop half of that gap. It still doesn't change what the data is. We tokenize at ingest, always. What an agent can reach is already safe, no matter which route it took.

Can we run Obot for connectivity and DataShield for evidence?

Yes, and that's the setup we'd pick. Obot fronts the whole MCP estate. It sandboxes servers, holds provider credentials, and finds shadow agents. DataShield holds the tokenized datasets. It issues MCP tool tokens with scope ceilings. It re-checks authority per call. It seals decisions into a chain. Both run in your own system, side by side. Plan for one seam: identity. Federate through your IdP once. Keep a single notion of who the agent acts for. How Auth fits.

Does DataShield have SOC 2?

No, and we won't imply otherwise. Neither does Obot, as far as we can tell. We checked their site, docs, and repo. On paper, we're level. Procurement shouldn't wave either of us through on trust. Our counter-offer is checkable, not just attested. Auth is live with a public threat model. You can run a verifier today. Guardian and Lighthouse have been live since April 2026. We offer source escrow for design partners. It all runs in your own system. Security page.

Obot's current hero: "Control Every AI Agent. Trust Every Outcome." with "Open Source & Enterprise-Ready." Primary CTA is "Try Obot for Free." - obot.ai, 13 Sep 2026
MIT-licensed core, roughly 1,000 stars and 212 forks. Sandboxed MCP servers in Docker or Kubernetes. Git-backed registries. Obot Sentry in beta. - github.com/obot-platform/obot, 13 Sep 2026
Audit logs default to 90-day retention. Exports go to S3, GCS, or Azure, one-time or scheduled. Obot encrypts bodies at rest. Only an Auditor role can decrypt them. No tamper-proof mechanism described. - Obot Platform v0.24.0 release post, 24 Jul 2026
Tool-call enforcement ships as a Sentry pre-tool hook that fails closed. It's labelled experimental and not recommended for live use. Agent auth scopes are API keys with expiry, bounded by the owner's permissions. - Obot Platform v0.25.0 release post, 2 Aug 2026
Obot's recommended audit schema hashes each call's arguments and content with SHA-256. It advises keeping tool events at least 90 days, longer under HIPAA or PCI-DSS. - Obot blog, 1 Sep 2026
$35M seed co-led by Mayfield Fund and Nexus Venture Partners to build an enterprise MCP gateway. - PR Newswire, 23 Sep 2025
≥80% of unauthorized agent transactions through 2028 will be internal policy violations rather than attacks. - Gartner, 2026

Other head-to-heads

Direct

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 →