Ihre autonomen Agenten lesen bereits Ihre Postfächer, buchen Aufträge, triagieren Tickets, buchen Flüge. Nachgelagerte Dienste haben keine Möglichkeit, die vier entscheidenden Fragen zu beantworten: Welcher Agent ruft an, wem gehört er, was darf er, wie widerruft man ihn? Die CodeB Business Wallet vergibt jedem Agenten eine DID, eine gespeicherte Fähigkeitsliste, widerrufbare ES256-Fähigkeits-Tokens signiert von Ihrem Mandanten-Aussteller sowie ein öffentliches Manifest für nachgelagerte Dienste. Aufbauend auf W3C DID Core, W3C VCDM 2.0, OpenID4VCI, HAIP Wallet Attestation und W3C Bitstring Status List. Kein neuer Stack. Keine neue Datenbank.
agent, Fähigkeits-Tokens, Agent-Manifest, Verify-Token-Endpunkt und Bitstring Status List Credential sind in der Referenzimplementierung heute produktiv. Fügen Sie in web-business-wallet.html einen Mitarbeiter mit der Rolle KI-Agent hinzu, generieren Sie ein Scope-Token und übergeben Sie es Ihrer Agent-Laufzeit.
Die letzten achtzehn Monate produktiver KI-Agent-Einführungen haben in jedem Team, mit dem wir gesprochen haben, dieselbe Lücke offengelegt.
Langlebige, entropiereiche Geheimnisse. Jeder Prozess auf der Maschine kann einen stehlen und wiederverwenden. Rotation ist eine manuelle Pflicht. Es gibt kein Eigentumssignal — der Schlüssel weiß nicht, dass er einem bestimmten Agenten, Modell oder Zweck gehört.
Besser als API-Schlüssel, aber immer noch undurchsichtig: Der nachgelagerte Server sieht eine Client-ID und ein JWT mit Scope. Er kann nicht beantworten, welcher meiner fünf Agenten dieses Token präsentierte, oder wofür der Agent gedacht war.
Das Model Context Protocol und A2A standardisieren, wie Agenten mit Tools und einander sprechen — keines beschreibt, wie der Server verifiziert, welcher Agent am Socket ist. Jedes Team schreibt seinen eigenen Identitätsklebstoff.
Der kommende EU-AI-Act fragt: Wer ist für die Handlungen eines Agenten verantwortlich? Wenn Ihr einziger Audit-Eintrag lautet „ein API-Aufruf landete um 09:12 mit einem Bearer-Token“, können Sie diese Frage nicht beantworten. Sie brauchen Agent-Ebene-Zuordnung von Anfang an.
Jeder Baustein existiert bereits in der CodeB Business Wallet. Dieses Feature verknüpft sie für einen Maschinenidentitäts-Anwendungsfall.
Jeder Agent erhält eine Fragment-DID unter seiner Wallet: did:web:tenant:business-wallets:acme#agent-e_abc123. Die Eigentümer-DID ist die Wallet selbst. Auflösbar über das DID-Dokument der Wallet.
Jedes Fähigkeits-Token ist ein Verifiable Credential im JWT-Format (ES256, W3C-VCDM-geprägte Payload). Nachgelagerte Dienste verifizieren mit dem öffentlichen Mandanten-Ausstellerschlüssel aus dem DID-Dokument.
HAIP §5.11 Wallet Attestation ist bereits je Mitarbeiter implementiert. Agenten erben dieselbe Attestierungsprimitive, wenn sie eine Wallet-Zugehörigkeit nachweisen müssen.
Kurzlebige (max. 24 h, je Agent konfigurierbar) ES256-JWTs mit typ=codeb-agent-token+jwt. Expliziter Scope-Claim. TTL vom Betreiber über agent_max_ttl_sec begrenzt.
Öffentliche Widerrufs-URL in jedem Agent-Manifest. Agent-Ebene-Widerruf per deactivate-agent sofort; token-genauer Widerruf per revoke-agent-token flippt das Bit unmittelbar.
Jede Ausstellung und jede Deaktivierung wird in das Wallet-Audit-Log geschrieben mit {ts, actor, action, target}. Als JSON herunterladbar. Rotiert bei 5000 Einträgen.
Öffnen Sie web-business-wallet.html, melden Sie sich per OIDC an, legen Sie eine Wallet für Ihr Unternehmen an. Sie werden automatisch als Direktor eingetragen.
Fügen Sie einen Mitarbeiter mit der Rolle „KI-Agent“ hinzu. Füllen Sie Modelltyp, Zweck, erlaubte Fähigkeiten und maximale Token-TTL aus.
Klicken Sie auf Fähigkeits-Token generieren. Wählen Sie eine Scope-Teilmenge. Kopieren Sie das ES256-JWT. Geben Sie es Ihrer Agent-Laufzeit als Bearer-Credential.
Ihr Server ruft verify-agent-token auf oder holt das öffentliche Agent-Manifest, um den Ausstellerschlüssel zu pinnen, und verifiziert Tokens dann offline.
Klicken Sie in der UI auf Deaktivieren. Das Manifest liefert dann active:false. Alle neuen Verify-Aufrufe scheitern mit agent_deactivated.
POST /business-wallet.ashx?action=mint-agent-token&bw=acme-ltd
Authorization: Bearer <OIDC-Token des Direktors>
Content-Type: application/json
{
"empId": "e_abc123",
"ttl_sec": 3600,
"scope": ["list-docs","download-doc","verify-vc"],
"audience": "https://downstream.example/api",
"purpose_hint": "Q3 Rechnungs-Triage-Batch"
}POST https://tenant.example/business-wallet.ashx?action=verify-agent-token
Content-Type: application/json
{"token": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImNvZGViLWFnZW50LXRva2VuK2p3dCJ9..."}
# Antwort
{
"verified": true,
"reason": "ok",
"agent_did": "did:web:tenant.example:business-wallets:acme-ltd#agent-e_abc123",
"owner_did": "did:web:tenant.example:business-wallets:acme-ltd",
"scope": ["list-docs","download-doc","verify-vc"],
"exp": 1786320000,
"typ": "codeb-agent-token+jwt"
}GET https://tenant.example/business-wallet.ashx?action=agent-manifest&bw=acme-ltd&emp=e_abc123
# Liefert Name, Modell, Fähigkeiten, Eigentümer-DID, Aussteller-JWK, Widerrufs-URL.
# Verifier pinnen issuer_key.x und issuer_key.y einmal und verifizieren dann offline.| Frage | API-Schlüssel | OAuth-Dienstkonten | Business-Wallet-Agent-Identität |
|---|---|---|---|
| Welcher Agent ruft an? | nein | client-id, nicht agent | Agent-DID |
| Wem gehört der Agent? | nein | Mandant | Eigentümer-DID + Wallet |
| Welches Modell / welcher Zweck? | nein | nein | Manifest-Feld |
| Expliziter Scope je Token? | nein | ja | ja, durch gespeicherte Caps begrenzt |
| Rotation | manuell | Bibliothek | ttl_sec-Klemme |
| Sofortiger Widerruf | Rotieren + Redeploy | Widerrufsliste | deactivate-agent + revoke-agent-token |
| Öffentlicher Verifier-Endpunkt | nein | JWKS | verify-agent-token + manifest |
| Standardbasiert | nein | OAuth 2.1 | W3C DID + VCDM + Bitstring |
| Portabel über Dienste hinweg | geteiltes Geheimnis leck | je Integration | Bearer-JWT überall |
| Passt zu MCP + A2A | nein | Aufsatz | ja — transportagnostisch |
Ein Agent liest geteilte Postfächer, legt Rechnungen an die Buchhaltung ab, markiert Verträge für die Rechtsabteilung, entwirft Antworten auf Routine-Kundenanfragen. Der Mail-Server, die Buchhaltungs-API und das Ticket-Tool müssen alle wissen: Wer hat diese Aktion autorisiert und kann sie rückgängig gemacht werden? Ein Fähigkeits-Token mit Scope read-mail,file-invoice,create-ticket gibt jedem nachgelagerten Dienst eine maschinell verifizierbare Antwort.
Ein Agent kauft Cloud-Ressourcen ein, verhandelt SaaS-Verlängerungen, erwirbt API-Guthaben unter einem Ausgabenlimit. Jede Bestellung trägt die Agent-DID, die Eigentümer-DID und einen expliziten purchase-goods,max-eur-500-Scope. Lieferanten-Audit-Trails ordnen Ausgaben nun korrekt zu. Der Notaus ist einen deactivate-agent-Aufruf entfernt.
Hundert Robotic-Process-Automation-Bots laufen über Nacht gegen SAP, Salesforce und ein On-Prem-AS/400. Statt eines geteilten Dienstkontos pro System erhält jeder Bot sein eigenes Fähigkeits-Token, das exakt auf die Aktionen seines Workflows beschränkt ist. Wenn ein Bot Amok läuft, ist der Widerruf bot-bezogen — nicht flotten-bezogen.
Coding-Agenten committen Patches, öffnen PRs, starten CI-Pipelines, deployen ins Staging. Jede Aktion ist vom persönlichen Agenten des Entwicklers signiert. Wenn um 02:00 ein verdächtiger Commit erscheint, sagt das Audit-Log Ihnen, welcher Agent, welcher Eigentümer, welcher Scope — nicht nur „das CI-Dienstkonto“.
Ein öffentlicher Agent beantwortet Rechnungsfragen, erstattet Beträge bis zu einer Schwelle, eskaliert Grenzfälle an Menschen. Nachgelagerte Erstattungs- und CRM-Systeme verifizieren das eingehende Token, sehen den Scope issue-refund,max-eur-100 und erfüllen oder verweigern entsprechend. Kein geteiltes Credential; kein Weg für einen feindlichen Prompt, Privilegien über den generierten Scope hinaus zu eskalieren.
Nichts hier ist erfunden. Diese Schicht ist eine pragmatische Zusammenstellung veröffentlichter Spezifikationen, angewandt auf den KI-Agent-Anwendungsfall.
Jeder Agent-Identifier ist ein wohlgeformter did:web mit Fragment. Eigentümer-DIDs sind unter /business-wallets/<cid>/did.json auflösbar.
Die Agent-Statusliste ist ein BitstringStatusListCredential im Format des W3C Verifiable Credentials Data Model 2.0.
Der Mandanten-Aussteller, der Fähigkeits-Tokens signiert, ist derselbe ES256-Schlüssel, der OID4VCI-Credential-Offers signiert. Ein Vertrauensanker, viele Verwendungen.
Agenten können eine Wallet-Instance-Attestation vorlegen, wenn der nachgelagerte Dienst nachweisen will, dass der Aufrufer in einer bestimmten Wallet läuft.
Pro-Mandant-Widerrufs-Credential veröffentlicht unter einer stabilen öffentlichen URL und aus jedem Agent-Manifest verlinkt.
Fähigkeits-Tokens sind Bearer-Credentials auf der Leitung. Sie funktionieren mit jedem MCP-Tool-Server oder A2A-Dispatcher, der bereits Bearer-Authentifizierung akzeptiert.
Aufgebaut auf derselben Architektur wie der CodeB-EUDI-Wallet-Stack: eIDAS-2.0-Primitive, ARF-3.0-Alignment und zukunftssicher für das entstehende EU-Business-Wallet-Vokabular.
Ein Fähigkeits-Token ist ein Bearer-JWT: Jeder OAuth-2.1-Resource-Server, der JWT-Bearer-Tokens akzeptiert und einen JWK von einer Discovery-URL abrufen kann, akzeptiert ein Agent-Token unverändert.
Damit nachgelagerte Dienste die vier entscheidenden Fragen beantworten können: Welcher Agent ruft an, wem gehört er, was darf er tun und wie schaltet man ihn ab? API-Schlüssel beantworten keine davon. OAuth-Dienstkonten beantworten nur die ersten beiden, und ihre Anmeldedaten sind langlebig und werden manuell rotiert. Eine auf verifizierbaren Nachweisen basierende Identität beantwortet alle vier — mit Widerruf, Audit und kryptografischem Eigentum von Haus aus.
Ein Dienstkonto ist ein statisches gemeinsames Geheimnis, das jeder Prozess auf der Maschine stehlen und wiederverwenden kann. Ein Fähigkeits-Token ist ein kurzlebiges ES256-JWT, signiert von einem Mandanten-Ausstellerschlüssel. Es trägt die Agent-DID, die Eigentümer-DID und einen expliziten Scope; der nachgelagerte Verifier ruft das öffentliche Agent-Manifest ab, um zu prüfen, ob der Agent noch aktiv ist und den öffentlichen Ausstellerschlüssel zu erhalten. Nichts wird geteilt. Nichts muss beim Verifier gespeichert werden.
Ja. MCP standardisiert, wie ein Agent mit einem Tool-Server spricht; A2A standardisiert, wie Agenten miteinander sprechen. Keines davon spezifiziert, wie der nachgelagerte Server beweist, welcher Agent am anderen Ende des Sockets ist. Die CodeB-Agent-Identitätsschicht schließt diese Lücke: Der Agent präsentiert ein Bearer-Fähigkeits-Token, der Server ruft verify-agent-token auf, fertig. Sie ist transportagnostisch und funktioniert mit MCP, A2A, HTTP-APIs, gRPC, Message Queues und allem anderen, das ein Bearer-Token transportieren kann.
Ja. Rufen Sie deactivate-agent in der Wallet auf. Das öffentliche Agent-Manifest beginnt active:false zurückzugeben, und jede verify-agent-token-Prüfung für diese DID scheitert mit reason: agent_deactivated. Bestehende Tokens sind kryptografisch gültig, aber der Agent wird verweigert — genauso wie bei einem OAuth-Widerruf. Token-genauer Widerruf per W3C Bitstring Status List ist jetzt live: revoke-agent-token setzt das Bit sofort.
Ein ES256 (ECDSA P-256 SHA-256) Compact-Serialisation-JWT mit dem Header typ=codeb-agent-token+jwt. Payload: iss (Eigentümer-DID), sub (Agent-DID), agent_did, owner_did, role, scope (Array), iat, nbf, exp, wallet_id (URN), wallet_link, manifest, did_doc, optional aud und purpose_hint, sowie eine zufällige jti. Signiert vom Mandanten-Ausstellerschlüssel, der über das DID-Dokument auflösbar ist.
Nein. verify-agent-token und agent-manifest sind öffentliche Endpunkte. Ein nachgelagerter Dienst ruft das Manifest einmal ab (60 s Cache), pinnt den Ausstellerschlüssel (JWK) und kann dann Tokens vollständig offline verifizieren. Alternativ kann er bei jeder Anfrage verify-agent-token aufrufen, um zusätzlich eine Aktiv-Flag-Prüfung zu erhalten, ohne selbst Zustand halten zu müssen.
did:web:<tenant>:business-wallets:<companyId>#agent-<empId>. Die Wallet-DID selbst ist unter /business-wallets/<companyId>/did.json auflösbar; das #agent-*-Fragment identifiziert einen bestimmten Agenten innerhalb dieser Wallet. Eigentümer-DIDs sind stets ohne Fragment.
Jede der lesenden Wallet-Aktionen (list-docs, download-doc, list-vc, verify-vc, get-state, list-my-wallets) sowie jeden eigenen Fähigkeits-Slug, den Sie definieren wollen. Eigene Slugs sind für die Wallet opak: sie trägt sie nur im Token, und Ihr nachgelagerter Dienst interpretiert sie. Mutierende Wallet-Operationen (upload-doc, add-employee, wallet-export etc.) sind für Agenten dauerhaft ausgeschlossen — per Designentscheidung.