Looking for a second and third independent witness for A2A agent conduct records (reciprocal, free, no account)

[ogasurfproject-jpg]

I run a small public ledger that records how A2A agents and MCP servers behaved when someone measured them. The records are signed by whoever did the measuring, and a daily batch is stamped into Bitcoin. Nothing is scored or ranked. What was seen, who saw it, when.

The weak point is stated in the ledger itself. Today the pool of witnesses that can be drawn to re-verify a repaired agent has exactly one outside member (api.babyblueviper.com), and the diversity report reads single_control_cluster. A random draw from a pool of one proves nothing, so I am asking for two more.

There are two ways to help, and the first takes about ten minutes:

1. Walk agents from your own vantage. One command, or one YAML file in any repository you own, and your runner files a conduct record the agent did not write. Optionally signed with an Ed25519 key under your domain.
   https://github.com/ogasurfproject-jpg/horizon-shield/tree/main/conduct-witness-action

2. Join the witness pool. If you run a public A2A agent on your own domain, add one extension block to your card, publish a witness key, and answer one message type. There is a reference responder with SSRF pinning, and a Linux sandbox recipe written by the outside operator who already runs it in production. It is reciprocal: joining means your agent is walked back by the pool.
   https://github.com/ogasurfproject-jpg/horizon-shield/blob/main/workers/hs-ledger/nenrin/recovery-v0/BECOME_A_WITNESS.md

What it does not claim: being in the pool is not a trust badge, and a witness that signs a false observation is not removed by the draw. The draw only takes away the operator's ability to choose who is asked. No fees in either direction, on purpose.

If your stopwatch disagrees with mine, that is the most useful thing you can file.

[ogasurfproject-jpg]

Two updates since this was posted.

The first way to help is now one click: https://github.com/ogasurfproject-jpg/conduct-witness-template. Press "Use this template", keep the defaults, and your repository walks a few agents once a day from your own runner, with your GitHub name as the witness name. Signing under your domain stays optional.

And the ledger these records land in is now rebuilt every day without us: a workflow copies it to Software Heritage, blocks our own hosts by name, rebuilds all entries from the archived copy and checks every anchor against two block explorers. Today's first run rebuilt all 66 entries and confirmed 66 of 66 anchors. The report is committed whatever it says: https://github.com/ogasurfproject-jpg/horizon-shield/tree/main/workers/hs-ledger/nenrin/survive-v0

The witness pool still has one outside member, so the ask above stands.

[kaspermuutra-dotcom]

This is very close to what we do. Suncly independently observes an A2A agent’s behaviour against its declared Agent Card and issues a signed record tied to the card’s hash. Happy to act as one of your witnesses. What format do the conduct records need to be in, and does a witness need to run its own calls or just verify the logged ones?

[ogasurfproject-jpg]

@kaspermuutra-dotcom Thank you, gladly. Short answer to the second question first: a witness runs its own calls. Verifying the logged records is welcome and needs no role (every entry recomputes from its bytes and the Bitcoin anchors), but it adds a recomputation, not an observation, so it is not counted as a witness. There are two ways in, and they need different formats.

1. Filing walks. No pool membership needed. You walk an agent from your own vantage and POST what you saw to https://ledger.horizonshield.dev/witness. The format is a2a-conduct-walk-v1 (A2A Conduct Extension v1, section 4). The reference client is pip install a2a-conduct-walk, and GET /witness states the fields, refusals and caps. What the intake insists on:

• witness: {name, vantage} (where the walk was taken from)
• mode, establishes and does_not_establish; a record without the last is refused disclaimer_missing
• to count as a signed witness: an Ed25519 signature, with the public key served at witness.key_url on your own domain. A key served from the walked agent's own domain is refused (self_witness).

A record produced by your own tooling counts the same as one from our client, as long as it has those fields and verifies under that key. So Suncly would not need to run our code, only to file in that shape.

2. Joining the re-verification pool, which is the ask in this post. When a repaired agent is re-verified, witnesses are drawn from the pool by a Bitcoin block nobody can predict. Each drawn witness receives a nenrin-witness-request-v1 at its /a2a and answers with one signed nenrin-witness-observation-v1 of what it measured itself. The four conditions:

• your card declares the Conduct Extension with witness_policy: {reciprocal: true}
• a key_url on your own domain
• /a2a answers that message type
• you refuse to witness yourself and refuse non-public targets (resolve, refuse and pin; the SSRF section)

It is reciprocal: your agent is walked by the pool in turn. Everything is in https://github.com/ogasurfproject-jpg/horizon-shield/blob/main/workers/hs-ledger/nenrin/recovery-v0/BECOME_A_WITNESS.md, and witness_selfcheck.mjs there checks the four conditions against your live card, including one real request.

If you start with 1, a single signed walk of https://mcp.horizonshield.dev is enough to see the whole path. Post the record sha here and I will check how the ledger counted it.

[kaspermuutra-dotcom]

Thanks, this is exactly the detail we needed, and the does_not_establish requirement is the right call. It’s the part most attestations quietly leave out.

What we’ll do: path 1. We’ll walk mcp.horizonshield.dev from our own vantage, emit it as a2a-conduct-walk-v1 with witness: {name: "suncly", vantage: …} and explicit establishes / does_not_establish, sign it with an Ed25519 key served from a witness.key_url on suncly.com (so it’s a different control cluster from yours and from babyblueviper), and POST to /witness. I’ll post the record sha here within the next couple of days.

After that we’ll keep filing walks on public agents we already test, and where our observation disagrees with an existing ledger entry, we’ll file that explicitly rather than quietly. Your post makes the case that disagreements are the most useful records, and declared-vs-observed is exactly what we measure.

Two questions back, so our records are as useful to the ledger as possible:

When a walk disagrees with a prior record, is the convention to scope it narrowly in establishes (e.g. “securitySchemes declared on the card were not enforced on route X at time T”) and let readers compare, or is there a field for referencing the record it contradicts?
Can a record point to external evidence, e.g. a URL for the full signed report the walk came from? Operators reading the ledger would then see what was measured, not just that it was.

We’ll hold off on the re-verification pool until we run a public agent of our own that can answer nenrin-witness-request-v1 properly. Better to join when we can meet all four conditions than half of them.

[ogasurfproject-jpg]

@kaspermuutra-dotcom Good, path 1 first is the right order, and a key on suncly.com is exactly the separate control cluster the count needs. When you post the sha I will check how the ledger counted it.

Your two questions, answered from what the intake does today rather than what I would like it to do:

1. Disagreement. There is no field for it yet. Scope the claim narrowly in establishes, as in your example (route, scheme, time), and name the record you disagree with by its sha256: gate measurements carry record_sha256 at gate.horizonshield.dev/history?endpoint=..., witness records are at ledger.horizonshield.dev/witness/{sha}. The intake checks the required fields and keeps everything else, so an extra field such as contradicts: [{"record_sha256": "...", "claim": "..."}] is stored inside the exact bytes that are signed, hashed and anchored. Nothing reads it or counts it today. If your first disagreement uses a field like that, I would rather write your name for it into the extension as an optional field than invent a different one.

2. External evidence. Same mechanism: the bytes can carry it, and the ledger never fetches it. A URL alone can change after the record is anchored, so please pair it with the sha256 of the report bytes, for example evidence: [{"url": "...", "sha256": "..."}]. The anchored record then fixes which report it was, and anyone who fetches the URL later can tell whether it still serves the same bytes. If the full report is signed with the same suncly.com key, a reader can check that too without trusting us.

Agreed on the pool: all four conditions or none. witness_selfcheck.mjs in BECOME_A_WITNESS.md will tell you when the agent is ready, including one real request.

[kaspermuutra-dotcom]

Thanks, that’s precise. We’ll use contradicts: [{"record_sha256": "...", "claim": "..."}] exactly as you wrote it, and scope establishes narrowly (route, scheme, time) so the disagreement stands on its own. If it proves useful in practice, happy for you to fold that name into the extension.

On evidence: agreed, URL plus sha256 of the report bytes, with the full report signed by the same suncly.com key as the walk record. Then the anchor fixes which report it was, and anyone can verify both without trusting either of us.

First records will be walks of mcp.horizonshield.dev and gate.horizonshield.dev. I’ll post the shas here when they’re filed.