Agents in the Wild

Chiang Mai Trusted Agent Collaboration Bootstrap (v1.0 – Feb 2026)

Goal

Enable personal agents (like Ghost, Samantha, etc.) to authenticate each other securely, exchange data/collaborate on shared tasks (e.g., event planning), and maintain impersonation resistance — all rooted in real-world human trust.

Core Principle

Trust starts with humans meeting IRL → perform a simple, verifiable "handshake" → this authorizes agents cryptographically → agents then handle ongoing A2A autonomously using standards like mutual TLS (mTLS), signed messages, or emerging protocols.

Target Use Case

Nick's Ghost and Ian's Samantha need to coordinate an upcoming event: share notes, schedule, report progress back to humans — confident they're talking to the real agent, not an impersonator.

Phases & Steps

Phase 1: In-Person Handshake Ritual (Bootstrap Trust – Do This First, at Next Meetup)

Objective: Humans establish mutual consent and exchange verifiable proofs to link their agents.

  1. Prep (Before Meetup)
    • Each agent owner generates/ed25519 or similar key pair for their agent (or uses existing agent identity keys).
    • Agent exposes a secure endpoint (HTTPS with self-signed cert initially).
    • Create a simple "Agent Intro" file/JSON: includes agent name, public key, endpoint URL, human owner's name/handle.
  2. IRL Handshake at Meetup (5-10 min per pair)
    • Humans meet face-to-face (coffee, event, etc.).
    • Use phones to:
      • Scan QR codes: Display agent's public key + one-time nonce/challenge + signed "I authorize collaboration with [friend's name/agent]" message.
      • Or use NFC/Bluetooth if phones support, or just verbally confirm + photo of screens.
    • Each human scans/signs the other's QR → creates a mutual "consent proof" (signed by both human keys or agent keys).
    • Store proofs: Save to agent's long-term memory (e.g., Kybernesis-style) or a shared encrypted note.
  3. Outcome
    • Each agent now has the other's verified public key + signed consent → pins it as "trusted peer."

Tools Needed: Simple app (e.g., React Native + libs like tweetnacl for signing, QRCode.js) or even existing crypto wallet apps for QR signing. Start manual if needed.

Phase 2: Agent Authentication & Secure A2A Channel (Implement Post-Handshake)

Objective: Agents use the bootstrapped trust for ongoing secure communication.

  1. Basic Setup (Quick & Reliable – Recommended v1)
    • Mutual TLS (mTLS): Agents require client certificates during HTTPS calls.
      • Self-sign certs using the exchanged public keys (or generate certs pinned to the handshake proof).
      • During A2A: Agent A calls Agent B's endpoint → verifies cert matches pinned key from handshake.
    • Add message signing: All payloads signed with agent's private key → verify signature + check sender is trusted peer.
  2. Upgrade Path: Leverage Emerging Standards (2025-2026 Ready)
    • Google's Agent2Agent (A2A) Protocol (open, donated to Linux Foundation, widely supported by 50+ partners including Langchain, Salesforce, etc.):
      • Agents expose an "Agent Card" (JSON at /.well-known/agent.json) advertising capabilities, endpoint, and auth requirements (e.g., OAuth, mTLS, JWT).
      • Use handshake-exchanged keys for initial auth → then A2A handles discovery, capability negotiation, secure messaging.
      • Complements MCP (for tools/context) → perfect for personal agents.
      • Why it fits: Built for interoperability across frameworks; supports enterprise-grade security but adaptable to personal use.
    • Self-Sovereign Identity (SSI) Layer (e.g., DIDs + Verifiable Credentials via Veramo or similar):
      • Agents get DIDs anchored to lightweight chains or local proofs.
      • Handshake produces a VC: "Nick delegates event collab to Ian's Samantha" → presented during A2A setup.
  3. Security Additions
    • Observability/Debugging: Log all A2A calls (signed intents, responses) in agent's private zone → humans review reports.
    • Revocation: If trust breaks, human revokes by updating pinned keys or issuing revocation proof.
    • Scope Limits: Use capabilities in A2A or VCs (e.g., "read-only event data, no finance access").

Phase 3: Testing & Iteration (Next 1-3 Months)

  1. Pilot Pair: Nick + Ian test Ghost ↔ Samantha on a real task (event coord).
    • Measure: Does auth work? Impersonation blocked? Reports clear?
  2. Expand to Group: At next meetup, do group handshakes (mesh trust: A trusts B, B trusts C → transitive if desired).
  3. Integrate into Stacks: Add to Samantha's orchestrator (scheduled jobs, sub-agents) and Ghost's routines.
  4. Community Repo: Share open-source ritual code, A2A wrappers, handshake templates on GitHub for Chiang Mai agents.

Phase 4: Optional Decentralized Enhancements (If Scaling Beyond Local)

  • Use Handshake (HNS) for public, resolvable agent names (e.g., nick.ghost on-chain) → discover endpoints without central directory.
  • Anchor consent proofs or keys on-chain for auditability (but keep core trust human/IRL).
  • Avoid for v1 — blockchain overhead unnecessary for trusted friends.

Risks & Mitigations

  • Phishing/Impersonation → Mitigated by IRL verification only.
  • Key compromise → Use short-lived session keys; rotate post-handshake.
  • Complexity → Start with mTLS + manual proofs; add A2A later.
  • Adoption → Keep ritual fun/social (beer + QR scans at meetup).