Head-to-head · updated 13 September 2026

DataShield vs Amazon Verified Permissions: same policy language, different job

Let's start with the awkward part: we like Cedar. We use it. AWS designed the language, open-sourced it, and still ships releases at a pace most policy engines can't match. Amazon Verified Permissions is the managed version, and if you need externalized authorization for an API behind API Gateway, it is a good, cheap, well-built answer. Their hero says it plainly: "Fully managed Cedar authorization service for fine grained authorization."

So this page isn't a fight about policy syntax. It's about scope. Verified Permissions answers one question, allow or deny, and hands the answer back. It doesn't issue the agent's token, hold the database credential, keep evidence you can verify, or know what to do when a subject asks to be erased. DataShield is the control plane around that decision. Below is the honest split, including the rows AWS wins.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

The thing you have to produce is evidence, not a decision. Our audit is a hash chain with signed, chained checkpoints, and the verifier names the failure: tampering, insertion, deletion, or truncation. Run it yourself.
Your agents need more than a verdict. They need a token with a scope ceiling, a credential pulled from a vault, and a per-call authority re-check that catches a revocation mid-session. How Auth does it.
The estate isn't only AWS. A policy store bound to API Gateway and AppSync doesn't help the agent running on a laptop, in Azure, or on a box in your own rack.
Someone will eventually ask for erasure and someone else will ask for the March logs. Crypto-shred answers both without breaking the chain. See the architecture.

Pick Verified Permissions when

You're building application and API authorization on AWS. It drops in beside Cognito, API Gateway and AppSync with almost no plumbing, and AWS operates it for you.
You want to prove things about your policies, not just test them. Cedar's symbolic analysis tooling is backed by an SMT solver and it is genuinely ahead of the field, ours included.
Per-request pricing suits you: $0.000005 for a single authorization call, no minimum, no upfront fee. At low volume that is close to free.
You want the language from the people who wrote it, on an AWS SLA, with AWS's compliance programme behind it. That is a reasonable thing to want.

Bottom line: Verified Permissions is a policy decision point. We ship one too, and we'd rather talk about everything else: tokens, vaulted credentials, verifiable evidence, erasure, break-glass. Plenty of teams keep AVP for their app APIs and add us for the agent and data seam. That's a sensible outcome.

Feature by feature

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

What matters	DataShield	Amazon Verified Permissions	Edge
Policy language	Cedar, with policy_explain surfaced to the user who got denied, and entitlement expansion. Cedar governs admin, config and token decisions.	Cedar, from the team that created it. Schema validation, AuthZEN support, active 4.x release cadence.	◈
Policy analysis	Tests and a change-governance flow: propose, approve, roll back, with security floors that can't be edited away.	Symbolic analysis backed by an SMT solver. You can prove a policy set never grants a given access. Real research, shipped.	◇
Audit evidence	SHA-256 row chain with Ed25519-signed checkpoints that are themselves chained. Verification distinguishes tampering, insertion, deletion and truncation. Public verifier.	Decision logging through ordinary AWS logging. We found no published cryptographic tamper evidence for the decision log.	◆
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.	You call IsAuthorized from your own code. Where that call sits, and whether it happens on every tool call, is your design problem. AWS's own Bedrock Agents pattern puts it in the Lambda behind the action group.	◆
Agent tokens and identity	SAML, OIDC, passkeys, RFC 9068 JWTs, MCP tool tokens with scope ceilings, JWKS rotation.	Not in scope. It evaluates identities minted elsewhere, usually Cognito. AWS's guidance is to customize a Cognito token so the agent carries user context.	◆
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 write an emergency Cedar policy and remember to remove it.	◆
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.	Out of scope. It holds policies, not subject data, so erasure lands on whatever system does hold it.	◆
Data handling	Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. 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.	None. It never touches your data, by design. That's a clean boundary, not a flaw.	◆
Credential handling	Connection Vault holds encrypted per-subject credentials with eight strategies, including Snowflake keypair JWT.	Not in scope. Secrets Manager is the AWS answer, bought and wired separately.	◆
MCP and agents	Native MCP endpoints on Auth, Ontology and Lighthouse, with per-call metering attributed to the agent.	The product page doesn't mention AI agents or MCP as of 13 September 2026. Agent material lives in the AWS Security Blog and in Bedrock AgentCore, which is a separate product.	◆
Deployment	Self-hosted in your own cloud or data center, or on a dedicated single-tenant server we operate. Your keys. No cloud dependency.	AWS-managed only. Cedar the language is open source and portable; the service is not.	◆
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.	AWS. Launched 2023, named customers including TELUS, Twilio, Stedi and FIS, AWS SLA and compliance programme. We aren't going to pretend this is close.	◇
Pricing	Published model, scoped instant quote, no sales wall.	Published to the fifth decimal: $0.000005 per single authorization request, tiered batch pricing, no minimums. Different shape, same honesty.	◈

◆ DataShield leads◇ Amazon Verified Permissions leads◈ comparable

AWS claims are drawn from aws.amazon.com/verified-permissions, its pricing page, the AWS Security Blog and the public Cedar repository, 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 policy decision point

A log an examiner can't wave away

A decision log that can be edited proves nothing. 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.

The re-check AWS leaves to you

An allow decision is a fact about one moment. An analyst resigns at 16:00 while their agent is 20 minutes into a job. We re-read authority on every governed tool call, so the next one fails closed. With a decision API, that behaviour exists only if your engineers built it and kept building it. How Auth does it.

Data the model never sees in the clear

Cedar can say no. It can't hand the agent a reversible pseudonym instead. We tokenize datasets at ingest, agents query the tokenized data over MCP, and detokenization is a privileged, audited operation. The EDPB names pseudonymization as a mitigation for exactly this. See the data layer.

Where Amazon Verified Permissions is genuinely stronger

Cedar is a good language and AWS made it, then gave it away. Releases keep landing: 4.12.0 shipped on 28 July 2026, part of a steady run through the year. The symbolic analysis tooling is the part I'd single out. It compiles a policy set to logic and hands it to an SMT solver, so you can prove that no policy in your store ever grants a given access. That is a stronger claim than any test suite makes, ours included, and I don't know of another vendor in this market shipping it. Add AWS operations, the SLA, the compliance programme, per-request pricing published to five decimal places, and drop-in hooks for API Gateway, AppSync and Cognito. If your problem is externalized authorization for an AWS application, buy it. We'd say the same on a call.

The push-back is about the size of the box. Verified Permissions returns a verdict and stops, which is exactly right for an API and thin for an agent. AWS's own pattern for Bedrock Agents places the check inside the Lambda behind the action group, which means the enforcement point is a line of your code that a future refactor can quietly move. The service doesn't mint the agent's token, hold the credential it uses, or keep evidence you could hand a regulator, and as of 13 September 2026 the product page doesn't mention agents at all. Through 2028 Gartner expects most unauthorized agent transactions to be internal policy violations rather than attacks. In a policy violation, nobody disputes the verdict. They dispute the log.

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 so a missing checkpoint shows up, and verification separates deletion from truncation from tampering. Run it at /verify. Verified Permissions: decision logs flow into normal AWS logging, and we found no published tamper-evidence mechanism for them. Ask AWS what stops an administrator editing the record, and who would notice.

Does DataShield run Cedar on every tool call?

No, and we'd rather you hear that from us than find out in a demo. Cedar decides admin, platform, config and token questions. The per-call path is different: auth gate, then the token's scope ceiling, then the declared authority tier, then a mid-session revocation re-check, then metering, then the handler, then a sealed audit record. It's a narrower check on purpose, because it runs on every dispatch. Anyone claiming a full policy evaluation on every tool call should be asked to show you the latency.

What happens to a revoked agent mid-session?

DataShield re-checks authority on every governed tool call, so revocation bites on the next call rather than at token expiry. Verified Permissions evaluates whatever you send it, when you send it. If your code checks once at the start of a job, the agent runs on your stale answer until the job ends. That's not a bug in AVP, it's the boundary of a decision API, and it's worth knowing which side of it your design sits on.

We're all-in on AWS. Why not just use Verified Permissions?

For your application APIs, do. We're not going to talk you out of a service that costs $0.000005 a call and sits next to the things you already run. The question is what happens when the caller is an agent: who issued its token, where its Snowflake credential lives, what gets written when it reads a patient record, and what you hand an examiner nine months later. AVP doesn't claim to answer those, which is to its credit. We do, and you can run us inside the same AWS account.

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 keeps verifying after the subject is gone. Verified Permissions stores policies rather than subject data, so the erasure obligation lands on your database, your logs and your token store instead. Worth mapping where it actually falls before someone files the request.

Does DataShield have SOC 2?

Not yet, and we won't imply otherwise. AWS has a compliance programme we can't match and won't pretend to. What we offer instead: Auth is live a public threat model and a verifier anyone can run without talking to us. 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.

Verified Permissions hero, verbatim: "Fully managed Cedar authorization service for fine grained authorization." Named customers include TELUS, Twilio, Stedi and FIS. No mention of AI agents or MCP on the page. — aws.amazon.com/verified-permissions, 13 Sep 2026
$0.000005 per IsAuthorized or IsAuthorizedWithToken request, tiered batch pricing, no minimum and no upfront fee. — AWS pricing page, 13 Sep 2026
Cedar 4.12.0 released 28 July 2026, alongside cedar-policy-symcc 0.6.0, the SMT-backed symbolic analysis tool. — cedar-policy/cedar releases, 28 Jul 2026
AWS's layered authorization pattern for Bedrock Agents puts the Verified Permissions call inside the Lambda behind the agent's action group. — AWS Security Blog, 2 Oct 2024
AWS's agent story lives in Bedrock AgentCore, a separate product whose page cites "access policies verified by automated reasoning" and does not name Cedar or Verified Permissions. — aws.amazon.com/bedrock/agentcore, 13 Sep 2026
≥80% of unauthorized agent transactions through 2028 will be internal policy violations rather than attacks. — Gartner, 2026

Other head-to-heads

Policy engines

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 →