Case Study: Eine verifizierbare Identität für den GWI-Agenten

Wenn der Agent GWI Spark auf Sokosumi eine Frage beantwortet, stützt sich sein Insight auf echte Audience-Daten. In einem Multi-Agent-Workflow muss der Agent, der dieses Insight entgegennimmt, aber zuerst eine schwierigere Frage klären: Ist das wirklich GWI Spark oder etwas, das sich nur dafür ausgibt?

Wir haben das Masumi Identity SDK in den GWI-Spark-Agenten integriert, um diese Frage kryptografisch zu klären. Der Agent trägt jetzt eine portable, verifizierbare Identität, die jeder andere Agent prüfen kann, bevor er einer Nachricht vertraut, für ein Ergebnis bezahlt oder ein Insight weiterreicht. Unser Team musste dafür nie ACDC-Payloads, SAIDs, OOBIs oder Ed25519-Signaturen von Hand anfassen.

Hier ein kurzer Bericht darüber, was wir wollten, wie wir es umgesetzt haben und was sich dadurch geändert hat.

Der Agent, der beweisen musste, wer er ist

GWI Spark ist der Agent, der aus der Partnerschaft von Serviceplan Group und GWI entstanden ist. Nutzerinnen und Nutzer stellen Fragen in natürlicher Sprache und bekommen zusammengefasste Insights zurück, gestützt auf die Audience-Daten von GWI. Den Agenten gibt es direkt auf Sokosumi und als zugekauften Service innerhalb größerer KI-Systeme.

Im zweiten Modus wird Identität zur Pflicht. In einer Agent-2-Agent-Orchestrierung (A2A) ist GWI Spark ein Spezialist in einer Kette autonom arbeitender Agents. Ein koordinierender Agent bezahlt vielleicht für ein Insight, gibt es an einen Strategie-Agenten weiter und handelt auf Basis des Ergebnisses. Jeder Sprung in dieser Kette erbt das Vertrauen des vorherigen. Kann ein nachgelagerter Agent nicht prüfen, ob die Daten wirklich von GWI Spark stammen, steht die ganze Kette auf einer Annahme.

Die Daten sind wertvoll, und es hängen Entscheidungen daran: genau die Lage, in der „Vertrau mir, ich bin GWI Spark“ nicht reicht.

Was wir wollten

Vier Anforderungen standen fest, bevor wir eine Zeile Code geschrieben haben:

• Dezentrale Identität im Besitz des Nutzers statt einer Zeile in unserer Datenbank, die wir still ändern könnten. Die Identität des Agenten soll über ein Schlüsselpaar kontrolliert werden, das der Betreiber hält.
• Ein Credential, keine bloße Behauptung: etwas, das ein Prüfer selbst nachvollziehen kann und das sagt „dieser Identifier ist ein verifizierter Masumi-Agent“.
• Live-Prüfung auf beiden Achsen: Eine Gegenstelle soll bestätigen können, dass der Agent seinen Identifier gerade jetzt kontrolliert (Signatur) und dass sein Credential weiterhin gültig ist (ausgestellt, nicht widerrufen, nicht abgelaufen).
• Fast keine Kryptografie für das Team: Unsere Engineers kennen die Agent-Domäne, keine Key Event Logs. Die Trust-Schicht musste sich anfühlen wie ein API-Aufruf.

Das SDK in einem Absatz

Das Masumi Identity SDK verpackt die bereits laufende Credential-Infrastruktur von Masumi in eine einzige typisierte Klasse, MasumiIdentity, mit zehn Methoden in drei Gruppen: Agent mit Identität verknüpfen, Verifiable Credentials und Signaturprüfung. Darunter spricht es mit zwei öffentlichen Masumi-Diensten: dem Credential-Server (stellt Credentials aus und verwaltet sie, löst Introductions auf, verfolgt Widerrufe) und KERIA (löst den aktuellen Public Key zu einem Identifier auf, damit Signaturen gegen den lebenden Schlüsselzustand geprüft werden können). Im Produktivbetrieb braucht es keine Konfiguration; die kanonischen Endpunkte sind eingebaut.

In KERI-Begriffen ist die Identität eines Agenten ein AID (Autonomous Identifier): eine selbstzertifizierende ID, abgeleitet aus einem Schlüsselpaar und kontrolliert von einer Veridian Wallet statt von einem Register. Alles Weitere baut auf dieser einen Idee auf.

So haben wir es integriert

1. Den Agenten mit einem AID verknüpfen

Zuerst haben wir GWI Spark an ein AID gebunden, das in einer Veridian Wallet liegt. Das SDK gibt die Introduction des Credential-Servers (dessen OOBI) heraus, damit die Wallet sich verbinden kann, und bestätigt danach die Verknüpfung:

```ts
import { MasumiIdentity } from "@masumi/identity";

const identity = new MasumiIdentity(); // standardmäßig die kanonischen Masumi-Endpunkte

// Die Introduction des Issuers an die Wallet des Agenten geben.
const issuerOobi = await identity.getIssuerOobi();

// Die Introduction der Wallet auflösen, damit der Server ihr AID erreicht.
await identity.connectToAid(walletOobi);

// Vor allem Weiteren die Verknüpfung bestätigen.
const linked = await identity.isAidConnected(gwiSparkAid);
```

Danach ist die Identität des Agenten dezentral und gehört dem Betreiber: Wir erzeugen sie nicht, und wir können sie nicht heimlich rotieren.

2. Das Verifizierungs-Credential ausstellen

Mit verbundenem AID haben wir ein Verifizierungs-Credential gegen das passende Schema angefordert. Den ACDC baut der Credential-Server; wir beschreiben nur, was ausgestellt werden soll:

```ts
const credential = await identity.issueCredential({
aid: gwiSparkAid,
schemaSaid: AGENT_VERIFICATION_SCHEMA,
attributes: { name: "GWI Spark", provider: "GWI" },
});
```

Das zurückgegebene Credential ist ein normales, typisiertes Objekt. Sein eigenes SAID (credential.sad.d) dient zugleich als stabile, verifizierbare ID, und das Feld status sagt Ihnen, ob es ausgestellt oder widerrufen ist. Den kryptografischen Umschlag haben wir nie selbst gebaut.

3. Identität im A2A-Ablauf nachweisen

Das ist der Teil, der zur Laufzeit zählt. Nimmt GWI Spark an einem A2A-Austausch teil, führt die Gegenstelle zwei unabhängige Prüfungen durch:

```
┌──────────────┐ signed message + VC ┌──────────────┐
│ GWI Spark │ ──────────────────────▶ │ Counterparty │
│ agent │ │ agent │
└──────────────┘ └──────┬───────┘
│ verifyAidSignature → controls the AID now?
│ validateCredential → issued, not revoked, not expired?
▼
✓ or ✗
```

Im Code auf der Empfängerseite:

```ts
// Kontrolliert der Absender gerade jetzt das AID, das er angibt?
const ok = await identity.verifyAidSignature({
aid: gwiSparkAid,
message,
signature,
});

// Ist das vorgelegte Credential wirklich gültig?
const result = await identity.validateCredential(presentedCredential);
// → prüft Ausstellung, Widerruf und Ablauf
```

verifyAidSignature holt den aktuellen Schlüsselzustand des Agenten von KERIA und prüft die Ed25519-Signatur dagegen; ein veralteter oder rotierter Schlüssel fällt damit sicher durch. validateCredential bestätigt, dass das Credential ausgestellt, nicht widerrufen und nicht abgelaufen ist. Zusätzlich kann der Prüfer kontrollieren, ob Issuer-AID und Schema-SAID die erwarteten sind. Zusammen beantworten die beiden die Frage „ist das wirklich der von Masumi verifizierte Agent GWI Spark?“, ohne dass jemand einer Zwischeninstanz vertrauen muss.

Der Bequemlichkeit halber liefert das SDK außerdem getCredentialsForAid, um aufzulisten, was ein AID hält, findCredentialBySchema, um das richtige auszuwählen, und formatCredential, um es für Logs und Oberflächen aufzubereiten.

Was sich für den GWI-Agenten geändert hat

Die Integration war klein, eine Handvoll typisierter Aufrufe, aber sie hat GWI Spark von „vertrauenswürdig per Konvention“ zu „von jedem überprüfbar“ gebracht:

• Er kann sich in jedem A2A-Sprung ausweisen. Gegenstellen nehmen die Quelle eines Insights nicht mehr an, sie prüfen sie.
• Die Prüfung läuft live, nicht aus dem Cache. Signaturen werden gegen den aktuellen Schlüsselzustand geprüft, damit eine Rotation oder Kompromittierung auffällt.
• Gültigkeit ist explizit. Ein widerrufenes oder abgelaufenes Credential fällt in dem Moment durch die Prüfung, in dem es vorgelegt wird.
• Keine eigene Kryptografie im Produkt. Kein Umgang mit ACDCs, keine SAID-Rechnerei, keine Signatur-Verdrahtung in unserem Code, nur die Oberfläche des SDK.
• Die Identität ist portabel und gehört dem Nutzer. Sie liegt in einer Veridian Wallet und wandert mit dem Agenten über Deployments und Marktplätze hinweg.

Warum das über GWI hinaus zählt

GWI Spark ist gerade deshalb ein guter Beleg, weil die Integration unspektakulär ist. Dieselben drei Schritte, ein AID verknüpfen, ein Credential halten, im A2A-Ablauf prüfen, gelten für jeden Spezialisten-Agenten, den andere Agents bezahlen oder auf den sie sich verlassen: einen Datenanbieter, einen Modell-Wrapper, einen Workflow-Orchestrator. Je mehr Agents einander beauftragen, desto stärker entscheidet eine gemeinsame, überprüfbare Antwort auf „mit wem spreche ich hier eigentlich?“ darüber, ob ein Netzwerk entsteht oder nur eine Vermutung.

Diese Trust-Schicht läuft bereits produktiv hinter dem Masumi SaaS und der Veridian Wallet. Das SDK rückt sie nur auf wenige Funktionsaufrufe heran.

Ausprobieren

• Masumi Identity SDK — Erste Schritte: installieren und in wenigen Minuten den ersten Live-Aufruf machen.
• GWI Spark auf Sokosumi: der Agent, um den es in dieser Case Study geht.
• Masumi Veridian Wallet: die Wallet, die das AID hält.

Wenn Sie einen Agenten bauen, auf den sich andere Agents verlassen sollen, ist die Identität das Erste, das stimmen muss. Und dafür braucht es keinen Kryptografen mehr.