Kenne deinen Agenten: Menschliche Bindung an KI-Agenten

Wichtige Erkenntnisse

• „Know Your Agent“ (KYA) ist nicht durch die Benennung eines Agenten gelöst. Die dauerhafte Kontrolle ist eine Delegationskette, die eine authentifizierte Person, einen registrierten Client, gewährte Scopes, einen Organisationskontext und jede daraus resultierende Aktion miteinander verbindet.
• Didits gehosteter Model Context Protocol (MCP)-Endpunkt stellt 115 Tools in 19 Domänen bereit und verwendet Open Authorization (OAuth) 2.1 mit Proof Key for Code Exchange (PKCE) und dynamischer Client-Registrierung.
• Das MCP agiert als der angemeldete Didit-Benutzer. Es erbt die Organisationsrolle dieses Benutzers, sodass ein verbundener Agent keine Berechtigungen erlangen kann, die die Person nicht bereits hatte.
• Ein in einer Konfigurationsdatei gespeicherter Anwendungsschlüssel beweist den Besitz eines Anmeldeinformationen, nicht aber, welcher Mensch eine bestimmte Aktion delegiert hat. Gemeinsam genutzte Schlüssel fassen mehrere Operatoren und Agenten zu einer einzigen Anwendungsidentität zusammen.
• Verantwortlichkeit erfordert sowohl Durchsetzung als auch Nachweis: bereichsbezogene Tokens und Rollenprüfungen vor einer Aktion, dann Audit-Aufzeichnungen, die zeigen, wer was geändert hat.

Didit hat den Mechanismus bereits ausgeliefert. Sein gehosteter MCP-Server verbindet einen KI-Client über einen angemeldeten Benutzer mit Identitäts- und Betrugsoperationen, anstatt den Agenten als anonymen Inhaber eines Anwendungsgeheimnisses zu behandeln. Der Endpunkt ist kostenlos, verwendet zustandsloses Streamable HTTP und stellt 115 Tools bereit. Die Implementierung ist auch im öffentlichen MIT-lizenzierten GitHub-Repository verfügbar.

Dieses Artefakt ändert die nützliche Frage. Anstatt nach einer weiteren Definition von KYA zu fragen, fragen Sie: Wenn ein Agent eine Verifizierungssitzung erstellt, eine Entscheidung liest oder Arbeitsbereichsdaten ändert, was beweist, welche Person dies autorisiert hat, was diese Person erlaubt hat und welche Organisation die Aktion akzeptiert hat?

Menschliche Bindung ist eine Delegationskette

Ein Agentenname, eine Modellkennung, ein öffentlicher Schlüssel oder eine Software-Attestierung können helfen, den Maschinenakteur zu identifizieren. Keines davon allein kann festlegen, wer für das, was der Agent tut, verantwortlich ist. Menschliche Bindung benötigt eine Kette mit verschiedenen Gliedern:

• Prinzipal: der authentifizierte Benutzer oder Dienstinhaber, in dessen Auftrag der Agent handelt.
• Client: die KI-Anwendung, die Zugriff angefordert hat.
• Delegation: die dem Client gewährten Scopes und Zustimmungen.
• Autorisierungskontext: die auf die Anfrage angewendete Organisationsrolle und Anwendungsgrenze.
• Nachweis: eine überprüfbare Aufzeichnung der Aktion und ihres Ergebnisses.

Jedes Glied beantwortet eine andere Frage. Die Authentifizierung sagt, wer sich angemeldet hat. OAuth sagt, welcher Client delegierten Zugriff erhalten hat. Scopes sagen, welche Arten von Operationen genehmigt wurden. Rollen sagen, was der Benutzer innerhalb der Organisation tun darf. Audit-Aufzeichnungen sagen, was tatsächlich passiert ist. Das Zusammenfassen dieser Kontrollen zu einem einzigen „verifizierten Agenten“-Abzeichen verbirgt den wichtigsten Teil: Autorität ist kontextabhängig und widerrufbar.

Ein vertrauenswürdiger Agent ist nicht nur identifizierbar. Er muss einen ununterbrochenen Pfad von einem verantwortlichen Prinzipal zu einer spezifischen, erlaubten Aktion aufzeigen können.

Warum ein Schlüssel in einer Konfigurationsdatei den Verantwortlichkeitstest nicht besteht

Ein Anwendungs-API-Schlüssel kann für eine kontrollierte Server-zu-Server-Integration geeignet sein. Er ist jedoch allein kein Mechanismus zur Mensch-zu-Agent-Bindung. Ein kopierter Schlüssel beantwortet normalerweise eine Frage: „Besitzt dieser Anrufer einen für diese Anwendung akzeptierten Anmeldeinformationen?“ Er beantwortet nicht, wer den Agenten gestartet hat, wer die aktuelle Aufgabe genehmigt hat oder ob zwei Anrufe mit demselben Schlüssel von verschiedenen Personen stammten.

Die Fehler sind vorhersehbar. Teams teilen einen Schlüssel über lokale Umgebungen hinweg. Ein Agentenprozess erbt ihn aus einer Konfigurationsdatei. Ein zweiter Agent erhält eine Kopie. Protokolle schreiben dann jeden Anruf demselben Anwendungs-Anmeldeinformationen zu. Das Widerrufen dieser Anmeldeinformationen unterbricht jede Workload, die sie verwendet, während das individuelle Delegationsereignis unklar bleibt.

Didit bietet bewusst keinen Anwendungsschlüsselpfad für seinen gehosteten MCP-Endpunkt an. Backend-Integrationen können Didits REST-APIs weiterhin mit Anwendungs-Anmeldeinformationen verwenden, aber der Remote-MCP-Zugriff erfordert einen Benutzer-OAuth-Fluss. Diese Trennung ist wichtig: Das REST-Anmeldeinformation repräsentiert eine Anwendungs-Integration; das MCP-Token repräsentiert den delegierten Zugriff eines angemeldeten Benutzers.

OAuth 2.1, PKCE und dynamische Client-Registrierung

OAuth ist das Delegations-Grundelement in diesem Design. Der Ablauf übergibt das Benutzerpasswort nicht an den Agenten und platziert kein wiederverwendbares Plattformgeheimnis in der MCP-Konfiguration. Stattdessen erhält der KI-Client ein eingeschränktes Zugriffstoken, nachdem sich der Benutzer bei Didit authentifiziert und den Zugriff genehmigt hat.

1. Client registrieren

Die dynamische Client-Registrierung ermöglicht es einem kompatiblen MCP-Client, sich beim Didit-Autorisierungsserver zu registrieren, ohne dass eine manuelle Vorab-Bereitstellung einer Client-ID erforderlich ist. Dies gibt dem Autorisierungsserver eine eindeutige Client-Registrierung, an die er Zugriff ausgeben kann. Die Registrierung identifiziert den OAuth-Client; sie bescheinigt allein nicht, dass die Software des Clients vertrauenswürdig ist.

2. Die Autorisierungsantwort an den Client binden

PKCE erstellt einen einmaligen Verifizierer und eine Challenge für den Autorisierungsversuch. Der Client, der den Flow startet, muss den Verifizierer beim Austausch des Autorisierungscodes vorlegen. Dies begrenzt den Wert eines abgefangenen Codes, da ein anderer Prozess ihn ohne den Verifizierer nicht einlösen kann.

3. Authentifizieren und zustimmen

Der Benutzer meldet sich bei der Didit Business Console an, die als Autorisierungsserver fungiert, und genehmigt die angeforderten Scopes. Didit bewirbt didit:verification für Verifizierungsoperationen und didit:management für die Arbeitsbereichsverwaltung. Ein Client sollte nur den für die Aufgabe erforderlichen Scope anfordern.

4. Jeden Aufruf validieren

Der gehostete MCP-Ressourcenserver validiert das Bearer-Token, bevor er einen Tool-Aufruf ausführt. Das validierte Benutzer-Token und der Organisationskontext werden mit der Anfrage an Didit übertragen. Der nachgeschaltete Dienst bewertet dann die vorhandene Rolle und Berechtigungen für diesen Benutzer. Das Ergebnis sind „acting-as-user“-Semantiken, keine neue Superuser-Identität, die für den Agenten erstellt wurde.

Der MCP-Authentifizierungsleitfaden dokumentiert den Ablauf, während die MCP-Übersicht den gehosteten Endpunkt und das Client-Modell erklärt.

Das Handeln als Benutzer macht die Autorität lesbar

Angenommen, ein Compliance-Mitarbeiter verbindet einen KI-Client mit Didit. Der Client ruft zuerst didit_context_get auf, das die Organisationen und Anwendungen zurückgibt, auf die der angemeldete Benutzer zugreifen kann. Wenn der Benutzer eine eindeutige Organisation und Anwendung hat, kann der Kontext automatisch aufgelöst werden. Wenn mehrere verfügbar sind, kann der Vorgang auf eine explizite Organisation und Anwendung eingegrenzt werden.

Der Agent kann dann didit_session_create aufrufen, um eine Verifizierungssitzung zu erstellen, und didit_session_get_decision, um deren Ergebnis abzurufen. Dies sind echte, domänenspezifische Tool-Namen im aktuellen MCP-Katalog. Ein Benutzer, dem die erforderliche Berechtigung fehlt, erhält diese nicht durch die Verbindung eines Agenten; die gleiche Organisationsautorisierungsgrenze gilt weiterhin.

Dies ist der zentrale Unterschied zu einem gemeinsam genutzten Anmeldeinformationen. Im OAuth-Modell kommt die Anfrage als bekannter Benutzer an, der über einen registrierten Client mit deklarierten Scopes arbeitet. Im Shared-Key-Modell sieht das nachgeschaltete System das Anwendungs-Anmeldeinformationen, während der Mensch und der Agent hinter einem bestimmten Aufruf nicht zu unterscheiden bleiben, es sei denn, eine separate Steuerungsebene liefert diesen Kontext.

Auditierbarkeit: von „wer darf handeln?“ zu „wer hat was getan?“

Autorisierung verhindert eine außerplanmäßige Aktion. Auditierbarkeit erklärt eine Aktion, nachdem sie stattgefunden hat. Didit stellt didit_audit_log_list zur Verfügung, damit ein autorisierter Benutzer Anwendungs-Audit-Einträge überprüfen kann, die beschreiben, wer was geändert hat. Da jede gehostete MCP-Anfrage das Bearer-Token des angemeldeten Benutzers und den aufgelösten Organisationskontext enthält, ist die Aktion diesem Aufrufer und nicht einem anonymen Agentenprozess zuzuordnen.

Eine vollständige forensische Aufzeichnung sollte auch agentenseitige Beweise aufbewahren. Für Workflows mit hoher Auswirkung sollten die Agenten-Lauf-ID, die Client-Registrierung, der angeforderte Scope, die Zielorganisation und -anwendung, der Tool-Name, der Zeitstempel, der Genehmigungsstatus und eine sichere Darstellung von Eingaben und Ausgaben protokolliert werden. Protokollieren Sie keine Zugriffstokens oder sensiblen Identitäts-Payloads. Der Plattform-Audit-Trail und das Agenten-Ausführungsprotokoll sollten korrelierbar sein, ohne Geheimnisse oder regulierte personenbezogene Daten zu duplizieren.

Zuschreibung ist nicht dasselbe wie Nichtabstreitbarkeit, und ein Audit-Log ist kein Ersatz für das Prinzip der geringsten Rechte. Die Kontrollen verstärken sich gegenseitig:

• Verwenden Sie kurzlebigen Zugriff und kontrollierte Aktualisierungen anstelle von permanenten, gemeinsam genutzten Anmeldeinformationen.
• Gewähren Sie den engsten OAuth-Scope und die Organisationsrolle mit den geringsten Rechten.
• Verlangen Sie eine menschliche Bestätigung für destruktive oder ungewöhnlich wirkungsvolle Operationen.
• Halten Sie den Organisations- und Anwendungskontext explizit, wenn mehr als ein Ziel verfügbar ist.
• Widerrufen Sie die Benutzersitzung oder Client-Gewährung, wenn die Delegation beendet werden soll.
• Überwachen Sie Audit-Aufzeichnungen auf unerwartete Akteure, Tools, Ziele oder Zeitpunkte.

Was die Bindung beweist – und was nicht

Dieses Muster beweist, dass ein authentifiziertes Didit-Konto einem OAuth-Client einen bereichsbezogenen Zugriff delegiert hat und dass jede Anfrage mit den Organisationsberechtigungen dieses Benutzers bewertet wird. Es schafft eine praktische Verantwortlichkeit für ein Konto und eine überprüfbare Kette für Plattformaktionen.

Es beweist nicht automatisch, dass der Kontoinhaber eine verifizierte zivile Identität besitzt, dass die genehmigte Client-Binärdatei nicht modifiziert wurde oder dass der Mensch jeden Schritt aktiv überwacht. Dies erfordert zusätzliche Sicherheiten. Wenn eine rechtliche Identitätssicherung erforderlich ist, verifizieren Sie den Prinzipal während des Onboardings mit Know Your Customer (KYC)-Kontrollen und binden Sie dieses Ergebnis an das Konto. Wenn die Softwareherkunft wichtig ist, fügen Sie eine Client-Attestierung und signierte Releases hinzu. Wenn die Anwesenheit wichtig ist, fordern Sie eine Step-up-Genehmigung zum Zeitpunkt der sensiblen Aktion an.

Diese geschichtete Ansicht hält KYA ehrlich. Agentenidentität, menschliche Identität, delegierte Autorisierung, Laufzeitrichtlinien und Audit-Beweise sind verwandte Kontrollen, keine austauschbaren Bezeichnungen.

Eine funktionierende Implementierung, die Sie prüfen können

Didits Implementierung bietet eine konkrete Referenz für Teams, die dieselbe Verantwortlichkeitsgrenze entwerfen. Der gehostete Server authentifiziert sich als der angemeldete Didit-Benutzer, erbt die Organisationsrolle dieses Benutzers und wendet diese Identität auf jeden Tool-Aufruf an. Seine 115 gehosteten Tools umfassen 19 Domänen, von Kontext- und Verifizierungssitzungen bis hin zu Workflows, Organisationen, Analysen und Audit-Logs. Der aktuelle Tool-Katalog listet die genaue Oberfläche auf.

Für den Produktkontext kostet das vollständige KYC-Paket 0,33 $ und kombiniert ID-Verifizierung, passive Lebenderkennung, Gesichtsabgleich und IP-Analyse. Didit beinhaltet 500 kostenlose Verifizierungen pro Monat und wird von über 2.000 Unternehmen in Produktion genutzt. Der MCP-Server selbst ist kostenlos, sodass Teams das Delegations- und Berechtigungsmodell bewerten können, ohne eine separate Connector-Gebühr hinzuzufügen.

Um zu sehen, wie dieser Mechanismus in breitere Agenten-Workflows passt, lesen Sie, wie das Identitäts- und Betrugs-MCP für KI-Agenten funktioniert und die Didit MCP-Tool-Referenz.

Binden Sie den Agenten, bevor Sie der Aktion vertrauen

Das schwierige Problem bei der Agentenidentität ist nicht die Erfindung eines dauerhaften Namens für Software. Es ist die Bewahrung der menschlichen Verantwortlichkeit, wenn Software Schnittstellen überwindet und mit Maschinengeschwindigkeit agiert. OAuth 2.1 liefert delegierten Zugriff. PKCE schützt den Autorisierungsaustausch. Die dynamische Client-Registrierung identifiziert den verbindenden Client. Scopes und Organisationsrollen beschränken die Autorität. Audit-Aufzeichnungen machen das Ergebnis überprüfbar.

Sie können die Architektur im Didit MCP-Repository überprüfen, die Authentifizierungsdokumentation einsehen oder Didit mit Claude verbinden. Der nützliche Test ist einfach: Können Sie für jede vorgeschlagene Agentenaktion den verantwortlichen Benutzer, den Client, den gewährten Scope, die Organisationsgrenze und die resultierenden Audit-Beweise identifizieren? Wenn ein Glied fehlt, ist der Agent nicht vollständig gebunden.