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.
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; 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, and the production deployment model includes redaction and tokenization of sensitive fields before evidence is stored.
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. Continuous monitoring, scheduled revalidation, and event-driven re-checks are planned capabilities on the roadmap; they are not current behavior, and Pruvz does not silently re-verify results in the background.
The production deployment model.
Pruvz's production deployment model is designed around the following controls. They will be configured and completed for each founding design-partner 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.
- Configurable evidence retention, deletion, and redaction policies.
- 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, evidence integrity today comes from ordered, append-only evidence records with server-assigned trust levels; cryptographic sealing and external anchoring are on the roadmap, and records are designed to be tamper-evident, not claimed as sealed today. 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 design-partner or enterprise evaluation.
Current availability
Validated today. The complete verification lifecycle on this page runs end to end in Pruvz's validation environment against controlled billing and CRM systems of record: independent read-back, evidence production, window and retry semantics, mismatch handling with human review, and historical-result behavior. Controlled source systems 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 validator behind it, at pruvz.ai/evidence-packet.
With founding design partners. Production connectors for live systems of record, such as Stripe and HubSpot, and the customer-specific deployment controls above will be selected, configured, and completed with 3-5 founding design partners, according to each partner's systems, access model, hosting, and security requirements. The program is open, and connectors are not yet deployed in customer environments.
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. Continuous monitoring and scheduled re-verification are planned capabilities, 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: August 1, 2026.