Verifizierter Support-Agent

Ein echter KI-Agent, gebaut mit dem Claude Agent SDK, dessen einziger Weg zu einem Backend über einen MCP-Server führt, der mit KYA-OS gesichert ist (dem offenen Standard für agentische Identität und Delegation, gespendet an die Decentralized Identity Foundation von Vouched).

Das Szenario spiegelt Vouches eigenes wiederkehrendes Beispiel wider: ein Support-Agent, der eine Rückerstattung von 50 $ automatisch bearbeiten kann, aber für alles Größere die Genehmigung eines Menschen benötigt. Alles hier ist real – eine echte kryptografische Identität mit Ed25519-Signatur, eine echte W3C-Delegationsberechtigung, ein echter HTTP-Consent-Server, der sie ausstellt, und ein echter Agent, der die Tool-Aufrufe durchführt. Das Einzige, was simuliert ist, sind die Bestelldaten (siehe „Warum simuliert“ unten).

Agent calls issue_refund($30)  -> executes immediately, proof attached
Agent calls issue_refund($500) -> needs_authorization -> human approves at a real URL -> agent retries -> succeeds

Warum es das gibt

KI-Agenten handeln jetzt im Namen von Benutzern – sie prüfen den Bestellstatus, erstatten Beträge, bewegen Geld – und verwenden dabei Anmeldeinformationen, die sie von dem Menschen, für den sie handeln, ununterscheidbar machen. Ein Session-Cookie fasst drei getrennte Fragen in einer einzigen ununterscheidbaren HTTP-Anfrage zusammen: wer tatsächlich handelt, in wessen Auftrag und ob diese spezifische Aktion innerhalb dieser Befugnis liegt. KYA-OS beantwortet diese drei Fragen getrennt, sodass Aktionen mit geringem Risiko vollständig automatisiert werden können (mit einem signierten Nachweis darüber, wer sie durchgeführt hat) und Aktionen mit hohem Risiko erfordern, dass der Agent nachweist, dass ihm diese spezifische Befugnis delegiert wurde, oft mit einem Live-Schritt der menschlichen Zustimmung.

Vouches eigene Materialien kehren immer wieder zu zwei Beispielen zurück: einem Support-/Erstattungsagenten („eine Rückerstattung von 50 $ automatisch bearbeiten, aber für Beträge über 5.000 $ eine Genehmigung benötigen“) und einem Reisebuchungsagenten („Flugstatus ansehen, aber ohne Genehmigung keine Flüge buchen“). Dieses Repository baut das erste Beispiel real und Ende-zu-Ende auf.

Schnellstart

npm install
npm run verify   # deterministic, no LLM needed - proves the whole lifecycle works
npm run agent    # the real thing - a live Claude Agent SDK agent driving 3 scripted turns

npm run verify führt src/verify-lifecycle.ts aus: ein eigenständiges Skript, das jeden Teil des Lebenszyklus in einem Prozess durchläuft (Beweiserzeugung, Beweisverifikation, einen absichtlichen Manipulationstest, der fehlschlagen muss, die vollständige Schleife needs_authorization -> echte Consent-Server-Genehmigung -> automatisch angewendeter Wiederholungsversuch -> Erfolg) und pro Prüfung PASS/FAIL ausgibt. Kein API-Schlüssel erforderlich – es ruft nie ein LLM auf.

npm run agent führt src/agent.ts aus: einen echten Agenten, gebaut mit dem Claude Agent SDK, verbunden mit src/server.ts als MCP-Toolquelle über stdio. Er durchläuft drei Prompts – eine Bestellung prüfen, eine Rückerstattung von 30 $ ausstellen und eine Rückerstattung von 500 $ ausstellen – und stoppt beim dritten absichtlich beim Autorisierungslink. Diese Pause ist der Punkt: Der Agent sieht nie einen Beweis oder eine Berechtigung, er sieht nur ein Tool, das ihn manchmal bittet, einen Autorisierungslink an einen Menschen weiterzuleiten. Benötigt ANTHROPIC_API_KEY (oder eine authentifizierte claude-CLI-Sitzung).

Was in jeder Datei steckt

So passen Sie dies an Ihren eigenen MCP-Server an

Das Muster in kya-tools.ts lässt sich auf jeden MCP-Server verallgemeinern:

1. Umschließen Sie die Identität Ihres Servers: createKyaOsMiddleware({ identity, session: {...}, autoSession: true }, crypto).

2. Klassifizieren Sie jedes Tool. Schreibgeschützt oder mit geringem Risiko: kyaos.wrapWithProof('tool_name', handler) – über einen signierten Beweis zurechenbar, nicht eingeschränkt. Mit hohem Risiko: kyaos.wrapWithDelegation('tool_name', { scopeId, consentUrl, formatChallenge }, kyaos.wrapWithProof('tool_name', handler)) – blockiert, bis eine Delegationsberechtigung mit diesem Geltungsbereich vorgelegt wird.

3. Richten Sie consentUrl auf Ihre eigene Autorisierungsseite oder verwenden Sie consent-server.ts und public/consent.html unverändert wieder.

4. Umschließen Sie den delegationsgeschützten Handler mit formatAsConsentLink() (siehe kya-tools.ts), sodass eine genehmigte Berechtigung beim erneuten Versuch des Aufrufers automatisch angewendet wird – niemand muss jemals eine Berechtigung von Hand einfügen.

Das ist die Form eines Integrationsleitfadens, nicht nur ein Beweis, dass diese eine Demo läuft.

Warum simuliert, keine echte Integration

check_order_status und issue_refund arbeiten mit einem kleinen festen In-Memory-Datensatz – keine echten Bestellungen, keine echten Kunden, kein echter Zahlungsabwickler, nichts PCI/PII-Relevantes. Das, was hier demonstriert wird, ist KYA-OS-Identität und -Delegation, nicht E-Commerce- oder Zahlungsentwicklung, und eine echte Integration würde Datenverarbeitungs- und Sicherheitsfläche hinzufügen, ohne einen Nutzen für diese Geschichte zu bringen.

Was dies bewusst noch nicht abdeckt

• Checkpoint (Vouches Schicht zur Erkennung von Agent-Traffic) – es hat eine echte kostenlose Self-Service-Anmeldung, aber das ist ein persönlicher Schritt zur Kontoerstellung, der außerhalb des Rahmens dieses Repositories liegt.

• Mehrere Frameworks – Vouches eigene Dokumentation listet Next.js, Express, Python, HTML und direkte API auf. Dieses Repository ist nur Node/TypeScript; eine Express-Variante ist ein natürlicher nächster Schritt, da die API von @kya-os/mcp transportunabhängig ist.

• IdentiClaw / KnowThat.ai – die anderen beiden Schichten von Vouches KYA-Suite; ihre öffentlichen Dokumentationen sind noch dünn.

Basierend auf

@kya-os/mcp – MIT-lizenzierte Referenzimplementierung von KYA-OS für das Model Context Protocol, gespendet von Vouched an die Trusted AI Agents Working Group der Decentralized Identity Foundation.