ZAMBO.DEV

What Zambo Receipts Verify and What They Don't

By Brennan ZamboPublished: Last reviewed:

A Zambo receipt is execution evidence, not a universal proof of success. It gives a reviewer a stable record of what Zambo recorded for a tool call and a way to check the record's integrity. It does not turn an unobserved third-party outcome into a fact.

That distinction matters when an agent's work will be handed to someone else, used to support a decision, or followed by a consequential action. A confident chat response is not enough. Nor is a green status by itself. The useful question is narrower:

What did the execution layer observe, preserve, and make checkable - and what still needs confirmation from the system that owns the outcome?

This page separates current documented behavior from a recommended roadmap. “Not documented” does not mean a control does not exist; it means an evaluator should not rely on it until Zambo publishes and can demonstrate it.

Start with a low-risk example: connect the hosted MCP, run a read-only call in the live demo, then verify its receipt.

The claim boundary, at a glance

Claim What a receipt can support What it does not establish by itself
A call was recorded The receipt ID, tool, timestamp, status, and observed result stored by Zambo for that execution. That the caller was authorized, that a human approved the action, or that a claimed caller identity is real.
The stored output has not changed relative to its commitment The exact canonical bytes can be checked against the stated SHA-256 output hash. That the output is correct, complete, safe, or true in the outside world.
Zambo observed source-backed material Evidence and provenance fields, when captured, can identify an upstream source, capture details, and integrity material. That the source remains available, is authoritative, or supports a broader conclusion than the captured evidence.
An external outcome was observed A separately populated external-evidence record - such as a read-back, processor confirmation, transaction reference, or observed webhook - can support the specific observed confirmation. Delivery, final settlement, publication, or a durable state change when no corresponding upstream confirmation is present.
An execution is reviewable later A public receipt URL and verifier allow another person or system to inspect the recorded execution without the original chat. A fixed retention period, enterprise audit retention, legal hold, or a guarantee that every field is appropriate to publish.

The language is deliberate: say “Zambo recorded,” “the bytes matched,” or “the source system displayed this state at this time.” Do not silently upgrade those statements into “the agent completed the business outcome.” [1][2]

Current documented behavior

1. A receipt records one observed execution

Zambo describes an execution receipt as a public record for one execution step: what was called, what it returned, when it ran, and the SHA-256 commitment used to check the record. The receipt is designed to travel with a handoff, review, or later verification; it complements traces, logs, and metrics rather than replacing them. [1]

For a completed call, the current product documentation says the receipt may expose:

A failed, blocked, invalid, pending, or unavailable call is still meaningful evidence. It should remain a failure, waiting, or unavailable state - not be rewritten as completion. That record can help an operator investigate what happened; it does not prove the requested work finished. [2]

2. Canonical bytes make the integrity check reproducible

The hash is useful only if reviewers hash the same representation. In Zambo's current receipt model, canonical bytes are the exact UTF-8 byte sequence used for the output commitment. output_hash is the declared SHA-256 digest of those bytes. A matching digest supports one specific conclusion: the bytes exposed for verification match the stored commitment. [2][3]

It does not mean “hash the JSON after reformatting it.” A reviewer should not substitute a different serialization, whitespace policy, encoding, or JSON key order and call the result verified.

Verify a receipt in four steps

  1. Open the public receipt URL and ensure the returned receipt ID is the execution you intended to inspect.
  2. Check the tool, timestamp, status, schema version, and claimed execution boundary.
  3. Ask the verifier for its status and output hash; if canonical bytes are available, compute the stated SHA-256 over those exact bytes and compare it with output_hash.
  4. Review evidence, provenance, and any external confirmation separately from the integrity result.

Zambo publishes a verifier endpoint and examples on its execution-receipt guide and AER-1 open draft. The verifier confirms that the stored record passes the implementation's checks as recorded. It is not a general-purpose truth oracle. [2][3]

3. Provenance and external evidence must be read separately

An integrity check answers whether the stored record matches its commitment. Provenance answers what role Zambo had in the event. Evidence answers whether an upstream source was captured. External evidence answers whether an independently checkable external confirmation was actually observed. These are different questions.

When available, current receipt documentation describes evidence fields such as an evidence URL, source URL, source hash, content type, byte length, status, and capture details. The separate external_evidence array can describe an upstream confirmation such as a transaction reference, processor transaction, read-back, or provider webhook observed by Zambo. A successful HTTP response or a tool description is not enough to populate that confirmation. [2]

For asynchronous work, a request may first be recorded as accepted. Confirmation belongs in a later phase only after an observable callback, delivery event, settlement event, or equivalent status read. If there is no observable confirmation path, the documentation says the honest state is not applicable, not success. [2]

Practical rule: if the outcome matters outside Zambo, obtain a read-back from the system that owns the state, retain its source and capture time, and attach or link it to the review. For example:

4. Public verification is intentionally low-friction; it is not identity or governance

Zambo's current documentation offers a hosted MCP endpoint at https://zambo.dev/mcp. The free path is documented as 20 calls per tool per day, with no account, API key, or credit card; completed calls include receipts. Public receipt pages and verification can be inspected without buying the call that created them. The free quota pauses at its limit and is documented not to silently convert into a paid call. [4][5]

For workloads beyond the anonymous quota, the current pricing page documents a 24-hour Day Pass and ongoing Pass options. A valid capability key can bypass anonymous quota and burst gates, while product and provider allowances still apply. Those are access mechanics, not evidence of user identity, organizational tenancy, authorization to act, or a security approval. [5]

There is an important side-effect boundary here: Zambo's tools page identifies the live tools/list catalog - not a marketing page - as authoritative for a tool's access scope, side effects, and idempotency. The current public material does not make the anonymous/free tier a blanket read-only or zero-side-effect guarantee. Before any call that might write, spend, publish, change access, or touch sensitive data, inspect the applicable live tool contract and confirmation mechanism. [6]

5. Approval, execution, and confirmation are different states

Zambo's approval guidance separates four states: proposed, approved, executed, and confirmed. A clear approval should point to a specific action, target, scope, parameters, limits, approver authority, expiry, side effects, and recovery path. A material change requires a new approval. [4]

But the same page is explicit: it describes the boundary; enforcement depends on the specific tool and integration. Zambo does not make a blanket guarantee that every tool has an enforced approval gate. A valid receipt does not authorize a payment, approve a trade, grant a permission, or prove a human approved the request. [2][4]

For consequential operations, use the following minimum review sequence:

  1. Present a concrete proposal and obtain the required human or policy approval.
  2. Compare the request about to run with the approved scope; stop if the target, amount, recipient, or side effects materially changed.
  3. Execute once with the relevant tool contract and preserve the returned status, including partial failure or timeout.
  4. Read back the outcome from the provider or destination system before reporting it as confirmed.

6. Privacy and retention have real limits

Zambo's security page says production public service traffic is served over HTTPS and that Zambo does not ask for or store user passwords, private keys, or seed phrases. It also says requests and operational records are processed as needed to execute requested features, return receipts, secure the service, and handle payments or support. Users should not submit credentials, secrets, card numbers, private keys, seed phrases, or confidential information that should not be processed in a job. [7][8]

Receipts are intended to be public and inspectable. Sensitive prompts, private contact information, upstream secrets, and confidential response bodies should be excluded or redacted before publication. A public URL is not a reason to make every field public. [2][3]

The current Data Processing Addendum is labeled “Draft - legal review required,” not an executed agreement. It says operational logs, rate-limit records, payment records, and receipts may be retained for a period reasonably needed for service delivery, abuse prevention, disputes, legal obligations, and auditability. A customer may request deletion of customer-controlled personal data, subject to legal, security, payment, or fraud-prevention limits; public blockchain records cannot be deleted by Zambo. The draft also says that the current provider list should be confirmed before a customer-specific agreement and does not claim that a fixed list is complete. [8]

That is useful disclosure, but it is not a fixed retention schedule, a contractual deletion SLA, a complete subprocessor register, or a data-residency commitment. Treat it accordingly during a privacy or procurement review.

Where a receipt stops

A receipt does not replace:

Zambo's security page expressly cautions that receipts are one layer in a control process and do not replace these obligations. The appropriate level of review should follow the cost of being wrong - not the agent's confidence. [7]

Enterprise evaluation: what is and is not claimed today

Evaluation area Current documented position Do not infer or claim today
Assurance Zambo says its security page is not a certification and does not claim SOC 2, ISO 27001, penetration-test certification, or absolute security. [7] Certified compliance, an independent assessment result, or a blanket enterprise-security assurance.
Data processing A DPA draft describes purposes, types of submitted data, deletion requests, and broad retention considerations. [8] An executed DPA, fixed retention/deletion commitments, or a complete contractual subprocessor schedule.
Tenancy, residency, and service commitments No enterprise tenancy, residency, or SLA commitment is established on the cited public pages. Private tenancy, tenant isolation, regional data residence, uptime guarantees, or recovery commitments.
Approval and high-risk action control Approval guidance exists, but enforcement is tool- and integration-dependent. [4] A gateway-enforced control for every write, financial, access, or administrative action.
Receipt integrity Zambo documents canonical bytes, SHA-256 commitments, schema versions, evidence/provenance fields, and public verification. [2][3] That a receipt proves provider truth, authorizes a request, or proves any outside-world outcome without appropriate external evidence.

The right conclusion for a regulated or high-impact workflow is not “receipts are insufficient.” It is “receipts are one precise evidence layer, and the rest of the control stack must be explicit.”

Recommended roadmap - not current product claims

The following controls are recommendations drawn from Zambo's published strategy context. They are not claims that Zambo currently implements them.

Priority Recommended control Why it closes a real boundary
P0 Publish one canonical endpoint and a machine-readable live catalog that includes tool schema, side-effect class, quota class, examples, and errors; test owned configuration links continuously. An evaluator needs a single authoritative contract rather than relying on scattered page copy.
P0 Release an open verifier kit with fixed canonicalization/hash fixtures, receipt schema/versioning, redaction guidance, CI, and key-rotation guidance. Independent reproduction of the core integrity check is stronger than a vendor-hosted explanation alone.
P1 Classify every tool as read-only, write, financial, or access/admin; limit anonymous use to demonstrably safe/read-only tools. The current no-account path is valuable for evaluation, but it should not become an ungoverned route to consequential side effects.
P1 For consequential tools, enforce approval that is bound to the request hash, expires, is invalidated by material changes, resists replay, and records partial outcomes. A generic “yes” cannot safely authorize a changed or replayed request.
P1 Add team evidence collections with roles, exports/webhooks, retention choices, spend controls, and an immutable artifact manifest that explains corrections and redactions. A portable receipt becomes operationally useful when a team can retain, review, and hand it off with governed access.
P1 Publish an enterprise readiness packet: data flow, isolation approach, subprocessor/residency position, encryption/key-management description, retention/deletion process, incident/BCP status, vulnerability disclosure, and exact assurance status. Security questionnaires should be answered with implemented controls and evidence - not aspirational marketing.
P1 Commission scoped independent testing of MCP confused-deputy risk, prompt/tool poisoning, SSRF, cross-tenant isolation, receipt tampering, replay, and approval bypass; publish an executive summary and remediation status. The receipt layer is only as credible as its execution and access-control substrate.

Until these controls are implemented and documented, Zambo should not promise enterprise compliance, tenant isolation, private tenancy, data residency, SLAs, or universal approval enforcement.

Compact control checklist

Use this checklist before relying on a Zambo receipt in a review, handoff, or decision:

Frequently asked questions

1. Does a matching SHA-256 hash prove the agent's answer is true?

No. It proves that the canonical bytes being checked match the stored hash commitment. It does not prove that a provider was accurate, a model reasoned correctly, or an outside-world result occurred. Review source evidence and external confirmation separately. [2][3]

2. Can someone verify a public receipt without an account, wallet, or original chat?

Yes, for a public receipt. Zambo documents public receipt pages and a verifier endpoint that can be checked without a wallet, token, or account. The reviewer still needs to assess what the receipt actually observed and whether the record is suitable to share. [2]

3. Does an approval or a receipt prove that a high-impact action completed?

No. Approval authorizes a defined next action; it does not prove execution. A receipt can document the recorded call and returned status; it does not prove delivery, settlement, publication, or a durable data change unless the appropriate external confirmation was captured. Approval enforcement also depends on the tool and integration. [4]

4. Are receipt contents private, and how long are they retained?

Treat public receipt content as shareable only after sensitive material is excluded or redacted. Zambo's current DPA is a draft and describes retention in purpose-based terms rather than a fixed schedule. It allows deletion requests subject to stated legal, security, payment, and fraud-prevention limits; it cannot delete public blockchain records. Do not submit secrets or confidential material that should not be processed. [7][8]

5. Is Zambo ready to satisfy every enterprise security questionnaire?

No such claim is made. The public security page explicitly does not claim SOC 2, ISO 27001, penetration-test certification, or absolute security. The cited pages also do not establish private tenancy, residency, SLA, or universal approval enforcement. Use the documented controls as evidence, list the remaining requirements, and require written commitments only where they have been implemented and agreed. [7][8]

Continue the review

References

[1] Zambo, “Receipts as execution evidence.” https://zambo.dev/docs/receipts-as-execution-evidence/

[2] Zambo, “AI Agent Execution Receipt - Definition & Verification.” https://zambo.dev/execution-receipt/

[3] Zambo, “AER-1: AI Agent Execution Receipt.” Open draft. https://zambo.dev/aer-1/

[4] Zambo, “Planning is not execution.” https://zambo.dev/approvals/

[5] Zambo, “Pay for trust, not seats.” https://zambo.dev/pricing/

[6] Zambo, “Live tools through one MCP connection.” https://zambo.dev/tools/

[7] Zambo, “Security at Zambo.” https://zambo.dev/security/

[8] Zambo, “Data Processing Addendum.” Draft - legal review required. https://zambo.dev/dpa/