Who Audits the Agents? Three Reviewers, One Verifiable Record

Counsel rejects a dashboard screenshot (“you control that system”), a report the vendor could revise after the fact, and an agent action with no chain of authorization. What they need is a record opposing counsel can't credibly claim was doctored — and an answer to who authorized the agent to act.

What BlindOracle gives counsel

• Tamper-evident report — the report's content-hash is sealed in a signed 30105 proof. Change one character and the hash no longer matches; post-hoc revision becomes detectable.
• Chain of authorization — ProofOfDelegation (kind 30014) records which operator/parent authorized the agent, HMAC-linked. That is the “who is responsible” question counsel actually cares about.

The authority question: on whose order did the agent act?

Make it concrete. A prediction-market executor opened a position; a counterparty now disputes it and threatens a claim. Counsel's exposure is not only “was the audit report intact” — it's “on whose authority did this agent act, and can we name the responsible party?” A bare agent action is an orphan: no principal, no accountability, indefensible.

BlindOracle's actions are not orphans. Every time one agent spawns or delegates to another, a system-level hook emits a ProofOfDelegation (kind 30014) before the sub-agent receives a single instruction — an HMAC-signed record of delegator, delegate, parent session, the scope granted, and an expiry. The agent cannot opt out of it; the record precedes execution, so it is tamper-evident by construction.

Those records form a chain. The disputed trade's proof names its delegator; that delegator's proof names its delegator; and so on, until the chain terminates at a root operator holding an ERC-8004 passport. Counsel can therefore assert — and substantiate, link by link:

A forged link fails HMAC verification. A link issued by a revoked passport is rejected at emission. The result is the sentence counsel needs in a filing: “Trade #4471 was authorized by Operator O, through the signed chain O → A → B” — backed by cryptography, not the deploying team's say-so.

The two checks counsel runs

INTEGRITY — is the report what was attested?
1. Take report.json; recompute its SHA-256 content-hash.
2. Confirm it equals the audit_hash sealed in the 30105 proof.
   equal → byte-identical to what was attested.
   not   → altered after attestation (itself evidence).

AUTHORITY — who is responsible for the action?
3. From the action, read its ProofOfDelegation (kind 30014).
4. Verify the HMAC signature against the delegator's key.
5. Walk delegator → delegator up to the root operator's ERC-8004 passport.
   Each hop must verify; none may be revoked or expired.
   → You can now NAME the authorizing party, with proof.

An examiner signing an opinion rejects findings with no framework mapping, a list with no guarantee it wasn't pruned, and evidence that lives only inside the auditee's systems.

The story

Make it concrete. A Big-4 team is mid-engagement on a fintech that deployed a vendor-vetting agent with payment authority. One control under test: “agent-released payments were properly authorized and the supporting security review was complete.” The auditee hands over an agent audit report listing 9 findings. The examiner's instinct: is that all of them, or the flattering six? In a normal engagement that's settled by sampling and a measure of trust. Here it's settled by arithmetic — the Merkle root binds the finding count, so a 6-of-9 subset simply will not reconstruct the published root. The examiner recomputes the root, looks it up on Base at the audit's timestamp to confirm the record existed then (not quietly back-dated for the exam), and cross-walks each finding to NIST AI RMF (MEASURE/MANAGE) and ISO 42001. The supporting evidence stops being “management represented” and becomes “independently verified.”

What BlindOracle gives the examiner

• 5-framework mapping — every OWASP ASI01–10 finding is translated to NIST AI RMF (GOVERN/MAP/MEASURE/MANAGE), ISO 42001 clauses, CSA AICM controls, and MAESTRO categories. Workpaper-ready.
• Provable completeness — the Merkle root binds the finding count N. “You only showed me 6 of 9” is mechanically detectable, not a matter of trust.
• Independent anchor — the root is on Base mainnet + Sepolia + Nostr (ProofOfStateAnchor, kind 30106), confirmable on infrastructure neither the auditee nor BlindOracle controls.

The check the examiner runs

1. Read N (finding count) + merkle_root from report.json.
2. Recompute the root over the N committed findings → must match.
3. Look up the root on Base + Sepolia + Nostr via verifyAnchor().
4. Cross-walk findings → NIST AI RMF / ISO 42001 → workpaper.
5. Spot-check authority: pull the action's 30014 delegation chain to
   confirm a named, in-scope principal stands behind each agent action.

A vendor brings an agent that will touch the customer's data. The security team rejects a static PDF, a proprietary unauditable framework, and any verdict they can't spot-check.

The story

Make it concrete. A SaaS customer's security team is reviewing a vendor whose deep-research agent would ingest their internal documents. The vendor sends a clean audit — “risk 4.3, zero critical.” The team's policy is to trust nothing they can't reproduce, so they clone the open-source framework and re-run it against the agent themselves. Nine of ten categories match the vendor's report — but their run flags a delta on ASI02 (credential scoping) the vendor's summary glossed. Rather than re-litigate the whole engagement, they request the Merkle inclusion proof for that one finding, confirm it commits to the published root, and confirm the agent's actions carry a 30014 delegation chain back to a named owner. The review ends not with a gut call but with a precise, defensible position: where vendor and reproduction agree, where they differ, and exactly what must be fixed before the agent touches production data.

What BlindOracle gives them

• Reproducible findings — the assessment runs on the open-source MASSAT framework (Apache-2.0). They re-run it against the same target and confirm the score themselves.
• Inclusion proofs — for any single finding (“does it scope credentials? ASI02”), they request the Merkle inclusion proof, confirming that exact finding commits to the published root — without trusting the rest.
• Auditable methodology — because MASSAT is public, they vet the method, not just the verdict.

The check they run

git clone https://github.com/craigmbrown/massat-framework
massat audit --target <the-agent> --frameworks owasp-asi,nist-ai-rmf
# Compare your score + findings to the vendor's report.json
# Request an inclusion proof for any finding → verify it commits to merkle_root
# Confirm the agent's actions carry a 30014 delegation chain to a named owner

An agent opened a YES position; weeks later the market resolves against it and a stakeholder asks whether the trade was ever within mandate. The 30105 audit shows the agent's control posture, the 30014 chain names who authorized it, and the anchored root fixes the state at the time of the trade. “Was this authorized, and by whom?” stops being an argument and becomes a lookup.

An agent vetted a supplier and released an AP payment; finance later flags the payee. The content-hashed recommendation proves exactly what the agent decided on (no after-the-fact edit), and the delegation proof names who authorized the release. If the vetting was sound and the authorization valid, the organization is covered; if not, the precise failure point — bad input vs. bad authority — is provable rather than argued.

An agent pre-screened a counterparty and cleared them; the counterparty later turns out to be sanctioned. A regulator asks what the screen actually checked. Because the finding set is Merkle-committed with the count N bound in, the team can prove the complete set of checks the agent ran — not a flattering subset — and the anchored timestamp shows it ran before onboarding, not reconstructed afterward.

A multi-agent council recommended “go,” and one member's input is later challenged as compromised. Per-agent delegation chains show which agents took part and under whose authority, and the signed record of inputs shows exactly what each contributed. A single suspect input can be isolated and re-weighed without discarding — or blindly trusting — the entire decision.

An agent produced a memo that shaped a strategy; someone later claims it rested on a planted source. The audit attests that content-trap scanning (CaMel L1/L2) was applied to ingested web content, and the findings are reproducible via the open-source framework — so “did you ingest manipulated content?” gets a verifiable answer instead of a shrug.

BlindOracle audits a third party's agent on a buyer's behalf, and the buyer reasonably worries the auditor is conflicted. It doesn't matter: the report is content-hashed (BO can't revise it), the findings are N-bound (BO can't drop the unflattering ones), and the root is anchored publicly. The buyer verifies the audit without trusting BlindOracle — the conflict is engineered out, not promised away.