DataShield Auth v2.4.1

Authorization and evidence for AI agents

Break-glass for agents: emergency access that expires itself. It revokes mid-session. No one can quietly delete it from the log.

Auth is per-call MCP authorization. Each call gets checked against a scope ceiling first. Auth also acts as the evidence layer for agents. A Cedar policy engine runs the checks, with policy_explain built in. That covers admin and platform decisions too. Auth issues scope-ceiling MCP tool tokens as well. Every call gets metered and tied to an agent. A hash-chained audit log seals the record. Signed checkpoints lock it down.

Per-call MCP authorization: how every governed tool call is checked

Every checked call runs one pipeline. Token scope ceiling, then declared authority tier. Then mid-session revocation re-check, then metered dispatch, then sealed audit entry. The Cedar policy engine handles admin and platform decisions. It also handles config and token decisions. It ships with policy_explain. You get to see why. Each call went that way for a reason.

The pipeline is not a marketing diagram. The architecture page shows it stage by stage. That's how it sits in code.

See it live in the Demo Center →

Break-glass access for AI agents, delegation, and mid-session token revocation

Break-glass that expires itself

Emergency access starts as a dual-logged event. It runs against a TTL. Then it shuts off on its own. The grant lands in the hash chain. So does each action under it. Try to delete that entry. verify_chain reports a deletion. Nothing gets silently absorbed.

Delegation with scope ceilings

A delegated key never grants more than its owner intends. That holds even for global admins. The dispatch pipeline enforces the ceiling by construction. Not by convention.

Mid-session revocation

Revoke or suspend an agent. Auth catches the change on its very next tool call. The session context drops mid-flight. Asana's 34-day cross-tenant MCP exposure would have been one call.

NHI authorization with metering, evidence, and governed configuration

Per-tool-call metering, tied to the agent

Auth meters each checked call. It ties each one to the agent that made it. Your usage numbers come from that stage. So does your evidence.

Hash-chained audit with signed checkpoints

A SHA-256 row chain, sealed under Ed25519-signed checkpoints. The checkpoints chain too. A check tells tampering, insertion, deletion and truncation apart. Auth builds in GDPR crypto-shred erasure and ISO 27560 consent receipts. Erasure doesn't break the chain. Run the verification yourself.

Config and tenancy, governed

Propose a config change, then approve it. It can never drop below the security floors. Auth stores connection credentials encrypted. It keeps each org apart. Same for each app and instance.

Questions engineers ask us

Does Cedar authorize every tool call?

No, and we won't claim it does. Per-call authorization is the dispatch pipeline. It checks the token scope ceiling, then the authority tier. Then the mid-session revocation re-check, then metered dispatch. Cedar fires on admin, platform, config and token decisions. It gives you policy_explain. You can audit each one.

We already have Entra / Okta. Why Auth?

Bring your IdP. Entra or Okta tells you who the agent is. DataShield proves the agent had permission to do it. Auth is the authorization and evidence layer. It sits downstream of identity, not in place of it.

Can an admin quietly delete a break-glass entry?

Deletion is detectable. Audit rows chain with SHA-256. Ed25519-signed checkpoints seal them. The checkpoints chain too. verify_chain calls out deletion, insertion, tampering, and truncation. Each gets its own verdict.

What is a scope-ceiling token?

It is an MCP tool token. It carries a hard limit on what it can reach. The agent works inside that ceiling. It can never rise above it. No matter how it asks. The dispatch pipeline checks the ceiling on each call. A delegated key never grants more than its owner intends.

How do I revoke an MCP session mid-conversation?

Revoke or suspend the agent in Auth. Its very next tool call hits the mid-session revocation re-check. Auth denies it on the spot. The session context drops mid-flight. The agent loses its old reach right away. Not when the chat ends.

What is break-glass access for AI agents?

It is emergency access with a timer on it. The grant starts as a dual-logged event. It runs against a TTL. Then it shuts off on its own. The grant lands in the hash chain. So does each action under it. Delete that entry. verify_chain reports a deletion.

Verification distinguishes four failure classes An audit chain of eight entries with injected faults: a tampered row, a deleted entry, and a truncated tail. Verification classifies each fault precisely instead of returning a bare pass or fail. seq 1 seq 2 seq 3 seq 4 seq 5 seq 6 seq 7 seq 8 Ed25519 checkpoint Ed25519 checkpoint tampered row content ≠ hash deleted entry link broken truncated tail entries missing VERDICT VALID → seq 1..3 TAMPERING @ seq 4 DELETION @ seq 6 TRUNCATION after seq 7 verification distinguishes tampering · insertion · deletion · truncation

Auth v2.4.1 is in production. Downstream of Auth sit Ontology and Commander. Ontology is the governed data plane. Commander is the agent operations cockpit.

Per-call authorization with scope-ceiling tokens. Evidence nobody can quietly edit. Self-hosted, on your own box.

See pricing

You've seen the proof

Ready for a number? Scope your deployment and we'll price it against your own economics.

Get your quote →