IBM gibt KI-Agenten eigene Identitäten – und macht die Lücken sichtbar

Der neue Sicherheitsfall ist ein Agent mit zu vielen Rechten

Ein Assistent, der einen Text zusammenfasst, benötigt eine andere Vertrauensbasis als ein Agent, der Kundendaten ausliest, Tickets schließt oder Cloud-Ressourcen verändert. Das Problem beginnt dort, wo beide Systeme technisch gleich behandelt werden: mit einem Benutzerkonto, einem langlebigen Schlüssel und weitreichenden Zugriffsrechten. IBM adressiert genau diesen Übergang von sprachlicher Assistenz zu eigenständig ausgeführten Aktionen.

Auf der TechXchange 2026 bündelt der Konzern dafür mehrere zuvor getrennte Bausteine. Agent Identity führt Agenten als eigenständige, verwaltbare Identitäten; IBM Verify soll Delegationen und Richtlinien nachvollziehbar machen. HashiCorp Vault stellt geschützte, möglichst kurzlebige Zugangsdaten bereit. watsonx Orchestrate führt die verschiedenen Agentenumgebungen in der Steuerung zusammen. Das ist mehr als eine weitere Chat-Oberfläche – aber auch kein Versprechen, dass dadurch jeder Agent sicher arbeitet.

Was verfügbar ist – und was noch nicht

Die Verfügbarkeit entscheidet über den tatsächlichen Nachrichtenwert. IBM nennt Agent Identity, Vault 2.2 und die Evaluierungsfunktionen von watsonx Orchestrate als allgemein verfügbar. Dagegen befinden sich die Funktionen, mit denen Orchestrate Agenten aus fremden Plattformen automatisch entdecken und in isolierten Laufzeitumgebungen betreiben soll, ausdrücklich in einer technischen Vorschau. Wer aus der Pressemitteilung ein sofort vollständiges Multi-Cloud-Kontrollsystem herausliest, verwischt diesen Unterschied.

Der angekündigte technische Ansatz ist dennoch bemerkenswert: Ein Agent soll eine dokumentierte verantwortliche Person oder Stelle, eine klar begrenzte Aufgabe und eine überprüfbare Berechtigung besitzen. Tokens und Zugangsdaten sollen nur für den jeweiligen Zweck gelten; Berechtigungen müssen widerrufbar bleiben. Das wirkt unspektakulär, trifft aber die Schwachstelle zahlreicher Agenten-Pilotprojekte: Es ist häufig unklar, wer welche Automatisierung genehmigt und wie sie im Fehlerfall gestoppt wird.

Warum Inventar und Audit-Trail keine Nebensache sind

Zahlreiche Unternehmen setzen mittlerweile Agenten aus unterschiedlichen Plattformen ein. Der Sicherheitsbeauftragte sieht dann nicht einen geschlossenen Softwarebestand, sondern einzelne Copilots, interne Skripte, MCP-Server und spezialisierte Workflows. IBM will mit einem gemeinsamen Gateway und einem verwalteten Katalog die Sichtbarkeit erhöhen. Dazu kommen nachvollziehbare Laufzeitspuren, Bewertungen und Kosteninformationen. Für Teams ist das vor allem eine organisatorische Zumutung: Sie müssen erstmal ehrlich erfassen, welche Agenten überhaupt produktiv arbeiten.

Es reicht allerdings nicht, jedem Agenten einen Namen und einen Datenbankeintrag zu geben. Eine Sicherheitskontrolle muss auch unter Last, bei fehlerhaften Tool-Antworten, bei Prompt-Injection und bei der Weitergabe von Berechtigungen zwischen Agenten bestehen. Die IBM-Dokumente beschreiben Architektur und Produktfunktionen; sie liefern keine unabhängige Erfolgsquote für diese anspruchsvollen Grenzfälle. Sichtbarkeit ist die Voraussetzung für Kontrolle, kein Beweis für ihre Wirksamkeit.

Unsere Einschätzung: weniger Agentenromantik, mehr Betriebshandwerk

Wir halten die Richtung für richtig. Der nächste Reifegrad von Agenten wird nicht allein daran zu messen sein, wie überzeugend ein Modell einen Auftrag formuliert. Entscheidend wird, ob ein Unternehmen jederzeit beantworten kann: Wer hat diesen Agenten freigeschaltet? Welche Daten durfte er sehen? Was hat er tatsächlich verändert? Und wer kann seine Rechte innerhalb von Sekunden zurücknehmen?

Genau hier sollte auch die Bewertung von IBM nüchtern bleiben. Dass Vault und Agent Identity angeboten werden, beweist weder eine lückenlose Ende-zu-Ende-Integration noch die vollständige Wirksamkeit einer Vorschaufunktion. Der konkrete Mehrwert ist erst nach einer Probe mit realen Fachanwendungen, Rechtewechseln und absichtlich fehlschlagenden Aktionen zu belegen. Wir würden klein anfangen: einen begrenzten Prozess, nachprüfbare Logdaten, nachweisbaren Widerruf – und erst danach weitere Agenten zulassen.

So lässt sich die Ankündigung praktisch einordnen

Ein belastbarer Testplan sollte vier Dinge enthalten: Erstens eine Inventarliste aller Agenten mit Verantwortlichen. Zweitens zeitlich und sachlich begrenzte Berechtigungen samt dokumentierter Delegation. Drittens eine echte Negativprobe, bei der ein Agent auf eine nicht freigegebene Ressource zugreifen will. Viertens eine Ereigniskette, die vom menschlichen Auftrag bis zum API-Aufruf nachvollziehbar bleibt. Fehlt eines dieser Elemente, bleibt die schönste Governance-Oberfläche ein Dashboard ohne Durchsetzungskraft.

AgentenCode führt ein eigenes, quellenbezogenes Dossier zu IBM watsonx Orchestrate. Dort lassen sich dokumentierte Produktmerkmale und ihre Nachweisgrenzen prüfen. Unsere Trust-Übersicht und die Bewertungsmethodik helfen, aus einer Anbieterankündigung konkrete Prüfanforderungen abzuleiten. Diese Daten ersetzen keine kundenspezifische Sicherheitsprüfung; sie verhindern aber, dass ein Marketingbegriff als belastbare Freigabe missverstanden wird.

Originalquellen und AgentenCode-Daten

• Originalmitteilung ↗
• Technische Vertiefung ↗
• Kontext / bestehende Zulassung ↗

Unsere redaktionelle Bewertung wird aus den genannten Primärquellen und den nachgewiesenen Grenzen abgeleitet; sie ist kein Praxistest.