Problem Deploy Demo Security Pricing GitHub FAQ
  For the regulators and courts that scrutinize AI decisions: OCC · FinCEN · NYDFS · EU AI Act  and more →

Your AI is already
making decisions.
Prove every one
of them.

A record is tamper-evident proof of what your AI agent decided, sealed the moment it happened and checkable by anyone — without you, and without us. When a regulator or opposing counsel asks you to prove what happened, it's what you hand them.

A working system, live today. Not a mockup. Seen live on a 30-minute call.
The gap

Someone challenges the decision.
You have nothing.

Banks, insurers, and healthcare companies are deploying AI agents to approve loans, flag fraud, deny prior authorizations, and triage patients. When a regulator, an auditor, or opposing counsel asks why the agent did what it did, most companies cannot answer.

OCC examination scenario

Your AI agent approved $4.2M in refunds last quarter. The OCC examiner wants three things: which policy governed each decision, whether the model got exactly what was authorized, and proof the record was not touched afterward. You have logs. They are mutable. Not enough.

Litigation scenario

Opposing counsel subpoenas your AI decision records. Your logs are not write-protected and carry no signature, so anything you hand over can be challenged on authenticity. And if your own cloud signed the evidence about decisions that ran on its infrastructure, they will challenge its independence too.

When someone asks about one decision

A challenger asks about one specific decision: the February 18, 2026 loan denial on application LN-2026-0218-3391. Here is what each demand costs you.

The examiner asks forYour stack todayWith PlainReal™
Which policy governed the decisionReconstruct from deploy history, and hope it matchesSealed into the artifact as policy_version_hash
That the model got exactly what was authorizedYou have the input logged, but cannot prove it was not changedBound before execution as input_hash
That the record was not altered afterwardRows can be updated. Logs are mutableWORM-committed, signed, timestamped
Independent verificationYou vouch for your own logsThe examiner verifies offline, without you
Time to produce itWeeks of cross-system forensicsOne record. Under 2 seconds
Five tools. None of them is neutral.

Each was built for something other than legal-grade decision evidence, and each stops at the same place: the record stays with a party that has a stake in the outcome.

Current toolWhat it doesWhat it lacksWith PlainReal
CloudTrail / audit logsRecords API callsThe same provider cannot be both the infrastructure and its auditorA record the challenger can check without trusting your cloud
AI monitoring platformsTraces execution, monitors driftMutable. Not evidenceSealed the moment the decision happens, by a party with no stake in the decision
OPA / policy enginesEvaluates rules at runtimeEnforces, but leaves no provable recordEvidence of what was authorized, that stands up without you
LLM observability toolsLogs LLM callsLogs you could have written yourselfSigned outside your stack, and checkable without us
SIEM / log aggregatorsAggregates logs across systemsCollects, but nothing is sealed or independentOne artifact an examiner verifies offline, on their own
Non-determinism

You cannot re-run an LLM
to find out what it did.

Every other system in your stack can be replayed: same inputs, same code, same result. An AI model is not. Same prompt, same settings, and the answer can come back different, because the provider updated the model behind the same version string or the sampling varied. An agent, chaining several such calls with shifting context, is further still from reproducible.

So you cannot reconstruct what the agent decided six months ago. If it was not sealed as it happened, to the exact input the model saw, it is gone. And the discovery order always arrives long after the decision, which is why capture has to be live.

The actual problem

Nobody in the chain
is neutral.

When an AI makes a consequential decision, the record of it is scattered across the systems that produced it. Your company deployed the AI agent. A vendor supplied it. A provider served the AI model. Some chains are longer. Some are shorter.

THE DECISION CHAIN · EVERY PARTY HAS A STAKE Your company deployed the AI agent Vendor supplied the AI agent Model provider served the AI model SEALS & ATTESTS OUTSIDE THE CHAIN Independent witness no stake in the decision · anyone can check

PlainReal is that independent witness. Outside the chain, with no stake in the decision itself.

THE DECISION CHAIN · EVERY PARTY HAS A STAKE
Your company
deployed the AI agent
Vendor
supplied the AI agent
Model provider
served the AI model
SEALS & ATTESTS
OUTSIDE THE CHAIN
Independent witness
no stake in the decision · anyone can check

PlainReal is that independent witness. Outside the chain, with no stake in the decision itself.

The in-house case is the worst one, not the best. Build the whole stack yourself and you hold the evidence about everyone's conduct, your own and your vendors'. Every record you produce is a record you could have written.

Better logging, immutable storage, governance tooling, vendor attestation: all worth doing, none of them close this. Each still leaves the record with an interested party.

The gap is not what you think

What is missing is not completeness.
It is independence.

The bar a record has to clear
01Sealed when the decision happened. Afterwards is too late.
02Fixed to what was actually in front of the model, not what someone says was.
03Any later change is detectable. We do not claim a record cannot be attacked, only that an attack cannot go unnoticed.
04Checkable by the challenger without trusting us, or you.
Why leaving costs you nothing

The format is public and the verifier is public. Stop paying us and every record you already hold still verifies, with no cooperation from PlainReal. What you pay for is the sealing itself, decision after decision, because tomorrow's decisions cannot be sealed after the fact. That is how you know the independence claim is real, not marketing.

The artifact

A PlainReal record.

One self-contained artifact per AI agent action. Signed, sealed, timestamped.
Click any field below to see what it proves. ↓

Each field exists for a forensic reason. Click to see it.

What TIER-A means Ed25519-signed, WORM-committed, RFC 3161 timestamped. TIER-A is the evidence grade built for named compliance controls.
demo_record.json  ·  excerpt TIER-A
// Excerpt of demo_record.json. Real values, real signature.
// The full 33 fields are on the Demo page.

  "record_id"       "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d"
  "record_version"  "1.0.0"
  "evidence_tier"   "TIER-A"signed · WORM · timestamped
  "decision_kind"   "MODEL_DECISION"
  "capture_layer"   "BUSINESS_LAYER"decorator
  "consequential"   true
  "principal_identity" "agent:credit-scoring-v2"
  "action_type"     "credit_decision"
  "execution_result" "APPROVED"

  "input_hash"       "9c195c99e72720b3.."bound pre-execution
  "policy_version_hash" "6b09e1031a4529aa.."
  "causality_chain_hash" "1f7588b3d1f0c503.."rebound at seal
  "provenance"
    "upstream" root record
    "workflow_run_id" "c3d4e5f6-a7b8-4c9d.."
  
  "deployment_mode" "SAAS_MANAGED"who ran the signer
  "governance_context"
    "accountable_party" "org:acme-lending"
    "environment"       "PROD"
    "oversight_mode"    "SOLELY_AUTOMATED"
    "retention_class"   "STANDARD_7Y"lock derives from this
  
  "lock_verification_latency_ms" 47
  "signing_key_id"  "69a0bbac56da5fae.."Ed25519 public key
  "signing_attestation" "c56e31877d64f193.."the only unsigned field

Verify independently: plainreal verify dp_9f3a2c1e

Integration

Two ways to deploy.

Both produce the same record, verified by the same CLI. Start with auto-instrument for immediate coverage, then promote your regulated paths to the decorator.

@plainreal.consequential   Decorator

Wrap a regulated function. The input is sealed before it runs. For OCC, NYDFS, and litigation evidence.

plainreal run   Auto-instrument

Zero code changes. Captures every LLM call at the client boundary. For EU AI Act Article 12 and GDPR record-keeping.

See how each mode works, step by step →
Compliance coverage

Your regulators. One artifact.

One record maps to the controls each framework names, from OCC agentic-AI supervision and FinCEN AML effectiveness to NYDFS Part 500 and EU AI Act Article 12. The same record answers all of them, rather than a separate system per regulator.

FinCEN OCC NYDFS EU AI Act GDPR SOC 2 NIST HIPAA FDA QMSR Colorado EO 14409
All frameworks, in detail →
Security review

OWASP Agentic AI Top 10, fully mapped.

All 10 agentic-AI risks map to specific record fields, so a security review checks named controls instead of reading a document. The controls live in code.

See the full OWASP mapping & security architecture →
Ed25519FIPS 186-5 Signing
FIPS 140-2Level 3 HSM
RFC 3161Trusted Timestamp
29 Fieldsrecord schema
34Design Issues Closed
10/10OWASP Agentic AI Mapped
The architecture of audit-grade evidence

Four pillars.

The independence above is not a claim, it is an architecture: four properties, each held by a different party so no single one can rewrite the record. PlainReal signs it. Your S3 bucket stores it in write-once mode. A neutral authority timestamps it. And any past artifact still verifies using only the published key, even if PlainReal is gone.

Full architecture & the crypto behind each pillar →
About the founder
Swapan Shridhar

Swapan Shridhar.

19 years building infrastructure that proves data integrity at the OS level, the storage stack, and federal compliance: HP, VMware, Cloudera, FedRAMP GovCloud, FIPS 140-3. PlainReal asks the same question about AI decisions.

Full background ↗
Honest scoping

Who this is not for.

An evidence company that overstates the need is the last one you should trust with evidence. If any of these fit you, you do not need us yet.

Your AI does not make consequential decisions about people or money.

Nobody subpoenas a copy drafter. Log it however you like.

You want to prevent bad decisions, not prove what happened.

That is guardrails and policy enforcement. We record and prove, we do not stop the agent. Different job.

Nobody with authority will ever ask you to prove it.

No regulator, auditor, plaintiff, board, or contracted customer. If that is genuinely true, do not buy this.

Why now, if no law forces it

No law or regulation currently compels cryptographic decision evidence, and we will not pretend otherwise. What we build for is the challenge itself: the discovery request, the adverse-action suit, the examiner asking a question you cannot answer. That exists today, regardless of what any law requires.

Common questions

Before you ask.

Your artifacts live in your S3 bucket under your Object Lock policy. PlainReal has no write access after provisioning, so every artifact stays in your possession, under your retention policy. The standalone verify CLI is open source: your auditor verifies authenticity using only your bucket access and the published public key. Nothing you hold depends on PlainReal still existing.
No. A PlainReal record is written to your S3 bucket in your AWS account. The signing operation receives the hash of your data, not the data itself. PlainReal has no write access to your bucket after provisioning. The deployment_mode field records which arrangement produced a given record, so a reader can see it rather than infer it.
For regulated decision functions, start with the decorator (@plainreal.consequential) on the functions that make regulated decisions. This produces the strongest evidence, built to meet OCC examiner, NYDFS, and litigation discovery standards. Auto-instrument is the right starting point if EU AI Act Article 12 or GDPR Article 22 record-keeping is your near-term driver. We recommend running both in production.
See the full FAQ →
Get started

Become a design partner.

For Compliance, Legal & Risk Teams
What would you hand over if someone asked you to prove it?

The system is live and working today. It seals an AI decision into an independently verifiable record, and if the record is altered, verification fails. It is early, being shaped into production with the first few regulated teams, and you help define what it must prove.

The call is a live walkthrough on your own decision types, not a slide deck. We are taking on two design partners. You define the artifact your auditor needs, we build to it, and the first two shape the format the rest of the market inherits.

90-day pilot, 50% upfront. $15-25K depending on integration depth and auditor requirements. Design-partner pricing applies to the first two.

Request Access Book a 30-minute call

contact@plainreal.com

For Engineering Teams
Evaluate the architecture.

The schema is open, the OWASP mapping is public, and the standalone verify CLI will be open source, so your auditor can run it themselves. Inspect the schema and verify a sample artifact before any conversation with us.

Explore Record Explorer See Deployment Modes

SDK integration: 30 minutes in a clean environment · Enterprise production: 1–4 hours

Request access.

90-day pilot · 50% upfront · $15-25K by scope. One conversation to see if it fits.

Or book directly: 30-min call ↗

Received. We will be in touch within one business day.