Was sich verändert hat und was sich in Authentifizierung und Identität für agentische Apps nicht verändert hat

Kürzlich habe ich diesen Artikel durchgesehen, und Agenten-Authentifizierung wurde erwähnt:

Wir sehen Andeutungen dessen, wie dies aussehen könnte. Die neueste MCP-Spezifikation enthält beispielsweise ein Autorisierungs framework, das auf OAuth 2.1 basiert und die Möglichkeit signalisiert, zu Scoped, widerrufbaren Tokens für KI-Agenten statt roher Geheimnisse überzugehen. Wir können uns ein Szenario vorstellen, in dem ein KI-Agent nicht Ihre eigentlichen AWS-Schlüssel erhält, sondern stattdessen ein kurzlebiges Anmeldeinformation oder ein Fähigkeitstoken, das ihm erlaubt, eine eng definierte Aktion durchzuführen.

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

Viele Freunde und Menschen, die nicht im Bereich Sicherheit oder CIAM tätig sind, haben den Eindruck, dass dies etwas Neues ist, aber das ist es definitiv nicht. OAuth ist ein standardisiertes, tokenbasiertes Autorisierungsprotokoll, das Tokens mit definierten Berechtigungen (Zugriffstokens) einbezieht. Diese sind zeitkritisch und bereichsbegrenzt, was Sicherheit und angemessene Zugriffskontrolle zu Ressourcen und Diensten sicherstellt. Im globalen SaaS-Markt (vor KI) sind die meisten professionellen Identitätslösungen bereits darauf aufgebaut.

Wenn Sie Ihr Google-Konto mit einer Drittanbieter-App wie Notion oder Zoom verbinden, verwendet es OAuth, um nur die erforderlichen Berechtigungen anzufordern, wie etwa den Zugriff auf Ihren Kalender oder Ihre Kontakte, ohne jemals Ihr Google-Passwort preiszugeben. Sie können diesen Zugriff jederzeit über Ihre Google-Kontoeinstellungen widerrufen. Dieses delegierte Zugriffsmuster ist genau das, wofür OAuth entwickelt wurde, und es ist dieselbe Grundlage, die heute auf agentische Anwendungen ausgeweitet wird.

Was sich in der agentischen Welt nicht ändert#

Authentifizierung ist nicht neu, basiert immer noch auf OAuth 2.1#

Es gibt zwei große aufkommende Protokolle: MCP und A2A.

• MCP konzentriert sich auf die Interaktion zwischen LLMs und den Werkzeugen und dem Kontext Ihrer App.
• A2A konzentriert sich auf die Ermöglichung von Aufgaben-Austausch zwischen Agenten.

Aber wenn es um Authentifizierung und Autorisierung geht, basieren beide immer noch auf bewährten Industriestandards wie OAuth.

MCP-Autorisierungsserver MÜSSEN OAuth 2.1 mit geeigneten Sicherheitsmaßnahmen für sowohl vertrauliche als auch öffentliche Clients implementieren.

Der A2A-Client ist verantwortlich für das Erlangen der notwendigen Anmeldeinformationen (z. B. OAuth 2.0-Tokens, API-Schlüssel, JWTs) durch Prozesse, die außerhalb des A2A-Protokolls selbst liegen. Dies könnte OAuth-Flüsse (Autorisierungscode, Client-Anmeldedaten), sichere Schlüsselverteilung usw. umfassen.

Wie Google es ausdrückt:

Statt neuartige, proprietäre Standards für Sicherheit und Betrieb zu erfinden, strebt A2A danach, sich nahtlos in bestehende Unternehmensinfrastrukturen und weit verbreitete Best Practices zu integrieren.

Benötigt ein Agent eine eindeutige Identität?#

Viel Hype und FOMO-Inhalte pushen die Idee, dass wir, da Agenten immer häufiger werden, ein System zur Verwaltung von Agenten-Identitäten benötigen.

Die Antwort ist: ja und nein.

Ja, weil wir eine neue Ebene zwischen Mensch und Maschine einführen. Es gibt echte Bedürfnisse:

• Agenten zu verwalten und zu identifizieren
• Eindeutige IDs zu vergeben
• Protokolle zu verfolgen
• Aktionen zu prüfen (um zu wissen, ob eine Aufgabe von einem Menschen oder einem Agenten durchgeführt wurde)

In den meisten technischen Fällen besteht jedoch kein Bedarf, ein formales Konzept der „Agenten-Identität“ zu schaffen.

Agent ≠ Benutzer, ≠ Dienstkonto.

Hinter jedem Agenten steht immer noch ein Benutzer und die Benutzeridentität reicht in der Regel aus.

Heutzutage:

• Handeln die meisten Agenten basierend auf Benutzerautorisierung (z.B. OAuth-Tokens)
• Führen Logik aus oder machen einen API-Aufruf
• Führen kurzlebige, einmalige Aufgaben aus (ohne Bedarf an Verfolgung)

In diesem Sinne ist der Agent nur ein Werkzeug als Funktion und benötigt keine global eindeutige ID.

Zum Beispiel:

• Ein GPT-Agent, der Ihren Kalender-API aufruft, benötigt nur die Zugriffsrechte, die Sie gewährt haben.
• Ein LangChain-Agent benötigt keine Identität, solange er die richtigen Werkzeuge aufrufen kann, funktioniert er.

Schon vor der KI hatten wir das Konzept von Maschine-zu-Maschine (M2M) Auth.

M2M bedeutet automatisierter Datenaustausch zwischen Diensten, ohne menschlichen Eingriff.

In diesem Kontext verwendet die Authentifizierung oft eine Client-App oder ein Dienstkonto.

Wenn Sie wirklich möchten, dass Ihr Agent eine Identität hat (zur Überprüfung usw.), können Sie die App-ID verwenden und das ist genug.

Sie müssen immer noch die Architektur Ihres Produkts definieren#

Das hat sich nicht geändert. Egal, ob Ihr Produkt Agenten beinhaltet oder nicht, die Architektur Ihres Identitätssystems hängt davon ab, wer Ihre Benutzer sind und wie Ihr System mit ihnen interagiert.

Wenn Sie ein Verbrauchererzeugnis mit Agenten-Fokus entwickeln: Sie benötigen leichtgewichtige Anmeldemethoden (E-Mail, Telefon, soziales Login) und einen einheitlichen Benutzerpool, um die Individuen zu verwalten, die mit Ihrer App und ihren Agenten interagieren. Agenten handeln im Auftrag dieser Benutzer mit delegierten Tokens (z.B. über OAuth).

Beispiel:

Stellen Sie sich vor, Sie entwickeln einen KI-gestützten Terminplanungsassistenten oder einen KI-gesteuerten Kalenderbot.

Jeder Benutzer meldet sich mit seinem persönlichen Google-Konto an. Ihr System verwendet OAuth, um die Erlaubnis zu erhalten, auf deren Kalender zuzugreifen. Der Agent hat keine eigene Identität, er nutzt das Token des Benutzers, um Meetings zu planen, Verfügbarkeiten zu prüfen oder Erinnerungen zu senden. Die Identitätsarchitektur ist einfach: ein globaler Benutzerpool, Token-Speicherung und Zustimmungverfolgung pro Benutzer.

Wenn Sie eine B2B-Agentenplattform erstellen:

Sie müssen die Identität auf Organisationsebene unterstützen, nicht nur auf individueller Benutzerebene. Dazu gehört:

1. SSO für Unternehmenskunden
2. Arbeitsplatz- oder Mandantenebene Trennung
3. Agenten-Delegationsrichtlinien auf Organisationsebene (z.B. Steuerung dessen, was Agenten über Teams hinweg tun können)
4. Admin-Level Sichtbarkeit und Protokolle für alle Agentenaktivitäten im Namen von Mitarbeitern

Beispiel:

Stellen Sie sich vor, Sie entwickeln eine Plattform, die KI-Agenten bereitstellt, um interne Arbeitsabläufe zu automatisieren — wie einen Sicherheitsanalysten-Bot, der Protokolle überwacht und Warnungen sendet, oder einen Vertriebsassistenten, der E-Mails aus CRM-Daten erstellt.

Jedes Unternehmen, das Ihre Plattform nutzt, möchte dass:

1. Mit ihrem vorhandenen SSO eingeloggt wird
2. Gesteuert wird, was die Agenten zugreifen können (z.B. interne Werkzeuge, Dokumentsysteme)
3. Ersichtlich ist, welcher Agent welche Aufgabe ausgeführt hat, unter welcher Benutzerauthorisierung

In diesem Fall muss Ihre Identitätsarchitektur ein Multi-Tenant-Design, spezifische Berechtigungen für Agenten und organisationsspezifische Richtlinien unterstützen. Agenten handeln weiterhin im Namen von Benutzern, aber die Berechtigungen und Identitätsgrenzen werden pro Geschäftsmieter durchgesetzt.

In beiden Fällen definiert das Identitätsmodell, wie Agenten operieren, was sie zugreifen können, und wie Ihr System Verantwortung sicherstellt.

Nutzen Sie diesen Leitfaden, um Ihre Identitäts- und Produktarchitektur zu planen.

https://docs.logto.io/introduction/plan-your-architecture/b2c

https://docs.logto.io/introduction/plan-your-architecture/b2b

Sie benötigen immer noch Sicherheitsebenen, um Ihre agentengesteuerten Apps sicher zu halten#

Unabhängig davon, ob es sich um eine Agenten-App handelt oder nicht, sind diese grundlegenden Sicherheitsebenen notwendig, um Ihre Benutzer und Systeme zu schützen:

• Multi-Faktor-Authentifizierung (MFA)

  Verhindert unbefugten Zugriff, selbst wenn Anmeldeinformationen kompromittiert werden.

  Beispiel: Wenn ein Agent Ihnen hilft, eine riskante Aktion auszuführen, wie eine Transaktion durchzuführen oder Identitätseinstellungen zu ändern, sollte es einen Menschen im Prozess behalten und MFA verwenden, um die Aktion zu bestätigen, bevor fortgefahren wird.

• CAPTCHA

  Blockiert automatisierten Missbrauch wie Credential Stuffing oder bot-getriebene Anmeldungen.

  Beispiel: Zeigen Sie das CAPTCHA nach drei fehlgeschlagenen Anmeldeversuchen, um Brute-Force-Angriffe zu verhindern.

• Rollenbasierte Zugriffskontrolle (RBAC)

  Stellt sicher, dass Benutzer und Agenten nur auf das zugreifen, was ihnen erlaubt ist.

  Beispiel: Ein KI-Assistent in einem Arbeitsbereich eines Unternehmens kann Kalenderereignisse lesen, aber nicht auf Abrechnungsdaten zugreifen, es sei denn, es ist ihm ausdrücklich eine höhere Rolle zugewiesen.

• Passwortloses Login

  Verbessert die Benutzererfahrung und reduziert das Risiko schwacher Passwörter.

  Beispiel: Lassen Sie Benutzer sich mit einem magischen Link anmelden, der an ihre E-Mail gesendet wird, oder über eine biometrische Aufforderung wie Face ID.

Diese Funktionen gelten sowohl für traditionelle als auch agentenbasierte Apps, besonders, da Agenten beginnen, über sensible Daten und Systeme hinweg zu operieren.

Was sich in der agentischen Welt verändert hat#

Authentifizierung ist wichtiger denn je#

Da Agenten und Multi-Agenten-Workflows entstehen, sehen wir neue Anwendungsfälle, in denen Benutzer, Agenten, APIs und MCP-Server alle interagieren. Die Anzahl und Vielfalt dieser Szenarien wächst schnell, viel mehr als in der Vergangenheit.

Wann immer diese Verbindungen passieren, wird die Autorisierung sichtbarer denn je. Benutzer müssen klare Zustimmung geben, und Berechtigungen müssen sorgfältig über Systeme hinweg verwaltet werden. Deshalb spricht jetzt jeder über das Halten eines „Menschen im Prozess“, der sicherstellt, dass Benutzer genug Kontrolle und Sichtbarkeit darüber haben, was Agenten tun können, und für welche Bereiche sie autorisiert sind.

Ihre KI-Anwendung muss möglicherweise mit vielen externen Diensten integriert werden#

Das MCP-Ökosystem expandiert, und das bedeutet, dass Ihre App nicht mehr nur ein eigenständiger Dienst ist: Sie ist Teil eines größeren, vernetzten Netzwerks.

Um LLMs reichten, nützlichen Kontext zu bieten, müssen Ihre Agenten möglicherweise:

• Auf mehrere MCP-Server zugreifen

  Beispiel: Stellen Sie sich einen KI-Projektmanager vor, der Aufgaben-Updates von Jira, Team-Verfügbarkeit von Google Kalender und Verkaufsdaten von Salesforce zieht, und jeder dieser Dienste könnte von einem anderen MCP-Server betrieben werden. Um einen wöchentlichen Bericht zu erstellen, muss der Agent sicher mit mehreren Datenquellen interagieren. Hierbei kommen Authentifizierung und Autorisierung ins Spiel, um jede Verbindung zu schützen und zu kontrollieren, wie Daten geteilt werden.

• Mit externen APIs und Werkzeugen verbinden

  Beispiel: Ein Kundendienst-Agent könnte Bestellhistorien von Shopify abrufen, Tickets in Zendesk aktualisieren und Workflows in Slack anstoßen. Ohne Integrationen wird der Agent isoliert und ineffektiv.

Da Agenten mehr Verantwortung übernehmen, ist Integration der Schlüssel zur Nützlichkeit. Ihr KI-Produkt hängt nicht nur davon ab, was es selbst tun kann, sondern auch davon, was es in einem vernetzten Ökosystem zugreifen, orchestrieren und darüber nachdenken kann. Aus diesem Grund ist es wichtiger denn je, für Interoperabilität zu bauen, sicher und flexibel.

Sie müssen offene Standards akzeptieren: OAuth/OIDC sind wichtiger denn je#

In der KI-Ära wächst der Bedarf an sicheren, flexiblen Integrationen. Das macht OAuth 2.0 und OIDC wichtiger denn je.

Wichtige Anwendungsfälle umfassen:

• Remote-MCP-Server: Lassen Sie Drittanbieter-Agenten sicher auf Ihr Produkt zugreifen, indem Sie delegierte Tokens verwenden.
• Drittanbieter-Integrationen: Erlauben Sie anderen Werkzeugen oder Agenten, sich mit Ihrer App zu verbinden (z.B. einer Projektmanagementplattform), ohne dass rohe Anmeldedaten benötigt werden.
• Agenten-Entwicklung: Bauen Sie KI-Agenten, die sicher im Namen von Benutzern über Dienste hinweg handeln.
• Intelligente Geräte: Verwenden Sie OAuth/OIDC für Dinge wie KI-gesteuerte Notetaker, um Benutzer zu authentifizieren und mit der Cloud zu verbinden — besonders mit minimaler UI.

Diese Protokolle bieten sicheren, tokenbasierten und benutzerzugestimmten Zugriff.

Das ist entscheidend in einer Welt agentischer, vernetzter Systeme. Sehen Sie sich diesen Artikel an, um zu sehen, warum OAuth und OIDC wichtig sind

Vertrauen und Skalierung im Zeitalter agentischer Software gestalten#

Da sich agentische Produkte weiterentwickeln, bleiben die Kernprinzipien von Identität und Autorisierung gleich, aber der Kontext verschiebt sich. Agenten führen neue Oberflächen für Delegation, Zustimmung und Zugriff ein. Deshalb sind das Festhalten an offenen Standards wie OAuth, der Aufbau einer klaren Architektur und die Durchsetzung solider Sicherheitspraktiken nicht nur Best Practices, sondern grundlegend. Sorgfältiges Design jetzt bedeutet, dass Ihr System mit Vertrauen, Flexibilität und im KI-gestützten Zeitalter skalieren wird.