Enterprise security by architecture.
Pruvz is the business outcome verification layer for AI agents. Its trust model is structural: your agent executes the business action in your systems, and Pruvz independently verifies the outcome by reading your systems of record, keeping an ordered, append-only evidence record of what was claimed, what was observed, and what was decided.
This page explains that architecture the way a security reviewer needs it: the trust boundaries, the data Pruvz reads and retains, the verification lifecycle, and the production deployment model, with a precise statement of what is validated today.
The six security pillars, at a glance.
The architecture in six statements. Each one is expanded below, with the trust boundaries, the data model, and the deployment model behind it.
Execution and verification, separated
Your agent executes the business action; Pruvz independently verifies it by reading the system of record. Agents can submit claims, but only Pruvz's verification service assigns a final result.
Read-only verification access
Pruvz verifies by reading, not writing: it executes no business actions in your systems. In the production model, the agent's execution credentials and Pruvz's least-privilege verification credentials are never the same identity.
Append-only, ordered evidence
Claims, independent read-back observations, evaluations, and human review decisions are appended as ordered evidence with server-assigned trust levels; recorded evidence is never rewritten. Records carry cryptographic commitments and Merkle proofs that support independent tamper-evident verification; managed signing and external anchoring are enabled per customer.
Data minimization by design
Pruvz captures what proves the action, context, policy, decision, and outcome. Sensitive fields are redacted at the connector edge before evidence is stored, an enforced allowlist bounds what read-back evidence may contain, and the opt-in retention window is executed by a scheduled cleanup.
Encryption and least privilege
Sign-in is through Microsoft Entra with enforced roles, and access to actions, evidence, and results is tenant-scoped. The production deployment model is designed to provide encryption in transit and at rest, with least-privilege, reviewable access to evidence.
Built for enterprise security reviews
Designed to support enterprise security reviews and SOC 2 / ISO 27001-aligned environments, with executed retention and deletion policies today, and hosting options where commercially supported.
Why independent verification is the safer trust model
An AI agent's execution report is a claim made by the system being evaluated. If the agent, or any caller outside the verifier, could mark its own action as verified, the audit trail would only ever prove what the agent said, not what happened. That is the gap between an AI agent audit trail built from self-reports and evidence for AI agent actions confirmed at the source.
Pruvz closes it by separating execution from verification. Agents submit claims and execution receipts, but no external caller can create independent evidence or a final verification result. The expected outcome is derived by Pruvz from the decision-time policy snapshot, never accepted from the agent, and a final result is assigned only by Pruvz's verification service after independent read-back verification against the system of record.
How Pruvz separates execution from verification.
Agent execution and Pruvz verification are separate trust domains. Business actions are executed on your side of the boundary; verification, evaluation, and evidence live on Pruvz's side. Three flows cross the boundary: action claims and receipts come in, read-only queries cross to the source system, and the observed state returns to the verifier.
Data access and trust boundaries
What Pruvz reads. Pruvz reads the systems of record that already hold the business truth. Today the verification flow runs against billing and CRM systems of record, with the Stripe and HubSpot connectors proven against live Stripe and HubSpot test environments; connectors for further classes of systems, such as ERP, ticketing, approval flows, and risk systems, are on the roadmap. Verification access is read-only: a read-only verification connector observes state, it never changes it.
What Pruvz retains. What is needed to make a verification result inspectable. The action record preserves the immutable decision-time policy snapshot, and the agent's claim, the observed source-system state with timestamps, and the evaluation with its reason codes are appended as ordered evidence items, each carrying its source and a server-assigned trust level, together with any human review decision. Later workflow-state updates do not rewrite the evidence already recorded.
What Pruvz never does. Pruvz does not execute business actions, does not retry or remediate them in your systems, and does not approve or block agent actions at runtime. It records, verifies, and routes exceptions to human review. Data minimization is part of the design: Pruvz captures what proves the action, policy, decision, and outcome; sensitive fields are redacted at the connector edge before evidence is stored, an enforced allowlist bounds what read-back evidence may contain, and the opt-in retention window is executed by a scheduled cleanup.
The evidence and verification lifecycle.
AI agent outcome verification in Pruvz follows one auditable path from action to final result, with a defined verification window and retry semantics along the way.
Action captured
The agent's business action is recorded together with the exact policy version in force at decision time. Pruvz derives the expected outcome from that snapshot on the server; it is never accepted from the agent.
Execution completes
The agent or business system executes the action in your environment and submits its claim and execution receipts. Execution status and verification status are tracked as separate state machines.
Verification job opens
Completing execution creates exactly one verification job for the action. Verification runs off the agent's critical path, so it never blocks the workflow.
Independent read-back
Within the verification window, Pruvz reads the system of record: an initial delay where required, then retries with backoff. Retries repeat the verification read only. Pruvz never re-executes, retries, or remediates the underlying business action.
Outcome classified
An evaluable terminal observation is classified as verified or outcome mismatch; if the verification window expires without one, the action ends as verification failed. Only Pruvz's verification service assigns a final result, and exactly one terminal business fact is recorded per action.
Evidence and review
The evidence packet holds the action claim, policy snapshot, observed source-system state, timestamps, evaluation, and reason codes. Mismatches route to human review; the decision is appended as new evidence and never rewrites the original result.
What each verification state means.
Once verification begins, an action stays pending until it ends in exactly one of three terminal results. The boundaries are strict: a slow or unreachable source system is never reported as a business mismatch.
The system of record confirms the expected outcome. Only verified actions contribute to verified business totals.
The system of record contradicts the agent's claim. The action routes to human review; the recorded mismatch evidence stays intact whatever the review decides.
The outcome is not yet terminal, or the source could not be evaluated on this attempt. A pending or unreadable observation is never misclassified as a business mismatch.
The system of record could not be read within the verification window. A technical outcome, clearly separated from a business mismatch, with the attempts on record.
What a completed result means later
A completed verification result is a historical verification result: it states what the systems of record showed during the defined verification window, and it becomes final when Pruvz records a terminal result. If the source system changes after that, the recorded result and its evidence are not rewritten; they remain the proof of what was observed and when.
Capturing a later change requires a new verification or an explicit revalidation. A human can trigger re-verification of an externally resolved case, and the new fact supersedes by being appended, never by rewriting. Pruvz does not do continuous monitoring and does not silently re-verify results in the background; bounded post-verification re-checks are a planned capability on the roadmap, not current behavior.
The production deployment model.
Pruvz's production deployment model is built around the following controls. Sign-in through Microsoft Entra with role enforcement, tenant-scoped access, connector-edge redaction, and an executed retention cleanup already run in the product: sign-in, role enforcement, and tenant isolation are exercised by its release gate, and redaction and the retention cleanup are integration-tested, fail-closed. The remaining controls are configured and completed for each customer environment based on its systems, hosting model, and security requirements. None of this is a claim that a control is already operating in a customer production environment today.
- Least-privilege, read-only verification access to your systems of record.
- Separation of credentials: execution and verification are designed to use separate identities, so the verifier never acts with the agent's credentials.
- Tenant-scoped access and authorization boundaries around actions, evidence, and results.
- Encryption in transit and at rest for evidence and verification data.
- Evidence retention, deletion, and redaction policies, with the opt-in retention window executed by a scheduled cleanup.
- Customer-specific hosting, data residency, and storage requirements where commercially supported.
- Auditability end to end: evidence, the decision-time policy snapshot, and every verification decision are designed to be inspectable after the fact.
Two boundaries on these claims, stated plainly. First, cryptographic assurance is layered and per customer: the hash-based layers (content commitments and an append-only Merkle log) run in every deployment and support tamper-evident verification, while signing and external anchoring are enabled per customer, so no deployment is claimed to produce signed, anchored records out of the box. Second, Pruvz does not claim SOC 2 or ISO 27001 certification: the ceiling of the claim is an architecture designed to support SOC 2 / ISO 27001-aligned environments, and deployment-specific security documentation is available during a pilot, design-partner, or enterprise evaluation.
The cryptographic evidence chain, layer by layer.
Evidence integrity is built as independent layers, and each is claimed only at its own maturity. The hash-based layers are present in every deployment and verify without keys; the key-bearing and cost-bearing layers are enabled per customer, after a live acceptance against the specific provider.
In every deployment. Every evidence record has a deterministic content commitment (a canonical byte representation and its digest), and records land in an append-only Merkle log that produces inclusion and consistency proofs. These layers are hash-based: they verify offline, without any signing key.
Enabled per customer. Signed evidence envelopes use a managed, non-exportable key in Azure Key Vault, and evidence checkpoints can be externally anchored through the DigiCert public RFC 3161 timestamp authority. Both are implemented and acceptance-tested against those specific providers, and both are off by default because they carry recurring or customer-specific cost. An anchor proves a record existed no later than a point in time; it never proves when the record was created. The signing-key history is published in a signed, pinnable trust registry; externally timestamped key history is available through the same on-request anchoring.
Independently verifiable, offline. The public offline verifier (version 1.6.1, on npm, PyPI, and NuGet) checks the complete chain, from content commitments through signatures, key lifecycle, Merkle proofs, and anchor receipts, without contacting Pruvz, and a three-runtime adversarial conformance suite holds all three verifier implementations to identical verdicts on 41 published attack cases. The full chain was proven live end to end on September 1, 2026: evidence from a real action in live Stripe and HubSpot test environments was sealed, anchored, exported, and independently verified offline by all three verifiers. The first attempt was refused by the verifier over a certificate-chain defect and fixed before any claim was made: the gate refuses rather than rationalises. The recorded public demo runs the demo track, which signs nothing.
Verify a packet yourself: the walkthrough and the offline verifierCurrent availability
Validated today. The complete verification lifecycle on this page runs end to end in the product, and its release gate passed live on August 25, 2026 against live Stripe and HubSpot test environments: independent read-back, evidence production, window and retry semantics, sign-in with role enforcement and tenant isolation, mismatch handling with human review, and historical-result behavior. The public demo runs the same lifecycle against controlled source systems, which make every path, including the failure paths, reproducible on demand; you can see all of them at pruvz.ai/demo, and inspect a real exported evidence packet, with the public schema and offline verifier behind it, at pruvz.ai/evidence-packet.
Customer pilots and design partners. Customer pilots are open. The Stripe and HubSpot connectors run against live test environments today, never against customer production; rolling them onto a customer's own systems of record, together with the customer-specific deployment controls above, happens per pilot, and the first partner workflows will be selected and completed with the founding design partners according to each partner's systems, access model, hosting, and security requirements.
Security questions, answered directly.
The questions security reviewers and buyers ask first about Pruvz's verification and data model.
What is independent read-back verification?
After an AI agent executes a business action, Pruvz independently reads the system of record, such as billing or CRM, to observe what actually happened, and compares that observation with the expected outcome derived from the decision-time policy snapshot. The verification result comes from the source system's state, not from the agent's own execution report.
Does Pruvz need write access to my systems of record?
No. Pruvz verifies by reading. The business action is executed by your agent or business system with its own credentials; in the production model Pruvz uses separate, least-privilege, read-only verification credentials. Pruvz does not execute, retry, or correct business actions in your systems, and it does not approve or block actions at runtime.
Can the agent mark its own action as verified?
No. Agents and other external callers can submit claims and execution receipts, but they cannot create independent evidence or assign a verification result. Only Pruvz's verification service assigns a final outcome, and only after independently reading the system of record.
What evidence does Pruvz retain for an AI agent action?
The action record preserves the immutable decision-time policy snapshot, and claims, independent read-back observations with timestamps, evaluations with their reason codes, and human review decisions are appended to it as ordered evidence. Each evidence item carries its source and a server-assigned trust level, so an agent's claim is never confused with an independent observation.
What happens when the system of record cannot be read?
The action stays verification pending and Pruvz retries with backoff inside the verification window. An unreadable source is never classified as a business mismatch. If retries are exhausted, the action is recorded as verification failed: a technical outcome, kept clearly separate from a business mismatch, with the attempts on record.
Does Pruvz keep monitoring the system of record after a result is final?
No. A completed result reflects what the system of record showed during the verification window, and it is not silently re-checked afterward. If the source system changes later, the recorded result remains the historical record of what was observed and when; capturing the new state requires a new verification. A human can explicitly trigger re-verification of an externally resolved case, with the new fact appended to the record. Pruvz does not do continuous monitoring; bounded post-verification re-checks are a planned capability, not current behavior.
Run your security review with us
Security reviewers get direct answers from the team that built the architecture. For deployment-specific security documentation, an architecture deep-dive, or a security questionnaire as part of a design-partner or enterprise evaluation, write to hello@pruvz.ai or book a call and bring your reviewer.
Last reviewed: September 23, 2026.