Everything a compliance, engineering, or risk team asks before a first call. ← Back to home
For regulated decision functions, the right starting point is the decorator (@plainreal.consequential) on the functions that make regulated decisions. This produces the strongest evidence, designed 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. It records every LLM call made through the instrumented client, without code changes.
We recommend running both in production. A coexistence guard ensures exactly one record per call, never two.
Yes. Same record schema, same Ed25519 signing, same S3 Object Lock COMPLIANCE mode WORM, same RFC 3161 timestamp, same standalone plainreal verify CLI. The capture_layer field tells the auditor which forensic claim applies. The verify CLI validates records.
SDK integration in a clean development environment: 30 minutes. Enterprise production integration: 1-4 hours. Enterprise security review of the interceptor that binds each call to an attested SDK build: 3-6 weeks, reduced by the OWASP mapping. Total onboarding to first production artifact: 4-8 weeks.
A valid signature is a narrow claim, and the narrowness is the point. It proves the bytes are the bytes that were signed, and that nothing has changed since. Five things it does not prove:
Not that the decision was correct. A verified record of a bad decision is still a verified record of a bad decision. Evidence of what happened is not a judgement about whether it should have.
Not that the record is complete. A signature covers what is present. It cannot show you what a producer chose never to record in the first place.
Not write-once custody. The declared retention_class is signed, and the substrate derives the Object Lock period from it. Confirming a specific object is genuinely under that lock requires access to the storage account.
Not when it happened. That is the RFC 3161 timestamp's job, and the signature covers content rather than time. Published sample records carry no timestamp token.
Not human non-repudiation. A record showing that a person approved something proves the system recorded that approval tamper-evidently. It does not prove that person personally signed anything. Authentication happens upstream, outside our trust boundary.
There has also been no third-party security audit. When there is one, we will name who did it.
In production, TIER-A means HSM-signed inside FIPS 140-3 Level 3 hardware, WORM-committed, and RFC 3161 timestamped. Design partner phase uses software signing with the same Ed25519 algorithm. The strongest grade we produce. Whether it evidences a particular SOC 2 criterion depends on the control your own organisation wrote, not on anything universal.
TIER-B: Customer-hosted attestation with a declared 60-second uncertainty window. Corroborating evidence. The distinction is explicit in the evidence_tier field of every artifact.
Yes. The OWASP Top 10 for Agentic Applications mapping is published open source on GitHub. Every control claim is tied to a specific named field in the record schema, also published. Your security team can review the mapping against the schema and verify every claim independently.
The mapping distinguishes between Prevention and Recording. Naming what each mode actually does is more honest than claiming prevention for everything.
Do both. An archive answers a question you will also be asked: did you keep it. It holds the record outside your own systems, which is a real kind of independence.
A record answers a different one. What was fixed before the model ran, and can someone outside check it without asking you, your archive, or us.
A record is a file. Put it in the archive you already pay for and it still verifies on its own.
It changes the question, it does not remove it. An examiner who accepts that a person signed off will ask what that person was shown, and when. Your agent produced the score, the recommendation or the shortlist the reviewer acted on, and that is the part nobody can reconstruct afterwards.
A record pins it where it happened: the input the agent was given, the policy in force at that moment, and what it returned, sealed before the reviewer saw any of it. The approval is recorded alongside, as a salted reference to the reviewer rather than a raw identity.
What it does not do is prove the person approved. PlainReal signs; the reviewer does not. Authentication happens in your identity system, upstream of us. So the record shows that the system recorded an approval by a named reviewer at a stated time, tamper-evidently. It is not that person’s signature and we will not describe it as one.
That distinction is worth having in writing before someone else draws it for you.
EU AI Act Article 12 requires automatic event logging for high-risk AI systems; it does not, in its own words, mandate cryptographic integrity. But a log that could have been altered after the fact carries little evidentiary weight with a regulator, a court, or an auditor. That gap between logging and evidence is the point. The Annex III obligations are deferred to 2 December 2027, so this is rarely about a single EU deadline. A discovery request, a SOC 2 audit, or an OCC exam tests whether you can prove a decision much sooner. A PlainReal record is built for that bar: tamper-evident and independently verifiable, so whoever challenges it can check it themselves.
Yes. OCC Bulletin 2026-13 (April 2026) revised interagency model risk management guidance but explicitly excluded generative and agentic AI from scope, on the basis that these technologies are "novel and rapidly evolving." The same agencies have signaled a forthcoming RFI specifically addressing AI-driven model risk. Meanwhile the OCC's Spring 2026 Semiannual Risk Perspective named agentic AI as a supervisory priority.
Banks face a gap: their agents fall outside the formal framework but inside the active supervisory focus. The real question is whether your governance program produces evidence that survives an examiner asking "what controlled that decision?" under a framework still being written. Mutable logs cannot. A PlainReal record produces a signed, WORM-committed artifact for each consequential agent action.
CloudTrail records that an API call happened. It does not record why the AI decided what it decided, what policy was in force, or what input the model received. It can also be altered, by your own team or by your cloud vendor. An OCC examiner or opposing counsel will ask one question: can you prove these logs were not touched after the fact? With CloudTrail, you cannot. With PlainReal, the answer is yes, because each artifact is signed, WORM-committed, and timestamped by a neutral party.
The evidence exists whether you capture it or not. The regulator will find the bad decisions regardless. What PlainReal gives you is proof that you found the problem internally, before the examiner arrived, and proof of exactly when you knew.
Mutable logs do not protect you. They mean the examiner finds the problem and you cannot establish your own timeline. Tamper-evident evidence is what lets you show a good-faith compliance program rather than a gap you cannot account for.
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.
Your artifacts live in your S3 bucket under your Object Lock policy. PlainReal has no write access post-provisioning. Every artifact stays in your possession, in your bucket, under your retention policy.
The standalone verify CLI will be open source. Your auditor verifies authenticity using only your bucket access and the published public key. We are establishing escrow custody of source code and keys for the cessation scenario.
Past artifacts remain independently verifiable even if PlainReal ceases operations. New artifacts require PlainReal signing. Nothing forces you to continue. What continuing buys is the signing infrastructure, schema currency as regulations evolve, and operational tooling. Past evidence is yours either way.
Three things, and one thing we cannot offer.
The signing service. Every new record requires Ed25519 signing, with HSM backing in production. Without this, your agents cannot produce new evidence.
Schema currency as regulations evolve. EU AI Act enforcement clarifications, OCC bulletin updates, new state laws, FinCEN rulemaking. We keep your evidence schema current. The OCC Bulletin update from 2025-26 to 2026-13 and the addition of Annex IV and SOC 2 CC8.1 are recent examples of work the schema captures so you don't have to track it.
Operational tooling. Fleet-wide monitoring, anomaly detection across deployments, compliance reporting, and integration with downstream audit systems that the standalone CLI does not provide.
Not a fourth thing. No auditor or CPA firm has accepted a PlainReal record, because we are in design-partner phase and none has been put in front of one. If a reference base ever forms it will be built by customers like you, so it is not something we can offer you now.
OpenTelemetry spans are mutable, infrastructure-dependent observability records designed for debugging. They can be deleted, modified, or selectively exported. An OCC examiner or opposing counsel can challenge their integrity.
Signing today is in software, using Ed25519 (FIPS 186-5). Moving it into a FIPS 140-3 Level 3 HSM is a later phase, with the same algorithm and the same schema. Both are written to S3 Object Lock COMPLIANCE mode and timestamped by a neutral RFC 3161 TSA. One is for debugging. The other can be checked by a regulator or opposing counsel without our cooperation. Not the same thing.
The sealing operation runs in the background, so it never blocks your agent. The record identifier returns immediately; the WORM commit and trusted timestamp complete asynchronously. Each artifact records its own sealing-time metadata for forensic transparency.
Because you would be signing your own evidence. An OCC examiner or opposing counsel will ask: who holds the signing key? If the answer is the same company that made the decision, or the same cloud that hosted it, the independence argument fails.
PlainReal holds the signing key. The timestamp comes from a neutral third-party TSA. Your S3 bucket holds the artifact. No single party controls all three. That separation is what makes the record credible to a regulator who was not in the room when the decision was made.