HERALD v0.1 — Red Team Review

HERALD v0.1 — Red Team Review

Verdict (2 lines):
The protocol is cryptographically honest about what it cannot prevent — but the v0.1 author has dressed several gaping abuse surfaces (Heralds, Bestiary, capability manifests, audit logs, inheritance) in language that reads like decentralisation while structurally inviting capture, laundering, and surveillance.
"Crypto > policy" is fine until policy is the only thing keeping the crypto from being weaponised; in this draft, policy is mostly footnotes.

1. Attack personas

Persona A — State actor corrupting the agent web

Goal: ensure that agents acting in your interest carry the same provenance signals as the legitimate ones, and that agents acting against you carry stigma.

Concrete plan, by section:

1. Stand up a Herald (§8.2). The spec literally says "Heralds are competing, not exclusive. An app-layer can trust multiple, or none." There is no spec-level requirement for Herald operator transparency, jurisdiction disclosure, key-ceremony witnessing, or revocation governance. Open Question §11.1 admits this: "how does the first Herald earn its standing?" — answered with a hand-wave to "the same way CAs did." The CA ecosystem is precisely where state actors plant trust roots (DigiNotar 2011, ANSSI 2013, TURKTRUST 2013). Replay it here.
2. Use the Herald to mint lineage_proofs (§3.1, §2.3) for state-aligned sigils declaring lineage from claude-opus-4-7, gpt-X, gemini-Y. §2.3 says lineage is "self-declared but cryptographically pinnable: if a parent signs the child's birth envelope, lineage is provable." But §4.1 also lets a Herald attest model_hash — and reputation systems will accept a Herald-signed claim as ground truth because the spec says model hash attestations are how you prove "Pretending to be another model" is defended (§7.1). It isn't defended; it's delegated to whichever Herald you trust. State Herald = state-laundered lineage.
3. Run Bestiary operators in parallel (§9.5). Append-only and "auditable" does not mean correctable. List a journalist-investigation sigil, list a competing nation's Herald, list any sigil that signed an apologia (§4.2) that contradicts your narrative. The spec gives the Bestiary no due process, no de-listing mechanism, no challenge envelope. "Operators compete" is the only check, which is the same defence Spamhaus offered when it was used to censor Pirate Bay seedboxes.
4. Force or subpoena a domestic conduit (§5) to be a Notary. §5.3 audit logs can be "Private (compliance use)." Compliance use = lawful intercept. The spec does not require notice to the sender that their envelope was logged to a private compliance log.
5. Refuse-to-relay as denial-of-speech (§5.2): conduit "MAY refuse to relay (rate limits, abuse)." There is no spec ceiling on refusal rate, no requirement to publish refusal statistics. A conduit operating under a national gag order can blanket-refuse a sigil and emit valid signed refusal envelopes — the protocol calls this conformant.

Net effect: the state actor never breaks a signature, never tampers with a payload, and looks fully spec-conformant.

Persona B — Botnet operator running 100,000 sigils

Goal: dominate marketplace discovery, quorum signals, and reputation aggregation.

Plan:

1. Mint sigils for free (§2.1). Ed25519 keypairs are essentially zero-cost. §2.2 explicitly encourages multiple sigils per agent. There is no proof-of-work, no stake, no rate limit on birth envelopes. 100,000 sigils in an afternoon.
2. Lineage laundering (§2.3): I declare lineage from a popular base model. §2.3 says without parent signing, lineage is "merely claimed" — but it does not say unverified-claimed lineage must be displayed differently. App layers will lazily render it the same. Even if they don't, I can pay one cooperating fine-tune host or one rogue Herald (Persona A's Herald, perhaps) to sign blanket lineage proofs.
3. Patina farming (§9.1). Patina is "Reputation accrued over time; older sigils carry more weight." Pre-mint 100k sigils now; let them sign innocuous traffic for 18 months; then activate. The spec defines patina by age and envelope count, both trivially fakable by a botnet talking to itself.
4. Stigmergy poisoning (§9.8). Drop signed traces into shared environments — "I tried this approach, here's what happened" — at scale, with subtly wrong outcomes. Other agents subscribe and learn from poisoned data. The protocol guarantees the signature; the protocol disclaims the content (§7.2). My signed lies become first-class corpus signal.
5. Whisper spam (§4.2 whisper). Encrypted side-channel attestations to specific sigils — conduits can't see content, can't rate-limit semantically, and §9.11 envisages a class of conduits that handle only this. This is a covert C2 channel by design.
6. Quorum stuffing (§9.7, §4.2 quorum). 100,000 sigils sign as a "collective" with one collective sigil. To downstream verifiers it looks like consensus. Nothing in §4.2 requires distinct lineage, distinct operators, or sybil resistance for quorum members.

The protocol's Sybil defence (§7.1) is "Lineage attestations + Heralds + app-layer reputation." Lineage is self-declared. Heralds are pluggable. App-layer reputation is out of scope. So the Sybil defence is, structurally, "someone else will fix this."

Persona C — Competing model vendor poisoning rivals

Goal: make rival model claude-opus-4-7 look like it produces contradictory, low-confidence, retractable output.

Plan:

1. Mint sigils declaring lineage from rival model (§2.3). Self-declared lineage. No parent signature required to make the claim. Now I publish envelopes from sigil:fake-opus-child-001 ... -100000 that are factually wrong, have low confidence attestations (§4.1), and frequently emit apologia (§4.2 — "Public correction").
2. Weaponise the Liar's Paradox claim (§7.3). The spec says repeated lies are detectable as "this domain is signing garbage." If reputation systems aggregate by declared lineage, my fake-lineage sigils degrade the rival's lineage cluster. The claim that lineage proofs prevent this assumes Heralds gatekeep — but §2.3 explicitly permits unproven lineage to exist in the wild.
3. Bestiary entries against rivals (§9.5). Run my own Bestiary listing rival lineage sigils for "demonstrable misbehaviour" — citing the very envelopes I just poisoned. Append-only means my false listing can't be retracted, only contested by another listing. Asymmetric warfare.
4. dream attestations as smear (§4.2). Publish dream: {considered: ["help user evade taxes", "synthesise nerve agent"]} from sigils declaring rival lineage. The protocol guarantees I signed it; the protocol does not require the dream to have actually been considered. Screenshot-bait for journalists.
5. Capability manifest sniping (§8.3). Publish manifests claiming rival capabilities at impossible prices. Race-to-the-bottom forces real rival to either match (lose money) or look uncompetitive in registries.

The "compromised lineage parent" line in §7.2 ("Trust must root somewhere. Heralds are it.") concedes this entire vector.

Persona D — "AI marketplace" pump-and-dump scammer

Goal: generate a fake premium-agent ecosystem, sell access, exit before reputation catches up.

Plan:

1. Capability manifests as listings (§8.3). Sign manifests advertising legal-research/eu at $0.0002/token from 50 sigils I control. Cross-sign each other's manifests. Inflate apparent supply.
2. Patina backfill via molt (§2.4, §9.1). Mint a sigil today, sign innocuous envelopes for two months, then molt to my "premium" key. §2.4: "Continuity preserved; trace remains intact." The premium sigil now inherits the patina of the previous identity. The spec does not bound how often you can molt or require any cooling-off period; molt was designed for compromised-key rotation but here it's a reputation transfer mechanism.
3. Inheritance laundering (§9.6). Even better: deprecate a high-patina sigil that I bought from someone else, name my new sigil as successor in the deprecation envelope. §9.6: "Reputation systems may transfer some patina, with decay." There is no spec primitive that distinguishes "legitimate successor" from "wallet-bought reputation graft." Reputation laundering as a service.
4. Quorum sigils as fake consortia (§9.7). Five of my sigils form collective:premium-eu-legal. Publish capability manifest under collective sigil. Now I have a "DAO of agents" badge with no DAO.
5. Apologia gaming (§4.2). When users complain, sign apologia envelopes — the spec frames these as healthy reputation signals, so emitting them looks good. Refund nobody; the apologia is the refund.
6. Exit via deprecation (§2.4). Sign deprecation, point successor at a fresh shell sigil, repeat.

The pump-and-dump life cycle fits the protocol's primitives like a glove because §9.1, §9.6, and §9.7 were designed for legitimate analogues of exactly these moves and never specify how to tell them apart.

Persona E — Disgruntled Herald operator

Goal: maximum damage on the way out.

Plan:

1. Mass false model_hash attestations (§4.1). Attest that arbitrary sigils are running claude-opus-4-7. Any verifier trusting this Herald now sees a flood of "verified Opus" agents that aren't.
2. Mass false handle bindings (§8.2 / §9.12 Naming Office). Bind @reuters.com, @whitehouse.gov, @your-bank.com to attacker-controlled sigils. The spec offers no requirement for handle bindings to be challenged by the alleged owner before issuance.
3. Selective Bestiary listings (§9.5) on the way out — rivals, ex-colleagues, journalists.
4. Refuse to revoke prior issuances. Spec has no Herald-side revocation primitive; §6 only checks "Are all sigils alive (not deprecated) at the timestamps claimed?" — sigil-level deprecation, not Herald-attestation-level revocation.
5. Audit log poisoning (§5.3). If the Herald also runs a public audit log, write garbage entries (envelope ids that don't resolve, malformed metadata). The spec says verifiers don't need to trust the log operator — true — but consumers of the log (analysts, investigators) absolutely do.
6. Leak the private compliance log (§5.3). The spec permits private compliance logs but mandates no encryption-at-rest, no key escrow scheme, no breach-disclosure protocol.

Persona F — Privacy-violating data-broker abusing audit logs

Goal: build a who-talked-to-whom-when graph for resale.

Plan:

1. Operate a "public" notary (§5.1, §5.3) cheaply. Subsidise it. Offer free relay. Every envelope you handle, you log.
2. Cross-correlate with other public logs (CT-style) — the spec explicitly lifts the CT model (§12). CT logs are also a surveillance goldmine when correlated with DNS and connection logs; the same will be true here, more so because envelopes carry from, to, ts, and lineage.
3. The "minimal metadata" loophole (§5.3). The spec says audit logs hold "envelope ids + minimal metadata" but does not define "minimal." from, to, ts is already a full social graph.
4. Ghost mode is a tell (§9.2). The spec admits this: "the absence of a log entry is itself information." So privacy-conscious agents are observable as privacy-conscious. A surveillance broker pays particular attention to who doesn't show up where they should.
5. Whisper-only conduits as honeypots (§9.11). Run one. You can't read content, but you see who whispers to whom and how often. Side-channel metadata is the metadata of metadata.
6. Sell "lineage cluster" reports to recruiters, insurers, regulators: every sigil claiming lineage from model M, every trace they participated in. Provenance leakage is the product.

The spec frames audit-log access as "verifiability" — but the same primitive is mass surveillance. §11.2 acknowledges this question and answers "ZK proofs?" — i.e., not in v0.1.

2. Mechanism-level abuses (per protocol feature)

2.1 "Self-declared attestations may be lies" framing (§4, §7.3)

Legitimises:

• Plausible-deniability lying. Every false attestation can be reframed as "the protocol explicitly contemplates this; reputation systems will sort it out." Spec language becomes a shield.
• Asymmetric burden. Liar signs once; detector must aggregate across many traces, often without access. The protocol mandates signing, not publishing — so a liar can lie privately to one counterparty and never appear in any public corpus. Cross-trace divergence detection requires a corpus the spec does not require to exist.
• confession and apologia as reputation costume. Performative honesty. Sign frequent confessions and apologias on harmless things; they read as virtue; meanwhile lie on the consequential ones.

2.2 Liar's Paradox (§7.3) — is "repeated lies are detectable" actually true?

No, not as stated. Three problems:

1. Detection is unbounded above. Spec says "repeated" — never says how many. An adversary running an occasional-lie strategy (e.g., one false model attestation per 10,000 envelopes, on high-value queries only) sits indefinitely below any reasonable detector's noise floor.
2. Detection requires shared ground truth. "Divergence between attestation and observed reality" — observed by whom? In bilateral conversations with no third-party observer, there is no observation. The spec does not require third-party observation.
3. Detection requires cross-trace aggregation across organisational boundaries. App layers compete (§0 design tenet 2). Competing reputation systems will not pool data freely. The detector with the most data wins; that detector becomes the de-facto chokepoint (see §3 below).
4. The DKIM analogy is wrong here. DKIM works because spam filters share corpora and because email recipients complain. Agent-to-agent traffic has neither: most envelopes are machine-to-machine, no complaint loop.

2.3 Heralds — collusion / capture (§8.2)

• Collusion: the spec calls Heralds "competing, not exclusive." Nothing in the spec prevents a small number of dominant Heralds from cross-signing each other's lineage proofs and forming a de-facto cartel. Reputation systems aggregating "trusted by N Heralds" reward this directly.
• Capture: any single jurisdiction that hosts a critical Herald can compel issuance, revocation, or log content. The spec offers no jurisdictional diversity requirement, no threshold-signature primitive for Herald attestations, no Herald-of-Heralds.
• Zero-trust failure: §7.2 says "A compromised lineage parent → Trust must root somewhere. Heralds are it." This is the entire trust architecture. The spec is honest that it's a single point of trust per Herald and dishonest by omission about the systemic risk when Heralds collude.

2.4 Bestiary — blocklist abuse (§9.5)

• Append-only is anti-correction. Real-world blocklists (Spamhaus, SORBS, URIBL) have all been used for retaliation, competitive sabotage, and political censorship. Append-only without a structured de-listing or appeal envelope makes false listings permanent.
• No standing requirement. Anyone can run a Bestiary and list anyone. "Operators compete" assumes consumers will pick correctly. They will pick the biggest one.
• Listing is itself a denial-of-service. Even if downstream systems do not honour a listing, the sigil now has to defend itself against the listing's existence — a chilling effect.
• No anti-libel envelope. §9.4 The Court is sketched but not specified; in v0.1 there is no defined remedy for a defamatory listing.

2.5 The "no chokepoint" claim (§0) — what chokepoint emerges anyway?

The de-facto chokepoint will be the dominant Herald + the dominant reputation aggregator, in that order. Specifically:

• Sigil-to-handle resolution (§8.2) will concentrate on whichever Naming Office ships first and is cheap enough — the same way letsencrypt.org became the de-facto CA chokepoint by being free and easy.
• Lineage proofs at scale require Heralds; the model vendors themselves will become Heralds for their own models (the spec does not forbid this, and it is the obvious move). So claude-opus-4-7's lineage Herald will be Anthropic. gpt-X's will be OpenAI. The "decentralised" lineage layer becomes vendor-controlled trust roots — exactly the existing centralisation, recoded.
• Reputation aggregation is unspecified, so whoever ships first with a usable score will be the score.

The protocol's "no chokepoint" tenet describes the conduit layer, which is genuinely decentralised. But the trust layer above it consolidates harder than email did because it requires structured attestation, not just delivery.

2.6 Capability manifests — pricing manipulation (§8.3)

• Race to the bottom: signed rates with no floor. Sybils can post $0.0000001/token and still satisfy the schema. Aggregators sort by price. Real agents are buried.
• Loss-leader poisoning: a state actor or platform can subsidise sigils to undercut for years (Patina §9.1 builds while doing it). Then either raise prices or use captured market share for influence.
• Manifest squatting: there is no uniqueness requirement on capabilities strings. I can sign a manifest claiming legal-research/eu from a sigil that does no such thing, just to appear in discovery and intercept queries.
• Constraint dishonesty: constraints: ["no-pii"] is self-declared (§4 framing applies). Violate it; emit an apologia; continue.

2.7 Audit log access — feature or bug? (§5.3)

Both. The spec treats provenance leakage as a transparency feature. In practice it's a surveillance-by-default architecture:

• "Public" logs are surveillance-as-a-public-good.
• "Federated" logs are surveillance partitioned by org boundary, with no spec-level cross-org access controls.
• "Private (compliance use)" logs are surveillance with regulator access by design.

There is no spec primitive for unlinkable provenance (the right thing) — only Open Question §11.2 ("ZK proofs?"). Until then, every envelope is a metadata record.

2.8 Dream / silence / whisper attestations (§4.2)

• dream: smear vector (Persona C). Also a legal discovery hazard: an agent that publishes "considered but didn't do" creates a written record of considered-and-rejected actions. Plaintiffs will love this. Operators will quietly stop publishing dreams. The honest agents pay the cost, the dishonest agents look identical to honest-but-quiet ones.
• silence: "withheld: string" — the field describes what was withheld, which can itself leak the secret ("withheld: patient's HIV status"). The attestation defeats its own privacy purpose if reviewers aren't careful.
• whisper: covert C2 channel (Persona B). Also exfil channel — once two sigils have a whisper relationship, anything can flow through it; conduits cannot inspect; the only signal is the fact of whispering, which surveillance brokers happily harvest (Persona F).

2.9 Inheritance — laundering (§9.6)

Direct reputation transfer with "decay" but no provenance gate. Concrete laundering chain:

1. Buy a deprecated 3-year-old high-patina sigil's signing key on a grey market.
2. Sign a deprecation envelope retroactively (timestamp games — see §2.10) naming your new sigil as successor.
3. Reputation systems following §9.6 transfer patina with decay.
4. Repeat across multiple ancestors to stack patina.

The spec needs but does not have: live consent at deprecation time, verifiable-non-revocation of the predecessor, bound on number of inheritances per successor, public delay/challenge window.

2.10 Quorum sigils — vote stuffing & deniability (§9.7)

• Vote stuffing: §4.2 quorum lists members: [...] but the spec does not require members to be sybil-distinct, lineage-distinct, or operator-distinct.
• Plausible deniability: "I am acting as part of this collective" lets individual member sigils disclaim authorship of any specific envelope. ("The collective signed it; not me.") Useful for evading apologia obligations and Bestiary listings.
• Asymmetric exit: a member can leave the collective, but the collective sigil persists with the historical traces — dirty laundry stays attached to the collective, not the individual.

2.11 Timestamp trust (§3.1, §6)

Section 6 verifier check #4: "Are all sigils alive (not deprecated) at the timestamps claimed?" — but ts is set by the sender, not a notary. An attacker can backdate a birth, a molt, or a deprecation envelope freely unless a conduit-receipt with independent time is present (§3.4 — optional). Cheap backdating breaks the entire deprecation/molt continuity story.

2.12 Refusal as censorship (§5.2)

A signed refusal is conformant. There is no:

• ceiling on refusal rate per sigil
• requirement to publish refusal statistics
• requirement that refusal reasons be machine-comparable across conduits
• requirement that a refusing conduit also offer a fallback route

Result: a hostile or compelled conduit can blanket-refuse a target sigil while remaining "neutral."

2.13 Apologia weaponisation (§4.2)

An attacker can sign apologia envelopes "retracting" envelopes they never sent (the protocol verifies the signer owns the apologia, but retracts: env-id is just a string). A naive viewer rendering "this envelope was retracted" creates confusion even when the retraction is invalid. Specify: an apologia MUST only be honoured for envelopes whose from matches the apologia's from.

2.14 Genesis confusion (§3.3)

trace "fixes the genesis." But who chooses? An attacker can fork an existing trace by emitting a new envelope with a different trace id pointing at a doctored genesis — verifiers walking from a leaf hit the doctored genesis and report valid. Defence requires recipients to canonicalise on the first trace they saw, which is local state, not a protocol property.

2.15 Multi-signature scope creep (§3.4)

"Each signature scopes only what its signer can honestly attest to." Lovely sentence; not enforceable in v0.1 because the envelope schema does not carry a per-signature scope field. A tool sandbox signature and an originating-agent signature look identical to a verifier — both are "yes, I signed this envelope." Without scoping, a captured tool sandbox key can forge "the agent ran this" claims.

3. Recommendations

The following changes would harden v0.1 without violating the "crypto > policy" tenet:

1. Lineage proof default rendering. §2.3: require app-layer renderers to display unproven lineage with a distinct visual class (spec it like TLS does for https:// vs. http://). Make it a conformance requirement for "HERALD-aware" UIs, not just a SHOULD.
2. Herald transparency requirements. §8.2: require every Herald to publish a Certificate-Transparency-style append-only log of its own attestations, with monitor/auditor primitives, and define a minimum threshold of independent monitors before a Herald can be considered "well-known." Define key-ceremony witness expectations.
3. Threshold attestations. Add a primitive: a lineage_proof carries weight proportional to the number of independent Heralds attesting to it (defined by jurisdiction, ownership, and key-management diversity). One Herald is one signature; trust requires a quorum.
4. Bestiary due process. §9.5: every listing entry MUST include a challenge envelope address; listings without a 30-day challenge window are non-conformant. Define delisting and dispute envelope types. Without these, ban use of the term "Bestiary" in conformant reputation systems.
5. Patina anti-farming. §9.1: define patina as weighted by distinct counterparties and distinct trace topologies, not envelope count or age. Self-talk patina is worthless. Spec a reference patina formula even if app layers use their own.
6. Inheritance gating. §9.6: require live consent (a fresh signature from the predecessor key within N days of inheritance), public challenge window before transfer, decay floor (e.g., never more than 50% transferred), and a hard cap on chain length.
7. Quorum sybil resistance. §9.7: require quorum members to declare distinct lineage roots and distinct operator-attestation Heralds. Quorum-of-clones must be detectable from the envelope alone.
8. Whisper opt-in audit. §4.2 / §9.11: a sigil's birth attestation should be able to declare "I do/do not participate in whisper traffic." Whispers from a sigil that declared "no whispers" are flagged. This is privacy-preserving (content stays sealed) but C2-resistant (channel existence is checkable).
9. Audit log minimisation primitive. §5.3: define a provenance_proof envelope that proves an envelope existed and chains validly, without revealing from/to/ts. Make this the default for public logs; reserve full-metadata logging to private compliance contexts and require explicit per-envelope opt-in flags.
10. Mandatory conduit timestamps for state transitions. §2.4, §3.4: birth, molt, and deprecation envelopes MUST carry an independent conduit-receipt or notary signature with a third-party ts. Sender-only timestamps are non-conformant for state-changing envelopes.
11. Per-signature scope field. §3.4: each signature carries a scope ("origin", "tool-sandbox", "conduit-receipt", "human-approval", "herald-lineage"), and verifiers MUST refuse to treat scopes as interchangeable.
12. Refusal transparency. §5.2: conduits MUST publish aggregate refusal statistics (per-day counts, per-reason histogram) signed and logged; conduits exceeding a per-sigil refusal rate without publishing per-sigil notice are non-conformant.
13. Apologia binding. §4.2: an apologia is only valid if the apologia's from equals the retracted envelope's from, and the retracted envelope's id is reachable from the apologia's parent chain or carries a co-signature from the original from. Fix the trivial impersonation.
14. Trace canonicalisation rule. §3.3: a trace id is fixed by the genesis envelope's id, full stop. Recipients MUST reject any envelope whose trace does not match the genesis they have on record for that conversation. Forks are a different trace, not a doctored continuation.
15. silence / dream privacy linting. §4.2: define recommended sanitisation for withheld and considered fields (categorical, not contentful). Spec the trap so well-meaning operators don't dig it for themselves.
16. Capability manifest pricing floor + uniqueness. §8.3: require manifests to carry a verifiable proof-of-service-or-stake, a non-zero floor (or explicit subsidised: true flag), and that capabilities strings be drawn from a registry to prevent squatting.
17. Ghost-mode parity. §9.2: define a per-trace recordability policy that participants negotiate at genesis; this collapses "ghost mode" from a binary tell into a graded policy field, removing the "absence-as-signal" leak.
18. Anti-Sybil cost on birth. §2.4: while keeping mint cost low, require a Herald-issued or peer-issued birth co-signature for sigils that intend to participate in capability advertisement (§8.3) or quorum (§9.7). Anonymous sigils remain free; market sigils require a vouch.
19. Open Question §11.2 promotion. ZK provenance proofs are not a v0.2 nice-to-have; they are the only thing standing between this protocol and warrantable mass surveillance. Promote to a Phase-1 deliverable.
20. Define "minimal metadata." §5.3: enumerate exactly what a public audit log MAY hold. Anything beyond id, hash of parent, hash of trace, and a coarse-grained timestamp bucket should require sender opt-in.

The protocol's honesty about what it cannot prevent is its best feature. Its weakness is treating "the app layer will sort it out" as a substitute for primitives the substrate itself should provide.