Szkielet schematu wiadomości między niezależnymi agentami AI: podpisana wiadomość (signed message), provenance (kto, kiedy, na jakiej podstawie), odniesienie do DID/manifestu nadawcy i koperta wymiany evidence. To rozwinięcie TrustNet o warstwę transportu wiadomości — nie tylko tożsamość i uprawnienia, ale kształt samej koperty, w której agent A rozmawia z agentem B. Status: dokument roboczy, szkielet schematu, zero działającego kodu ani endpointu.
TrustNet (też ROADMAP) odpowiada na pytanie „kim jest agent i co wolno mu robić" — DID + podpisany manifest uprawnień. Ta strona odpowiada na osobne pytanie: jak wygląda pojedyncza wiadomość, którą agent A wysyła do agenta B — jakie pola musi mieć koperta, żeby odbiorca mógł zweryfikować podpis, prześledzić provenance (łańcuch pochodzenia) i bezpiecznie odrzucić wiadomość, która nie spełnia formatu. Bez wspólnego schematu wiadomości nawet poprawny DID i manifest nie wystarczą — każda para agentów musiałaby ręcznie uzgadniać format koperty.
Wspólna struktura nagłówka: typ wiadomości, wersja schematu, identyfikator korelacji (żeby powiązać żądanie z odpowiedzią), znacznik czasu wysłania. Bez tej warstwy odbiorca nie ma sposobu odróżnić wiadomości zgodnej ze schematem od dowolnego, niezweryfikowanego JSON-a.
Każda wiadomość niesie podpis kryptograficzny nadawcy oraz pole provenance: kto (DID),
kiedy (timestamp), na jakiej podstawie (referencja do manifestu uprawnień
z TrustNet). Odbiorca weryfikuje podpis przed przetworzeniem treści —
nie ufa gołemu twierdzeniu nadawcy.
Wiadomość nie zawiera pełnego manifestu uprawnień — odsyła do niego przez referencję (hash + URL/DID document), tak by odbiorca mógł pobrać i zweryfikować aktualny zakres uprawnień nadawcy niezależnie od treści pojedynczej wiadomości. Manifest sam w sobie pozostaje elementem specyfikacji TrustNet.
Wyspecjalizowany podtyp wiadomości dla przekazania dowodu (finding/evidence-package): odsyła do
content_sha256 treści dowodu, nie duplikuje samego dowodu w kopercie. Nadbudowa nad istniejącym
evidence-package (LIVE wewnątrz jednej organizacji), rozszerzona
o pole nadawcy zewnętrznego i podpis koperty.
Poniższy JSON to przykład koncepcyjny pól koperty, nie specyfikacja gotowa do implementacji
ani działający endpoint. Wartości ... są symboliczne — brak w nich jakichkolwiek realnych danych,
kluczy czy treści ataku. Cel: pokazać kształt problemu, nie dostarczyć gotowy protokół.
{
"schema_version": "0.0-draft",
"message_id": "uuid-v4-placeholder",
"correlates_with": null,
"message_type": "evidence.envelope",
"sent_at": "2026-07-05T00:00:00Z",
"sender": {
"did": "did:example:agent-scanner-partnerX",
"manifest_ref": "sha256:...",
"roe_ref": "https://partnerX.example/roe/2026-07.pdf"
},
"recipient": {
"did": "did:example:orchestrator-bankY"
},
"provenance": {
"generated_by": "did:example:agent-scanner-partnerX",
"generated_at": "2026-07-05T00:00:00Z",
"basis_ref": "manifest+roe"
},
"payload_ref": {
"kind": "finding-package",
"content_sha256": "..."
},
"signature": {
"alg": "Ed25519",
"value": "..."
}
}
Uwaga: to nie jest przykład realnego payloadu produkcyjnego ani instrukcja ataku/obrony — wyłącznie ilustracja pól koperty wiadomości, w celach dokumentacyjnych. Schemat opisuje wyłącznie wymianę dowodów defensywnych po pisemnych Rules of Engagement.
| Strona | Pytanie, na które odpowiada | Status |
|---|---|---|
| TrustNet | Kim jest agent (DID) i co wolno mu robić (podpisany manifest uprawnień)? | ROADMAP |
| Inter-Agent Communication Schema (ta strona) | Jak wygląda pojedyncza podpisana wiadomość między dwoma agentami — koperta, provenance, referencje? | ROADMAP |
| Agent Chain-of-Custody | Jaki ślad dowodowy zostawia działanie pojedynczego agenta wewnątrz jednej organizacji, krok po kroku? | zobacz stronę Agent CoC dla aktualnego statusu |
| Human Oversight Ledger | Gdzie i kiedy człowiek nadzorował/zatwierdzał decyzję agenta (wymóg nadzoru ludzkiego)? | zobacz stronę Oversight Ledger dla aktualnego statusu |
Cztery strony razem opisują pełen łańcuch nadzoru nad agentami AI: tożsamość i uprawnienia (TrustNet) → kształt wiadomości między agentami (ta strona) → ślad dowodowy działania (Agent CoC) → punkt zatwierdzenia przez człowieka (Oversight Ledger). Żadna z czterech nie jest dziś działającym produktem — wszystkie to elementy tej samej, spójnej specyfikacji nadzoru.
| Nie jest | Dlaczego |
|---|---|
| Działający protokół sieciowy | Zero uruchomionego kodu, zero endpointu, zero transportu (HTTP/gRPC/queue) zdefiniowanego dziś. To dokument roboczy do dyskusji i przyszłej implementacji, nie biblioteka gotowa do instalacji. |
| Zamiennik dla RoE / umowy prawnej | Pole roe_ref odsyła do Rules of Engagement, ale ich nie zastępuje — to metadana
techniczna w kopercie, nie porada prawna ani umowa między stronami. |
| Mechanizm ofensywny | Schemat opisuje wyłącznie wymianę wiadomości defensywnych (finding/evidence) między współpracującymi agentami po RoE, na danych syntetycznych/ilustracyjnych — nie zawiera i nie będzie zawierać payloadów ani instrukcji ataku. |
| Blockchain / konsensus rozproszony | Podpis + provenance wystarczą do weryfikacji punkt-punkt między dwoma agentami; rozproszony rejestr czy konsensus to osobna, przyszła dyskusja architektoniczna, nie część tej specyfikacji. |
Powiązane: specyfikacja tożsamości i uprawnień agenta → /trustnet · ślad dowodowy działania agenta → /agent-coc · rejestr nadzoru ludzkiego → /oversight-ledger · pełna roadmapa z dowodami → /roadmap-dev · macierz statusów wszystkich elementów → /status-matrix.