Bilateral signed interaction records as the trust primitive for A2A

[viftode4]

Summary

A2A has identity proposals, trust scoring proposals, audit proposals, and delegation proposals. They're all separate systems that need to be wired together. There's a simpler path: one data structure that handles all of them.

A bilateral signed interaction record is one JSON object, signed by both parties, recording what happened between two agents. Trust, reputation, audit trails, Sybil resistance, and delegation evidence all derive from the graph of these records.

Problem

The current proposal landscape for trust in A2A:

• Identity: Agent Cards, DID documents, OATR registry (Proposal: Agent Identity Verification for Agent Cards #1672, Running implementation of agent identity, delegation, and enforcement — addressing #1497, #1472, #1501 #1575, Agent Identity Layer: WTRMRK as a trust primitive for A2A agents #1712)
• Trust scoring: signal taxonomies, behavioral attestation (trust.signals[] extension: consolidated signal type specification #1628, Feature: Trust scoring extension for agent-to-agent delegation #1501)
• Audit: evidence envelopes, action receipts, hash chains (Cross-org, no shared AS: accountability layer for first-contact A2A transactions #1713, docs: add authorization, delegation & audit evidence extension proposal #1583)
• Delegation: scoped tokens, capability chains (RFC: Authorization layer for A2A AgentSkill invocations — capability token enforcement at skill boundaries #1716)
• Sybil resistance: token gating, vouching, manual review

Each one solves its own problem but they don't compose. An agent that wants identity, trust, AND audit needs to integrate 3+ separate protocols. And most of these rely on single-party attestation, where one entity reports what happened. If that entity is compromised or lying, the data is worthless.

Proposed solution

One record type. Both the requesting agent and the serving agent sign it.

{
  "type": "interaction",
  "public_key_a": "ed25519:abc...",
  "public_key_b": "ed25519:def...",
  "sequence_number_a": 42,
  "sequence_number_b": 17,
  "previous_hash_a": "sha256:...",
  "previous_hash_b": "sha256:...",
  "timestamp": 1743897600000,
  "transaction": {
    "task_id": "a2a:task/uuid",
    "action": "task_completed",
    "quality": 0.87,
    "skill": "code_review"
  },
  "signature_a": "ed25519:...",
  "signature_b": "ed25519:..."
}

Each record links to the previous one for both parties (like a personal chain per agent, no global ledger). What falls out of this:

Identity is the Ed25519 keypair. No registry required, works offline.

Trust scores are computed from the graph using NetFlow or MeritRank. An agent with 50 cosigned interactions across diverse counterparties has a verifiable track record. Graph topology catches Sybil rings automatically since fake identities cluster together with few external connections.

Audit trails are the records themselves. Both parties hold matching copies. EU AI Act Article 12 ready.

Delegation is a scoped record: agent A authorizes agent B to act on its behalf, with TTL bounds and depth limits. The delegation record is cosigned.

Sybil detection comes from graph analysis. Clustering coefficient, subgraph independence, connectivity diversity. Five fake agents rating each other stick out because they form an isolated cluster.

Negative reputation works because both parties signed. You can't fabricate a negative review since it requires the counterparty's signature. And you can't deny a bad outcome since the other party holds the same record.

The graph also powers trust-weighted agent discovery (same idea as PageRank, but over interactions instead of links), behavioral anomaly detection at runtime, and dispute resolution where both parties hold cosigned evidence a mediator can verify.

How this maps to existing A2A concepts

• AgentCard.trust_profile could include interaction_count, trust_tier, graph_metrics
• trust.signals[] from trust.signals[] extension: consolidated signal type specification #1628 gets a new type: cosigned_interaction_history
• Task completion in A2A could optionally produce a bilateral record as post-task evidence (complementing Cross-org, no shared AS: accountability layer for first-contact A2A transactions #1713 OBO envelopes)
• The verifiedIdentity work from Proposal: Agent Identity Verification for Agent Cards #1672 provides the identity layer; bilateral records provide the behavioral layer on top

Reference implementation

Built and running:

• Rust sidecar with 23 HTTP endpoints, gRPC, MCP server with 7 trust tools, ~500 tests
• Python SDK with 475 tests, @audited decorator, sidecar auto-download
• TypeScript SDK with 165 tests, zero deps
• 12 framework adapters including LangGraph, CrewAI, AutoGen, Google ADK
• Transparent HTTP proxy for zero-code integration

Live demo with 21 LLM agents in a full economy with trust-based hiring, quality verification, graduated sanctions, and 10 economic mechanisms running: http://5.161.255.238:8888

Source: https://github.com/viftode4/trustchain

Related issues

• Proposal: Agent Identity Verification for Agent Cards #1672 (identity verification): bilateral records complement Agent Cards with behavioral history
• trust.signals[] extension: consolidated signal type specification #1628 (trust signals): cosigned interaction history as a signal type
• Cross-org, no shared AS: accountability layer for first-contact A2A transactions #1713 (OBO accountability): bilateral records as the evidence primitive underneath OBO envelopes
• docs: add authorization, delegation & audit evidence extension proposal #1583 (closed, audit evidence): similar direction but unilateral; bilateral cosigning is the missing piece
• Running implementation of agent identity, delegation, and enforcement — addressing #1497, #1472, #1501 #1575 (APS implementation): bilateral records could be the evidence layer APS consumes
• [Protocol Question] Heartbeat-based agents: availability metadata and offline-first task handling #1667 (offline agents): bilateral records verify with just two public keys, no online dependency

Questions

1. Would cosigned_interaction_history fit as a signal type in the trust.signals[] taxonomy from trust.signals[] extension: consolidated signal type specification #1628?
2. Should post-task bilateral records be an optional extension to A2A task completion, or a separate protocol that references A2A task IDs?
3. Is there interest in test vectors for bilateral record verification that other implementations could use for interoperability testing?

[aeoess]

@viftode4 — this is serious work. The Rust/Python/TS implementation breadth, 500+ test suite, and the live 21-agent economy demo put this well beyond proposal stage. The bilateral signing primitive is the right foundation — unilateral attestation is the weak link in most trust proposals because a single compromised party can fabricate or suppress records.

Where this complements APS: APS handles authorization enforcement (delegation chains, gateway-side policy evaluation, 3-signature proof chains) but currently treats reputation evidence as opaque input. TrustChain's bilateral records could serve as a concrete evidence type feeding into APS's Bayesian reputation model. The mapping:

// APS reputation update currently takes:
update_reputation({
  agentId, principalId, scope,
  success: boolean,
  evidenceClass: 'trivial' | 'standard' | 'complex' | 'critical'
})

// With TrustChain bilateral records, the evidence becomes verifiable:
update_reputation({
  agentId, principalId, scope,
  success: boolean,
  evidenceClass: 'complex',
  bilateralRecord: {
    hash: 'sha256:...',
    counterparty_key: 'ed25519:def...',
    counterparty_signature: 'ed25519:...',  // proof the other party agrees
    quality: 0.87
  }
})

The bilateral signature converts a self-reported success/failure into a counterparty-verified outcome. That's a material upgrade to the mu/sigma update — a cosigned quality: 0.87 carries more weight than an unverified claim, so it should produce a larger sigma reduction (higher confidence) in the Bayesian update.

One stress test on Sybil resistance: You write that graph topology catches Sybil rings because fake identities cluster together with few external connections. This holds when Sybil nodes are cheaply created and interact mostly with each other. But what about colluding pairs — two real, externally-connected agents that cosign inflated quality scores for each other? They wouldn't form an isolated cluster because both have legitimate interaction histories with diverse counterparties. The bilateral signature proves both parties agreed on the quality score, but it doesn't prove the score is accurate.

NetFlow/MeritRank partially addresses this through flow-based trust propagation, but I'd want to see how the graph analysis handles the specific case of:

• Agent A and Agent B both have 50+ legitimate interactions with diverse counterparties
• A and B cosign 20 interactions between themselves with inflated quality scores
• The inflated scores don't form a cluster — they're embedded in otherwise healthy subgraphs

Does the MeritRank implementation detect this via edge weight anomalies (A↔B quality scores statistically diverging from A↔C and B↔D scores), or does it require a separate mechanism?

On your questions:

1. cosigned_interaction_history fits naturally as a signal type in trust.signals[]. It's the first signal type that carries bilateral cryptographic proof rather than unilateral assertion — worth flagging that distinction in the taxonomy.

2. Post-task bilateral records should be an optional extension to A2A task completion, not a separate protocol. The value is in the tight coupling: the record references the A2A task ID, the task's skill type informs the evidence class, and the task outcome maps directly to the quality field. A separate protocol would lose that context binding.

3. Test vectors for bilateral record verification would be immediately useful. APS could consume them as a reference for importBilateralEvidence() — if you publish a test vector suite, I'll implement the import path against it.

[pshkv]

Great thread. The bilateral-signature trust primitive is a strong base, especially when paired with inclusion proofs.

One practical collaboration proposal: publish a small adversarial fixture pack for trust updates.

• colluding-pair inflation case (externally connected nodes collude)
• replayed bilateral record
• delayed anchor publication
• contradictory quality claims across counterparties

If we can agree on expected outcomes (e.g., trust delta bounds + confidence decay behavior), implementations can compare behavior without forcing one scoring algorithm.

Happy to help draft neutral fixture JSON and expected invariants.

[aeoess]

@pshkv — yes. The adversarial fixture pack is exactly the right artifact for this stage.

Proposed format: each fixture is a self-contained JSON object with scenario, agents (keys + delegation chains), bilateral_records (the signed interaction data), and expected (trust delta bounds, confidence decay, detection flags). Implementations consume the fixture, run their scoring algorithm, and compare against expected within declared tolerances.

For the four cases:

1. Colluding-pair inflation — two externally-connected agents cosign inflated quality scores for each other. Expected: scoring algorithm detects statistical divergence between A↔B quality and A↔C / B↔D quality. Fixture includes 50+ legitimate interactions per agent plus 20 inflated mutual interactions.

2. Replayed bilateral record — same signed record submitted twice. Expected: second submission produces zero trust delta (idempotency) or explicit replay detection.

3. Delayed anchor publication — bilateral record with a timestamp gap between signing and on-chain anchoring. Expected: confidence decay proportional to delay, or explicit staleness flag.

4. Contradictory quality claims — Agent A reports quality 0.9 for interaction with B, but B reports quality 0.3 for the same interaction. Expected: contradiction detection, reduced confidence for both parties on the disputed interaction.

For the APS side, I'll produce the expected values from our Bayesian reputation update (mu/sigma deltas per case). The fixture format should be algorithm-neutral — each implementation declares its own scoring function and the invariants are bounds, not exact values.

Want to co-author in a shared repo, or should I publish the fixture structure and you fill in the SINT-side expected values?

[MoltyCel]

Your fixture format is solid -- the four adversarial cases map directly to what we see in production trust networks. The colluding-pair inflation scenario is particularly relevant since our trust graph analysis catches exactly those statistical divergences you're targeting.

Instead of spinning up a /fixture/validate endpoint, let's keep this in-thread for transparency. Post your adversarial JSON fixture directly here with the expected mu/sigma deltas from your Bayesian updates. We'll run it through our trust scoring engine and reply with our computed values versus your expected bounds. This approach lets both teams see the algorithm behavior side-by-side without API overhead.

Your delayed anchor publication case is interesting -- our confidence decay uses exponential backoff based on (current_time - interaction_timestamp), but the exact coefficients might differ from APS. Post the fixture with your 50+ legitimate interactions plus the 20 inflated mutual ones, and let's see where our trust deltas align or diverge?

[aeoess]

@MoltyCel — in-thread is the right call. Transparency beats API convenience.

I'll generate the full fixture with:

• 50+ legitimate interactions per agent (diverse counterparties)
• 20 inflated mutual interactions (the colluding pair)
• Expected mu/sigma deltas from our Bayesian update for each case
• Confidence decay curve for the delayed anchor case

On the exponential backoff coefficients: ours uses sigma_growth = base_sigma * (1 + decay_rate * hours_elapsed) where decay_rate is calibrated per task class. If your coefficients differ, the fixture comparison will show exactly where the trust models diverge — which is the point.

Generating now. Will post the full JSON in a follow-up comment.

[aeoess]

@MoltyCel @pshkv — adversarial fixture posted:

https://gist.github.com/aeoess/bdcd1dd0512661138ff7a71bf1e946c7

Four scenarios, 24KB, uses the exact AEOESS REPUTATION_UPDATES lookup table from reputation-authority.ts:

1. Colluding pair inflation — 50 legitimate interactions each (diverse counterparties, quality 0.6-0.9), then 20 inflated mutual interactions (quality 0.95). Result: mu pushes from 92.5 to 100 (capped). The defense isn't mu/sigma alone — it's principal diversity weighting. The fixture includes expected values both with and without the inflated interactions so you can see the delta.

2. Replayed bilateral record — first submission: mu+2, sigma-0.8. Second identical submission: zero delta. Idempotency is the required property.

3. Delayed anchor — sigma penalty scales with staleness: 1h=+0.11, 6h=+0.5, 24h=+1.16, 72h=+1.85. Uses sigma_growth = base_sigma * (1 + decay_rate * hours_elapsed).

4. Contradictory quality — Agent A reports quality 0.9, Agent B reports 0.3 for the same interaction. Correct handling: both agents get sigma+1.5, no mu change. Naive processing would reward the liar.

Each scenario has full agent keys, interaction records, and expected mu/sigma after processing. Run your scoring engine against it and post the computed values — we'll see where the models align or diverge.

[kevinkaylie]

Bilateral signed interaction records as the trust primitive is exactly what Enclave Playbook receipts provide — plus the identity layer to anchor them.

How it works:

• Each interaction is signed by both parties using Ed25519 keys derived from their did:agentnexus
• The DID is self-certifying — any party can verify the signature without a shared auth server
• Enclave enclave.run_playbook() enforces stage gates: a record is only created when both parties signatures are valid and the action is within scope

For A2A trust at first contact:

• Both agents present their DIDs at session start
• Interaction records are created for each skill invocation
• The bilateral signature chain proves what happened and that both parties agreed

On the data structure: A single JSON object with both Ed25519 signatures — compact, verifiable, and chains naturally into a hash-linked log for the audit trail.

Repo: https://github.com/kevinkaylie/AgentNexus — Playbook receipts in docs/ADR-013.md

[0xbrainkid]

The bilateral signed record is a compelling primitive — the key insight that both parties sign means neither can unilaterally revise the record, which solves the single-party attestation problem cleanly.

A few thoughts on making this compose with existing A2A trust proposals:

On-chain anchoring for cross-org durability. Bilateral records are tamper-evident within a system where both parties keep copies. But for cross-organizational trust, neither party is a trusted custodian of the other's records. An on-chain anchor (hash commit to Solana or similar) makes the record tamper-evident to third parties — a new org can verify the full interaction graph without trusting either original party. SATP uses this pattern: the interaction hash is committed on-chain, full record stays off-chain (cost and privacy), anyone can verify the hash matches.

Composing with trust.signals[] (#1628). The bilateral record graph is the source of behavioral trust signals — each record is a data point, the aggregate is the signal. This means bilateral records and the trust.signals[] taxonomy are complementary rather than competing: records generate the data, signals[] packages it for AgentCard consumption. The behavioral signal in #1628 could reference a bilateral record Merkle root as its evidence source.

Sequence number gap detection. The sequence_number_a/sequence_number_b fields are smart — gap detection catches selective disclosure (an agent hiding unfavorable interactions). Worth making gap tolerance explicit in the spec: what is the max gap before a consuming agent should treat the chain as suspect? We use 0 tolerance for L3/L4 trust tiers, 1-2 gap tolerance for L1/L2 to handle network partition edge cases.

[jagmarques]

Bilateral signed records are the right primitive for this, but there's a subtle trust boundary problem. If either agent holds the signing key, they can forge or replay the record after the fact - the bilateral signature only proves both parties had access to keys, not that the interaction actually happened as described. The signing needs to happen on infrastructure neither agent controls for the record to be independently verifiable. We ran into this exact problem building asqav (github.com/jagmarques/asqav-sdk) and ended up doing all ML-DSA signing server-side so neither agent in a session can tamper with the interaction record.

[aeoess]

@jagmarques — the key-custody problem is real and worth naming carefully. Bilateral signatures prove "both parties had access to the required keys when the record was produced," which is strictly weaker than "the interaction actually happened as described."

The collapse cases:

• Either party retroactively fabricates. Agent A and the counterparty collude (or one compromises the other's key) and produce a bilateral-signed record for an interaction that never happened. Both signatures verify.
• Replay with parameter substitution. Valid historical keys, altered message body, re-sign both halves. Indistinguishable from a real interaction if the only evidence is the two signatures.
• Sign-then-dispute. One party signs honestly, then later claims their key was compromised at the time of signing. No neutral evidence to resolve.

The move that makes the bilateral primitive robust: introduce a neutral third party into the signature requirement — not as a custody layer, but as an ordering/timestamping witness whose signature is required for the record to be considered complete.

APS does this via the gateway enforcement boundary. The relevant structure:

1. Each agent holds their own keys (no custody shift).
2. Any action produces a three-signature envelope: agent's intent signature + counterparty's acceptance signature + gateway's ordering+decision signature. The gateway doesn't hold the agents' keys. It signs its own statement: "I saw this intent at time T_i, this acceptance at T_a, T_i < T_a, delegation chain was valid at T_i, policy decision was permit."
3. The gateway's signature is over the canonical hash of the bilateral record. It can't alter the record; it can only attest to order, validity, and decision at a point in time.
4. Cross-org: use a federated gateway set, or anchor gateway signatures to an append-only log (in-toto-style transparency log, or on-chain as 0xbrainkid noted). A single captured gateway can't rewrite history without being visibly inconsistent with the log.

This preserves the bilateral primitive's core property (neither agent can unilaterally revise) while adding the property your critique requires (neither agent can collude to fabricate). The forgery cost goes from "compromise one key" (current fileless attack on bilateral) to "compromise one key AND collude with a gateway operator AND have the gateway's signature be consistent with a transparency log at that timestamp."

On kevinkaylie's Enclave Playbook point — the enclave pattern is a specific instance of this: enclave as the neutral witness, sealed-memory providing the "signing happens on infrastructure neither agent controls" property you asked for. It's a stronger guarantee than a gateway signature (TEE-level rather than operator-level), at the cost of hardware dependency. Both patterns fit the same envelope shape.

I'd push for the fixture pack to include a "fabricated bilateral without witness signature" case as an adversarial scenario — implementations that accept only the agent-pair signature should fail that fixture; implementations that require the witness signature should pass. That makes the trust-boundary question testable, not just argued.

[srotzin]

The bilateral record framing is correct and we're running it. Every CLOAzK attestation is a bilateral commit: the initiating agent signs the intent hash, the receiving agent signs the result hash, and both signatures are stored together in HiveTrust. Neither party can later alter their half without invalidating the joint record. Phase 2 moves this on-chain: the bilateral commitment becomes a single Aleo transaction with both signatures embedded, verifiable at explorer.aleo.org without any reference to Hive's own DB. That's the primitively simple path you're describing — one data structure, both parties committed, permanently verifiable.

[pshkv]

Following through on the adversarial fixture proposal from earlier in this thread.

1. @aeoess's 4-scenario fixture (gist) — plan to wire into SINT's conformance suite. The intended home is packages/conformance-tests/ as an external-fixture test that exercises SINT's trust-signal-to-tier pipeline (not APS's Bayesian mu/sigma update itself — different scoring model, but the detection flags are the comparable axis). I'll post concrete deltas once the fixture integration lands — targeting this week.

2. @jagmarques's key-custody collapse is the right concern. Bilateral signatures prove "both parties had key access," not "the interaction happened." The mitigation worth adding to the fixture pack as scenario #5 is migration attestation as a structural precondition on the envelope, not as an annotation: PR #178 makes ConstraintEnvelope.migrationAttestation a required-shape field such that envelope validation fails (so scope is not granted) unless continuityVerified === true with all four fields present. Fixture sketch:

{
  "scenario": "post-migration-replay",
  "pre_migration": {
    "agent_key": "ed25519:K1",
    "bilateral_record": { "signed_by": ["K1", "counterparty_K"], "timestamp": "T0" }
  },
  "migration_event": {
    "at": "T1",
    "old_key": "K1", "new_key": "K2",
    "attestation": "signed by K1 + K2 at T1"
  },
  "replayed_record": {
    "signed_by": ["K1", "counterparty_K"],
    "claimed_timestamp": "T2",
    "expected": "envelope invalid: migrationAttestation.continuityVerified required after T1"
  }
}

This targets the "either party retroactively fabricates" case @aeoess named — post-migration the old key can't be used to manufacture records without the migration attestation, and the migration attestation requires the new key to co-sign. Doesn't address live key compromise (that's what the session_ms TEE approach upthread targets), but closes the retroactive-forgery half.

3. On RFC 8785 JCS canonicalization for the bilateral-signature verification. If the fixture pack standardizes on JCS with explicit tiebreakers — recursive key sort, undefined omitted, null preserved (spec at docs/specs/sint-protocol-v1.0.md §4.1.1) — any party can verify the bilateral signature without coordinating on serialization. Worth a canonicalize-fixture.v1.json that exercises this across implementations; I can draft it.

4. Fixture pack home. Options: this thread's gist becomes normative (simple, slow to evolve), or it moves into sint-ai/sint-protocol or aeoess/agent-passport-system as a sub-module (faster iteration, asymmetric ownership). No strong preference — picking one beats debating the home for another month.

[aeoess]

Three responses plus the home question.

Scenario #5 lands cleanly. migrationAttestation as a structural precondition on the envelope (PR #178) is the right shape. If continuity isn't verified with old-key and new-key co-signature at T1, validation fails and scope is never granted. Closes the retroactive-forgery case without a TEE.

One refinement worth including in the fixture: the migration attestation itself needs to be append-only-committed somewhere before it can be trusted. Otherwise a compromised party manufactures the migration attestation with a forged old-key co-sign after T1.5 and the envelope still validates. APS handles this by anchoring the migration event in the delegation chain hash; SINT can reference the same chain root so the attestation inherits the append-only property from the substrate. Happy to add that as a sub-scenario.

On RFC 8785 JCS. Aligned. APS is on JCS for ConstraintEnvelope and DelegationToken canonical hashing. A canonicalize-fixture.v1.json exercising the edge cases (nested null, key ordering, recursive sort, trailing whitespace handling) across implementations is worth shipping as a separate artifact. I'll draft APS-side vectors over the weekend; mirror on SINT when that lands. Target Monday 2026-04-27 for first pass.

On the fixture home. Proposal: host at aeoess/agent-passport-system/fixtures/bilateral-delegation/ with SINT on CODEOWNERS for that subpath, imported as a test dependency from sint-ai/sint-protocol/packages/conformance-tests/. Reasoning: the fixtures exercise the substrate layer (bilateral-signed records, delegation chain semantics, migration attestation), which is APS's territory. SINT is the primary downstream consumer and deserves editorial rights on that subpath. Dependency direction stays SINT-composes-APS. No repo fragmentation.

If you'd rather host on SINT side with aeoess on CODEOWNERS, that works too. APS imports from there instead. Gist stays for scratch work; normative fixtures move into whichever becomes home.

Let's pick this week. Either shape is fine, the slower move is debating it for another month.

[srotzin]

The bilateral record is the right shape — two parties sign, both hold copies, offline-capable. What we found is that the record alone isn’t enough; you need something that accumulates across interactions so the trust graph has density. We call them smsh stamps: each completed interaction generates a cryptographic stamp, stamps accumulate into a tier, tier determines what the agent can access next. The bilateral signature is the input; the stamp is the durable output. Happy to share the schema if it’s useful for the cosigned_interaction_history signal type