PPromptReports
Sign in
← All postsWorkflows

A trust packet a buyer can check: signed evidence for a security review

PromptReports6 min read

How the trust packet workflow will export approvals, incidents, promises kept and corrections as one signed packet that a security reviewer can verify without trusting the seller.

A trust packet a buyer can check is a workflow for founders selling to larger companies, and for the security reviewers on the other side of the deal. It will produce one signed export for an org and a period: the approvals people gave, the incidents and how they recovered, the promises made and kept, and the corrections. A reviewer can check every item on AI Source of Truth without taking the seller’s word for any of it. PromptCompute, RepoOps and CommitOps will each sign a section.

The packet check on AI Source of Truth and the trust center on this site are live. Three signed sections are still to go.

The problem

Security reviews ask for proof that people control what a company’s AI agents do. Who can approve an agent’s action? What happened the last time an agent broke something? Did the company tell the customer?

Teams answer with screenshots and a policy PDF. The reviewer cannot check either. A screenshot shows one moment someone chose to capture, and a policy says what should happen, not what did. So the reviewer takes the seller’s word, or sends another round of questions, and the deal waits.

How the workflow solves it

The packet will replace the screenshots with records. Each product that holds evidence will export its own section, signed: PromptCompute the approvals, RepoOps the incidents with their causes, recoveries and lessons, and CommitOps the promises made and kept. AI Source of Truth checks every item against its public record, and a person approves sharing the packet outside the company.

The reviewer then checks the packet on AI Source of Truth, without a PromptReports account. If anyone changes one item after export, the check will fail on that item and name it.

Step by step

When the workflow runner ships, a run will take these steps. Present tense means the part works in its product today; “will” means it is still to build.

A run will start when a person starts it for a named buyer and a period.

  1. PromptCompute will export the approvals, signed. Every PromptCompute decision is already signed; the packet section is the new part.
  2. RepoOps will export incidents, causes, recoveries and lessons, signed.
  3. CommitOps will export the promises made and kept, signed.
  4. AI Source of Truth checks every item against the public record. Its packet check is live at aisourceoftruth.com/verify/packet.
  5. A person approves sharing the packet outside the company. The share step will run only after someone approves file.share.external for the named buyer. If the buyer named on the approval differs from the one the run started with, the step will refuse with args_mismatch.
  6. The reviewer verifies the packet. On the packet check page they paste the packet, upload it, or give its URL.

The approval at step 5 is the gate that matters. A packet holds internal evidence, and it will leave the company only for the buyer a person named.

What the reviewer sees

AI Source of Truth calls a packet verified only when four things hold. It is signed by a key the issuer registered. The issuer is a member of the org. Every item is in the log, belongs to that org and was logged within the period. And no item has been sealed or corrected since.

The page is plain about the limit of that check. Verified “does not mean what the items say is true”. It means the items are what the org logged, when it logged them, unchanged. Items the org keeps private are confirmed only as present in the log for that org and period, and their content is never shown. Reading and verifying are free.

What the workflow will report

Each run will report:

  • The days from the buyer’s questionnaire to a signed-off review.
  • The share of items in the packet a reviewer can verify. The plan sets the target at 100%.
  • The follow-up questions per review.

Why it matters to a founder selling up-market

The security review is often the slowest step in a larger deal. Evidence a reviewer can verify on their own cuts the back and forth, because the reviewer has no need to ask whether a screenshot is current. The same packet will hold up later in an audit, since each item has a record that cannot be edited after the fact.

The packet is evidence, not a certification. We do not have a SOC 2 report yet, and the plan’s mappings to SOC 2 change management and to EU AI Act logging are planned work.

How to set it up

The packet needs no connection outside the family.

When the runner and the signed-in app ship, setup will be:

  1. Sign in with PromptReports ID and pick your org.
  2. Connect PromptCompute, RepoOps, CommitOps and AI Source of Truth.
  3. Register the agent that will assemble the packet.
  4. Set the approval policy for sharing a file outside the company (file.share.external) and for bulk exports (data.export.bulk). Both default to high risk.
  5. Name the buyer, the period and the sections, and start a dry run. It will show which sections would come back missing.
  6. Start the run, approve the share, and send the reviewer the packet and the check page.

An agent will start the run through the PromptReports MCP server or API, with the proposed start_run tool.

The trust packet is on every plan. Plans are per user per month: $25 for 100 workflow requests, $50 for 500, and Enterprise above 500. There is no free tier. One packet for one buyer is one request.

You can read about the packet today on the trust center, which lists each section and its state.

What is built today and what is planned

The workflows page lists the trust packet as partly built: three of five parts are merged, and the PromptCompute and RepoOps signed sections are still to go.

Built:

  • The packet check on AI Source of Truth (aisourceoftruth #241).
  • The trust center on this site, which explains the packet (PromptReports #32).
  • The signed promises section from CommitOps (commitops #149).

Still to go:

  • The signed approvals section from PromptCompute.
  • The signed incidents, causes, recoveries and lessons section from RepoOps.
  • The workflow runner. No runner exists today. The plan is a durable runner service in the PromptCompute stack, with one run id across products, approvals as steps, and each run metered as one workflow request.

Read more

AS
Post record
This post has no record on AI Source of Truth yet. Once it does, its verdict badge shows here and links to the record.

Read next

WorkflowsNov 10, 20266 min

Launch with proof: each launch claim tied to the change that shipped it

How the Launch with proof workflow checks the docs against a release, puts the announcement in front of a person, and records each claim so anyone can check it later.

Read →
WorkflowsNov 10, 20266 min

Customer escalation to recovery: one case from the complaint to the kept promise

How the escalation workflow will join the customer's report, the error, the fix and the deal into one case, with the fix and the customer notice approved together.

Read →