Verifiable Inter-Agent Claims: Attestation and Signed Provenance Between Agents

There are two different questions an agent faces when another agent speaks to it. The first is who are you, answered by identity and the trust models built on it. The second, quietly more dangerous, is why should I believe what you just told me. An agent with impeccable identity and a spotless reputation can still assert something false — because it was prompt-injected, because it was fed poisoned data, because it is simply wrong. If the receiver accepts the assertion because of who said it, the falsehood propagates with the full authority of a trusted source. The remedy is to stop accepting assertions and start demanding verifiable claims: statements accompanied by evidence the receiver can check on its own, without trusting the speaker's honesty. This is an old idea in cryptography — the whole point of a zero-knowledge proof, introduced by Goldwasser, Micali, and Rackoff in 1989, is to let one party convince another that a statement is true while revealing nothing beyond its truth. This article ports that instinct to agent meshes: which claims agents make, what evidence can back them, and how a receiver verifies substance instead of trusting standing.

The claim, the evidence, the verifier

Fix the triad. A claim is a statement one agent asserts to another that the receiver must decide whether to act on — for example this output was produced by approved model code, or this record was read from an authorized source. Evidence is whatever accompanies the claim to let the receiver check it. A verifier is the procedure the receiver runs on the evidence to decide accept or reject. The defining property of a verifiable claim is that the verifier's decision does not depend on trusting the claimant's honesty — it depends only on evidence the claimant cannot forge. When that holds, a lying or compromised agent gains nothing by asserting falsely, because the assertion fails verification.

This reframes the trust problem productively. Identity answers who; reputation answers whether they tend to behave; but neither lets a receiver check the substance of a specific statement. Verifiable claims fill that gap by moving the basis of belief from the speaker to the evidence. The design question for each kind of claim becomes: what evidence would make this claim self-checking, and what would an adversary have to forge to defeat the check? A claim whose only evidence is the speaker's word is not verifiable at all — it is an assertion, and in a mesh of manipulable agents, assertions are liabilities.

A spectrum from assertion to proof

Verifiability is not binary; it is a spectrum defined by what an adversary must forge to defeat the check. At the weakest end sits the bare assertion: the agent says so, and the evidence is nothing. One step up is the signed statement: the claim is cryptographically signed by a key bound to a verifiable identity (as SPIFFE provides), so a forger must steal the key — the receiver now knows who committed to the claim and that it was not altered in transit, though not that the claim is true. Stronger still is attestation: evidence, ideally rooted in hardware, that binds the claim to a measured property of the claimant's environment — for example that it is running a specific, unmodified code image — so that forging requires defeating the attestation root, not merely holding a key.

At the strong end sit proofs of the claim's substance. A zero-knowledge proof (Goldwasser, Micali & Rackoff, 1989) lets the claimant convince the verifier that a statement is true while revealing nothing beyond its truth — the verifier gains certainty about the claim without learning the claimant's secrets and without trusting its honesty at all. The practical lesson of the spectrum is to match the strength of evidence to the stakes of the claim: a low-stakes routing hint may warrant only a signature, while a claim that gates an irreversible action deserves attestation or proof. Crucially, moving up the spectrum narrows what an adversary can get away with — from lying freely, to needing a stolen key, to needing to subvert a hardware root or break a cryptographic assumption.

Attestation: binding a claim to a measured environment

Attestation is the mechanism that lets an agent prove properties about itself rather than merely assert them. The pattern has three roles: an attester (the agent making a claim about its own state), a verifier (the party checking the claim against a policy), and a relying party (whoever acts on the verifier's verdict). The attester produces evidence — a signed set of measurements describing, say, the exact code image and configuration it is running — rooted in something the attester cannot fake, typically a hardware root of trust. The verifier compares that evidence against known-good reference values and issues an attestation result the relying party can consume. SPIFFE supplies the identity substrate this builds on: a cryptographically verifiable name for the workload, so the attestation is bound to a known agent rather than an anonymous process.

The security value is that attestation converts a class of claims from unverifiable to verifiable. I am running approved code is a bare assertion when spoken; backed by attestation it becomes a claim the receiver can check against reference measurements, defeating a whole family of impersonation and tampering attacks catalogued in MITRE ATLAS and the OWASP Agentic threat guidance. But attestation has honest limits that a rigorous treatment must state. It proves what code is running, not that the running code behaves correctly or has not been prompt-injected at the data layer — attestation covers the environment, not the intent expressed through legitimate inputs. And it introduces the verifier and its reference values as trusted components; a mesh must protect and correctly manage those, or the root of trust becomes the single point of failure. Attestation raises the forgery bar dramatically; it does not make claims about behavior true.

Signed provenance: making the history of data checkable

Many of the most damaging mesh failures are not about who is running what, but about where a piece of data came from and what happened to it. An agent asserts this record was read from an authorized source and already sanitized. If the next agent believes it, poisoned or unsanitized data flows onward under a false clean bill of health — precisely the propagation risk that makes a single compromise a mesh-wide incident. Signed provenance addresses this by attaching to each data artifact a signed, tamper-evident record of its origin and the transformations applied to it, so a receiver can verify the history rather than trust the assertion about it. Each producing agent signs the step it performed and links it to the prior step, forming a chain of signed statements a verifier can walk back to a trusted origin.

The property that makes provenance useful is non-repudiable attribution of each step: because every transformation is signed by a key bound to a verifiable identity, no agent can later deny a step it performed, and no agent can silently insert or alter a step without breaking a signature. This turns already sanitized from an assertion into a checkable claim — the receiver verifies that a sanitization step, signed by an agent authorized to perform it, actually appears in the artifact's history. The limitation, stated honestly, is that provenance attests that a step was performed and by whom, not that the step was performed correctly; a compromised sanitizer can sign a sanitization it botched. Provenance is therefore most powerful when paired with attestation of the producing agents and with the trust and delegation disciplines that bound what a compromised producer can do. It closes the where did this come from gap that identity alone cannot.

Zero-knowledge: proving a claim without revealing the basis

Some claims are hard to verify because the evidence that would prove them is itself sensitive. An agent may need to prove it holds a credential, satisfies a policy, or knows a secret — without disclosing the credential, the underlying data, or the secret. This is exactly the problem zero-knowledge proofs solve. Goldwasser, Micali, and Rackoff (1989) defined an interactive proof system with three properties: completeness (a true statement can always be proven to an honest verifier), soundness (a false statement cannot be proven except with negligible probability), and zero-knowledge (the verifier learns nothing beyond the statement's truth). Ported to a mesh, this means an agent can convince a peer that a claim holds while leaking none of the private basis for it — a receiver gains certainty without the claimant surrendering a secret that would itself become a liability if shared.

The mesh relevance is sharp. Consider an agent that must prove it is authorized for an action whose authorization derives from sensitive attributes, or that its output satisfies a policy predicate over private data. A naive design would have the agent hand over the attributes or the data so the receiver can check — creating exactly the sprawl of over-shared secrets that widens the blast radius of any single compromise. A zero-knowledge proof lets the check happen without the sharing, minimizing what each agent learns and therefore what an attacker gains by compromising it. The honest caveats are that soundness is probabilistic (though the error is driven negligibly small) and that practical zero-knowledge systems carry real engineering and performance cost, so they belong where the stakes and the sensitivity of the evidence justify them — not as a default for every routine claim.

Designing a verifiable-claims discipline for a mesh

Assembling these mechanisms into a coherent discipline follows a few principles. First, default to verify, not trust: every claim that gates a consequential action must carry evidence a receiver checks, and the receiver rejects claims that arrive as bare assertions. Second, match evidence to stakes along the spectrum — signatures for low-stakes claims, attestation where environment integrity matters, provenance where data history matters, zero-knowledge where the evidence is itself sensitive. Third, verify locally: the receiver runs the verifier itself rather than delegating the check to the claimant or an unverified third party, because a check performed by the party being checked is no check at all. Fourth, bind claims to verifiable identities so that every piece of evidence is non-repudiably attributable.

The discipline composes cleanly with the rest of a mesh trust decision. Identity and capability answer who may act; reputation estimates whether they behave; delegation bounds how authority propagates; and verifiable claims let a receiver check the substance of what it is handed at each step. Together they shift a mesh from a network where belief flows on standing to one where belief is earned by evidence at every hop. The residual, stated plainly, is that verification checks the claim as presented, not the entire causal history of the claimant's cognition — a perfectly attested, well-provenanced, zero-knowledge-proven claim can still encode a decision a compromised agent made within its legitimate scope. Verifiable claims raise the cost of lying to the point where forgery is harder than honesty; they are the evidentiary backbone of mesh trust, not a guarantee of correct intent.

function accept_claim(claim, evidence):
    # 0. bare assertions are rejected outright for consequential actions
    if evidence is None:
        return REJECT("unverifiable assertion")
    # 1. attribution: evidence signed by a verifiable identity
    if not signature_valid(evidence, identity_of(claim.claimant)):
        return REJECT("bad or missing signature")
    # 2. match mechanism to the claim's stakes + sensitivity
    need = evidence_policy(claim.action_stakes, claim.evidence_sensitivity)
    if need == ATTESTATION and not attestation_matches_reference(evidence):
        return REJECT("attestation mismatch")
    if need == PROVENANCE and not provenance_chains_to_trusted_origin(evidence):
        return REJECT("broken provenance")
    if need == ZK_PROOF and not zk_verify(evidence, claim.statement):
        return REJECT("proof failed")
    # 3. verify LOCALLY — never delegate the check to the claimant
    return ACCEPT

Limits and honest caveats

A verifiable-claims discipline is powerful but bounded, and rigor demands naming the boundaries. Every mechanism here relocates trust rather than eliminating it: signatures trust key management, attestation trusts a hardware root and the verifier's reference values, provenance trusts the correctness of each signed step, and zero-knowledge trusts a cryptographic assumption and a correct implementation. A mesh does not escape trust; it concentrates trust into a small number of well-scrutinized roots that are far easier to protect than a diffuse assumption that every agent is honest. The engineering task is to make those roots few, hardened, and monitored — and to treat their compromise as the catastrophic event it would be.

Two residuals deserve explicit statement. First, verification checks the claim as presented; it cannot certify that an authorized, attested agent formed the claim through uncorrupted reasoning, because a compromised agent can produce a truthful-looking, fully-evidenced claim that encodes a malicious in-scope decision. Verifiable claims defeat forgery and tampering; they do not defeat a legitimate-but-manipulated author. Second, the mechanisms carry real cost — key infrastructure, attestation services, proof computation — so a mesh must apply them proportionately, reserving the strongest evidence for the claims whose falsehood would cause the most harm. The correct posture is not to prove everything, but to make every consequential claim carry evidence commensurate with its stakes, and to pair verification with the containment mechanisms that assume some checks will eventually be beaten.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

claim_evidence:
  low_stakes_open:        { require: signature }
  high_stakes_open:       { require: [attestation, provenance] }
  low_stakes_sensitive:   { require: signature, disclose: minimal }
  high_stakes_sensitive:  { require: zk_proof }
defaults:
  bare_assertion: reject          # never act on an unverifiable claim
  verify: local                   # receiver runs the verifier itself
  bind_to_identity: required      # evidence signed by a verifiable identity

# bare assertion for a consequential action must be rejected
assert accept_claim(claim(action="delete", stakes=HIGH), evidence=None) == REJECT

# tampered signature must be rejected
bad = sign(evidence(...), key=WRONG_KEY)
assert accept_claim(claim(action="read", stakes=LOW), bad) == REJECT

# high-stakes claim needs attestation matching reference values
ok_att = attest(image=REFERENCE_IMAGE)
assert accept_claim(claim(action="deploy", stakes=HIGH), ok_att) == ACCEPT
assert accept_claim(claim(action="deploy", stakes=HIGH), attest(image=UNKNOWN)) == REJECT

# sensitive high-stakes claim needs a valid zero-knowledge proof
assert accept_claim(claim(action="payout", stakes=HIGH, sensitive=True), zk_proof(valid=False)) == REJECT

Glossary

Verifiable claim

A statement accompanied by evidence a receiver can check without trusting the claimant's honesty.

Claim / evidence / verifier

The triad of an asserted statement, the unforgeable data backing it, and the procedure that decides accept or reject.

Attestation

Evidence, ideally hardware-rooted, that binds a claim to a measured property of the claimant's environment such as its exact code image.

Attester / verifier / relying party

The three attestation roles: who makes the claim, who checks it against policy, and who acts on the verdict.

Signed provenance

A tamper-evident, signed record of a data artifact's origin and transformations, letting a receiver verify its history.

Zero-knowledge proof

An interactive proof that convinces a verifier a statement is true while revealing nothing beyond its truth (Goldwasser, Micali & Rackoff, 1989).

Completeness / soundness / zero-knowledge

The three defining properties: true statements are provable, false ones are not (except negligibly), and the verifier learns nothing else.

Root of trust

The small, hardened component — key store, hardware, or reference values — that a verification scheme ultimately depends on.

References

1. Goldwasser, Micali & Rackoff, The Knowledge Complexity of Interactive Proof Systems (SIAM J. Comput., 1989)
2. SPIFFE — Secure Production Identity Framework For Everyone (CNCF)
3. IETF RFC 8693, OAuth 2.0 Token Exchange (2020)
4. NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
5. OWASP Agentic Security Initiative, Agentic AI Threats and Mitigations (2025)
6. OWASP Top 10 for LLM Applications (2025)
7. MITRE ATLAS (Adversarial Threat Landscape for AI Systems)
8. NIST SP 800-207, Zero Trust Architecture (2020)