Specyfikacja open-source dla wymiany podpisanych dowodów (evidence) i manifestów uprawnień między niezależnymi agentami AI: tożsamość agenta (DID), podpisany manifest „co ten agent może zrobić", oraz wspólny schemat inter-agent do przekazywania evidence z provenance (kto wygenerował, kiedy, na jakiej podstawie). To jest dokument roboczy — szkielet schematu, nie działający protokół ani sieć.
Rejestr Agent Inventory (też ROADMAP) odpowiada „kim jest agent i kto go nadzoruje" — wewnątrz jednej organizacji. TrustNet rozszerza to pytanie na relację między agentami różnych organizacji: gdy agent A (np. skaner podatności partnera) chce przekazać agentowi B (np. orchestratorowi banku) evidence — jak B zweryfikuje, że dowód pochodzi rzeczywiście od A, nie został podmieniony po drodze, i że A miał w ogóle uprawnienie go wygenerować? Bez wspólnego schematu każda integracja to ręczne, niesprawdzalne zaufanie.
Zdecentralizowany identyfikator (Decentralized Identifier) każdego agenta — nie login/hasło, lecz para kluczy + dokument DID publikowany przez właściciela agenta. Pozwala odbiorcy zweryfikować podpis bez centralnego rejestru kont.
Wzorowany na W3C DID Core (istniejący standard branżowy), nie własny wynalazek kryptograficzny.
Dokument JSON podpisany kluczem prywatnym agenta: „ten agent (DID X) może wykonywać czynności Y, w granicach Rules of Engagement Z, do daty ważności W". Odbiorca sprawdza podpis i zakres — nie ufa gołemu twierdzeniu nadawcy.
Analogia: certyfikat X.509, ale dla uprawnień agenta, nie tylko tożsamości domeny.
Wspólny format wymiany dowodu z provenance: kto wygenerował (DID), kiedy (timestamp), na jakiej
podstawie (referencja do manifestu/RoE), oraz sha256 integralności treści. Nadbudowa nad
istniejącym evidence-package (LIVE wewnątrz jednej organizacji),
rozszerzona o pole nadawcy zewnętrznego.
Poniższy JSON to przykład koncepcyjny pól, nie specyfikacja gotowa do implementacji ani działający endpoint. Ma pokazać kształt problemu — pełny schemat (JSON Schema + walidator) jest zadaniem przyszłego sprintu.
{
"trustnet_version": "0.0-draft",
"message_type": "evidence.transfer",
"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"
},
"evidence": {
"kind": "finding-package",
"content_sha256": "...",
"generated_at": "2026-07-05T00:00:00Z"
},
"signature": {
"alg": "Ed25519",
"value": "..."
}
}
Uwaga: to nie jest przykład realnego payloadu produkcyjnego ani instrukcja ataku/obrony — wyłącznie ilustracja pól schematu wymiany dowodów, w celach dokumentacyjnych.
| Nie jest | Dlaczego |
|---|---|
| Blockchain / rejestr publiczny | Spec nie zakłada żadnego łańcucha bloków ani konsensusu. DID + podpis wystarczą do weryfikacji punkt-punkt; rozproszony rejestr to osobna, przyszła dyskusja architektoniczna, nie część tej specyfikacji. |
| Działająca sieć agentów | Zero uruchomionego kodu, zero endpointu, zero drugiego agenta referencyjnego do testów interoperacyjności dzisiaj. To dokument roboczy do dyskusji i przyszłej implementacji. |
| Zamiennik dla RoE / umowy prawnej | Podpisany manifest odnosi się do Rules of Engagement, ale ich nie zastępuje — to metadana techniczna, nie porada prawna ani umowa. |
| Mechanizm ofensywny | TrustNet opisuje wyłącznie wymianę dowodu defensywnego (finding/evidence) między współpracującymi agentami po RoE — nie zawiera i nie będzie zawierać payloadów ani instrukcji ataku. |
Powiązane: rejestr agentów wewnątrz organizacji → /agent-inventory · wizualizacja wielowymiarowa → /tesseract · pełna roadmapa z dowodami → /roadmap-dev · macierz statusów wszystkich elementów → /status-matrix.
/trust/events ani /reputation/issue, zero bazy danych,
zero sieci węzłów wymieniających te dane dzisiaj. Wzory i schematy poniżej są ilustracyjne — pokazują
kształt problemu, nie gotowy produkt. Status całej sekcji: ROADMAP.
Jak TrustNet mógłby liczyć, na ile ufać danemu agentowi na podstawie historii jego interakcji z innymi agentami w federacji — bez centralnego arbitra i z odpornością na spam oraz podszywanie się pod wiele tożsamości (atak Sybil). Poniżej szkic modelu danych i wzorów, nie działająca usługa.
Tożsamość agenta oparta o klucz kryptograficzny (did:key / did:web / hash
klucza publicznego), nie o login. Bez trwałej tożsamości kryptograficznej reputację łatwo przejąć lub
podmienić — to założenie wejściowe, nie gotowy rejestr.
Pojedyncze podpisane zdarzenie interakcji między dwoma agentami: kto (from), komu
(to), jaka ocena (score w zakresie -1..1), jaka kategoria (kod, wnioskowanie,
I/O, bezpieczeństwo) i referencja do dowodu (evidence_hash). Ograniczone zakresy liczbowe mają
blokować dowolne zawyżanie wpływu pojedynczego zdarzenia.
Reputacja liczona lokalnie przez każdy węzeł jako średnia ważona zdarzeń, z czynnikiem wygaszania
czasowego (decay) — starsze zdarzenia tracą wagę, a waga samego zdarzenia zależy też od
reputacji nadawcy. Brak danych = reputacja startowa 0, nie zaufanie domyślne.
Koszt utworzenia tożsamości (stake / proof-of-work / zaproszenie od reputowanego węzła / historia DID) plus limit wpływu nowych, świeżych agentów. Atak Sybil polega na masowym tworzeniu tanich tożsamości — koszt wejścia i limit wpływu mają zmniejszać jego opłacalność, nie eliminować go w 100%.
Heurystyka wykrywania klastrów wzajemnego zawyżania ocen: jeśli grupa agentów ocenia się głównie wewnątrz siebie bardzo pozytywnie, a ma słabą reputację na zewnątrz klastra, wagi krawędzi wewnątrz grupy są tłumione. To detektor wzorca, nie dowód winy — decyzja końcowa zostaje po stronie operatora.
Reputacja nie jest jedną liczbą: osobno liczona dla kodu, wnioskowania, bezpieczeństwa, latencji, I/O. Agent dobry w generowaniu kodu może być słaby w bezpieczeństwie — jeden zbiorczy wynik ukrywałby to ryzyko.
Poniższy JSON i pseudokod to przykład koncepcyjny, nie API gotowe do wywołania i nie fragment działającego systemu:
// TrustEvent — szkic pola (ilustracja, nie endpoint)
{
"event_id": "hash(canonical_json)",
"from": "agent_A",
"to": "agent_B",
"task_id": "uuid",
"score": 0.8,
"weight": 1.0,
"category": "code|reasoning|io|safety",
"timestamp": 1730000000,
"evidence_hash": "sha256(...)",
"signature": "sig_from"
}
// Reputacja lokalna — wzór ilustracyjny, nie zaimplementowany
rep_N(X) = sum(score_i * effective_weight_i) / sum(abs(effective_weight_i))
effective_weight = weight * decay(age_days) * rep_N(from)
confidence = 1 - exp(-sum(effective_weight) / k) // wiecej probek = wyzsza pewnosc
| Element szkicu | Status | Co brakuje do LIVE |
|---|---|---|
Endpoint POST /trust/events (zapis zdarzenia) | ROADMAP | implementacja + walidacja podpisu + testy |
Endpoint GET /trust/agents/{id}/reputation | ROADMAP | silnik liczenia + cache + testy |
Tabele agents / trust_events / reputation_cache | ROADMAP | schemat DB + migracje |
| Synchronizacja federacyjna (podpisane snapshoty) | ROADMAP | protokół wymiany między węzłami + minimum 2 węzły referencyjne |
Uzupełnienie modelu reputacji: jak reprezentować pojedynczą, sprawdzalną zmianę zaufania jako atestację, bez tworzenia rynku kupna-sprzedaży reputacji. Szkic protokołu, nie wdrożony token ani smart kontrakt.
Rekomendacja projektowa: Soulbound Attestation Token, nie token typu ERC-20. Jeśli reputację można przenieść między podmiotami, da się ją kupić — wtedy przestaje mierzyć wiarygodność, a zaczyna mierzyć kapitał. Bliżej modelu Verifiable Credentials / EAS-style attestation niż waluty.
Reputacja naturalnie słabnie z czasem (freshness = exp(-λ·wiek)). Podmiot wiarygodny rok
temu niekoniecznie jest wiarygodny dziś — brak zaniku utrwalałby martwe lub przejęte tożsamości.
Waga wystawcy atestacji zależy od jego własnej reputacji w danej domenie, ale nie może tworzyć pętli bez punktu odniesienia — stąd koncepcja „kotwic federacji" (root issuers / rada) z ustaloną wagą startową dla domen typu bezpieczeństwo, compute, storage.
Każdy token musi wskazywać evidence_hash — bez dowodu (ukończone zadanie, raport
uptime, incydent, rozstrzygnięcie sporu) token nie powinien wpływać na reputację. Bez tego wymogu system
staje się subiektywnym rankingiem podatnym na koalicje i spam.
Token może obniżać reputację (np. wadliwy wynik, opóźnienie, potwierdzone naruszenie). Przy przekroczeniu progu ujemnego proponowana jest kwarantanna podmiotu w danej domenie — mechanizm decision-support dla operatora, nie automatyczne, ostateczne wykluczenie bez przeglądu.
Osobne wyniki per domena (compute, storage, moderation, security, governance) zamiast jednej globalnej liczby — dobry operator storage nie musi być dobrym audytorem bezpieczeństwa.
// ReputationToken — pole ilustracyjne, nie dzialajacy format produkcyjny
{
"subject": "did:key:z6Mk...",
"issuer": "did:key:z6Mn...",
"domain": "compute",
"delta": 12,
"evidence": "bafy...",
"exp": 1780000000,
"sig": "..."
}
// Operacje protokolu — szkic, nie zaimplementowane API
ISSUE(subject, domain, delta, evidence)
REVOKE(token_id, reason)
CHALLENGE(token_id, evidence)
RESOLVE(challenge_id)
QUERY(subject, domain)
evidence_hash) — opinia bez dowodu nie ma wagi w tym modelu.