Head-to-head · updated 13 September 2026
DataShield vs Obot: the gateway governs the pipe, but who governs the data?
Obot is a good MCP gateway, and it's MIT licensed, so you can read every line before you trust it. The Rancher Labs founders clearly know how platform teams work. You get one governed front door to every MCP server a person is allowed to reach, sandboxed execution on Kubernetes, central credentials, a curated registry, and Obot Sentry hunting down the shadow agents already running on your engineers' laptops. We like it. We'd install it.
We do a different job. A gateway governs the pipe. DataShield governs the data and the record. Datasets are tokenized at ingest, agents query tokenized data over MCP, detokenization is a privileged, audited operation, and every governed decision lands in a hash chain you can verify without trusting us. Most teams who like Obot should run both. Here's the honest split, including the rows Obot wins.
The short version
Pick DataShield when
- You will have to prove an agent's access log wasn't edited, to an examiner or under EU AI Act Article 12. 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. Datasets are tokenized at ingest, so a leaked result set holds tokens rather than names. How the data layer works.
- You need mid-session revocation and a break-glass procedure for agents that you can hand to an auditor without flinching.
- 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 in full, and fork if we all disappoint you. That's a real answer to lock-in, and 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 with egress rules and one endpoint.
- Shadow AI discovery matters. Obot Sentry enrolls workstations, inventories devices, and 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, and you'd like your LLM proxy, token spend, and model access policies in the same 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, and the honest recommendation for most regulated teams is both.
Feature by feature
Competitor cells describe what Obot's public site, docs, and release notes say as of the date above. If we've mischaracterised something, email support@myorg.ai and we'll correct it, credited.
| What matters | DataShield | Obot | 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. | Correlated audit logs across MCP, LLM gateway, and Sentry. Bodies encrypted at rest, decryptable only by an Auditor role. Their own schema post hashes each call's arguments and content with SHA-256, which proves a body matches its row. Records aren't chained to each other, so a removed row leaves no gap. | ◆ |
| Log retention | The chain is yours, in your database, for as long as you keep it. Erasure is handled by crypto-shred rather than by deletion. | Default retention is 90 days, with one-time or scheduled JSONL export to S3, GCS, or Azure for anything longer. Their own guidance says keep tool events at least 90 days, longer under HIPAA or PCI-DSS. | ◆ |
| Agent authorization | Every governed tool call passes a scope ceiling, a declared authority tier, and a revocation re-check before dispatch. Shipped in Auth, live in production. | Server and tool access by user or IdP group, model access policies, and agent auth scopes on API keys bounded by the owner's permissions. Tool-call enforcement arrived in v0.25.0 as a Sentry pre-tool hook that fails closed, and they label it experimental and not for production. | ◆ |
| Mid-session revocation | Authority is re-read on the next governed tool call. A revoked agent stops there instead of riding its token to expiry. | API key scopes carry expiry dates. We found no description of what happens to an already-open session when you revoke. Worth asking on the call. | ◆ |
| Break-glass | Scoped, time-boxed emergency access for agents. It auto-revokes and can't be quietly removed from the log. | Nothing in their public material describes a break-glass path. | ◆ |
| GDPR erasure | Crypto-shred of per-subject key material plus ISO 27560 consent receipts. Actor identities are HMAC commitments, so the chain still verifies after a subject is erased. | Not addressed publicly. Exported JSONL in three clouds makes the question harder, not easier. | ◆ |
| Data handling | Datasets are tokenized at ingest: deterministic, join-preserving, vault-reversible, with 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. | Request filtering and central credential custody. Payloads are encrypted in the log. We found no PII or PHI classification, no tokenization, and no 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 in Docker or Kubernetes with domain egress rules, composite servers, Git-backed MCP and Skills registries, and MCP Tunnels for 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 that find agents, MCP servers, and Skills through config files, network logs, and OAuth tokens. A concrete capability most of this market only talks about. | ◇ |
| Open source | Not open source. Design-partner terms include source escrow so a small vendor isn't a single point of failure. | MIT licence on the whole core, roughly 1,000 GitHub stars and 212 forks. Audit it, fork it, run it free for up to 100 users on Community. | ◇ |
| 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. Genuinely good operator ergonomics. | ◈ |
| 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. Design partners, no marquee logos. | Founded 2025, $35M seed co-led by Mayfield and Nexus, Rancher Labs founders, shipping fast at v0.25.0. No SOC 2, ISO, or HIPAA claim found 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 published figures. Hard to beat free as an entry point. | ◇ |
◆ DataShield leads◇ Obot leads◈ comparable
Obot claims are drawn from obot.ai, docs.obot.ai, the obot-platform/obot repository, and the v0.24.0 and v0.25.0 release posts, last checked 13 September 2026. Links below rather than 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, and 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, and the verifier names which of deletion, truncation, insertion or tampering it found. 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: deterministic, join-preserving, vault-reversible, with 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 on quasi-identifiers. The agent gets a dataset it can join and aggregate, and the raw value was never in the queryable surface. Detokenization is a privileged, audited operation. 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 reconciliation queue. We re-read authority on the next governed tool call, so it fails closed rather than running to token expiry. And when someone genuinely needs emergency access at 2am, break-glass is scoped, time-boxed, auto-revoking, and written into the chain where nobody can quietly lose it. How Auth handles both.
Where Obot is genuinely stronger
If 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, so your security team can read it rather than take 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, which is the kind of detail you only get from people who have run infrastructure before. Sentry going after shadow agents on developer machines is the most useful thing in this category right now, and we don't have anything like it. Their engineering pace is high: two substantial releases in six weeks.
The push-back is about what a gateway can reach. It governs traffic that routes through it, and nothing else. The batch job with its own database credential, the notebook on a data scientist's machine, the server Sentry hasn't enrolled yet: all invisible, all still touching the same records. Tokenizing at ingest means the data is safe whichever path finds it. The other gap is evidentiary. Ninety days of retention by default, then JSONL files sitting in a bucket, is a reasonable operational answer and a weak one for an examiner asking about March. Files in object storage can be edited by anyone with write access, and nothing in the format objects.
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, checkpoints are signed and chained so removing a checkpoint is detectable too, key rotation fails closed, and 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, which is good hygiene and proves a payload matches its record. We found no claim of record-to-record chaining or signed checkpoints. Ask them how they'd distinguish a deleted row from one that was never written.
What happens to a revoked agent mid-session?
Every governed tool call re-reads the agent's current authority before dispatch, so the call after a revocation fails closed. Obot issues agent auth scopes on API keys with expiry dates, bounded by the owning user's permissions, which is sensible design. We couldn't find a description of mid-session behaviour in their docs. Phrase the question as authority, not credentials: after you revoke, is the very next tool call in an open session re-authorized, or does the session ride?
How does GDPR erasure interact with the audit trail?
We crypto-shred the per-subject key material and issue an ISO 27560 receipt. No log row is touched and none needs to be, because actor identities in the chain are HMAC commitments rather than names. Obot's public material doesn't cover erasure, and scheduled JSONL exports to S3, GCS, or Azure mean copies of the trail live in places a deletion request now has to reach. Ask what their runbook is.
Isn't an open-source gateway enough governance on its own?
For the pipe, often yes, and the licence is a genuine advantage. The limit is coverage. A gateway governs what routes through it. Anything with a direct credential, a batch job outside the proxy, or a laptop-local server that Sentry hasn't enrolled sits outside the policy and outside the log. 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, so what an agent can reach is already safe regardless of the 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 MCP estate, sandboxes servers, holds provider credentials, and finds shadow agents. DataShield holds the tokenized datasets, issues MCP tool tokens with scope ceilings, re-checks authority per call, and seals decisions into a chain. Both run in your own infrastructure. The seam to plan for is identity: federate through your IdP once and keep a single notion of who the agent is acting 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 from their site, docs, and repo. So on paper we're level, and neither of us should be waved through procurement on trust. Our counter-offer is checkable rather than attested: Auth is live with a published threat model, a verifier you can run today, Guardian and Lighthouse in production since April 2026, source escrow for design partners, and everything running in your own infrastructure. 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 with one-time or scheduled JSONL export to S3, GCS, or Azure; bodies encrypted at rest and decryptable only by an Auditor role. No tamper-evidence 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, labelled experimental and not recommended for production; 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, and 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
DataShield vs MintMCP
A hosted MCP gateway with SOC 2, against a tokenized data plane.
LayerDataShield vs Docker MCP Gateway
Container-native plumbing versus authorization and evidence.
LayerDataShield vs AI gateways
Which obligations land in the pipe, and which land in the record.
AllEvery comparison
Every vendor, one honest scorecard each.
See the two mechanisms a gateway can't give you: break a live audit chain and watch the verifier name the failure, then revoke an agent mid-session. Demo Center access is free with a work email.
Get free Demo Center accessYou've seen the proof
Ready for a number? Scope your deployment and we'll price it against your own economics.
Get your quote →