Die KI-Agenten-Identität
Jeder KI-Agent auf dem AI OS erhält seine eigene eindeutige Identität — kein gemeinsames Dienstkonto — mit Least-Privilege-Berechtigungen, die auf seine Aufgabe eingegrenzt sind, authentifizierten Agent-zu-Agent-Aufrufen und einem vollständigen Audit-Trail darüber, was er getan hat und unter wessen Autorität, innerhalb Ihres Perimeters.
Eindeutige Identität pro Agent
Keine gemeinsamen Dienstkonten. Jeder Agent — und jede Instanz eines Agenten — erhält seine eigene überprüfbare Identität, verankert in Ihrem Identitätsanbieter.
Eingegrenzte Least-Privilege-Berechtigungen
Agenten erhalten genau die Tools, Daten und Aktionen, die ihre Aufgabe erfordert — nicht mehr — statt pauschalen Zugriffs, der von einem gemeinsamen Credential geerbt wird.
Authentifizierte Agent-zu-Agent-Aufrufe
Wenn ein Agent über A2A einen anderen Agenten aufruft oder über MCP ein Tool aufruft, trägt der Aufruf seine Identität, sodass jeder Hop autorisiert und zurechenbar bleibt.
KI-Agenten-Identität ist die Praxis, jedem autonomen KI-Agenten seine eigene eindeutige, überprüfbare Identität auszustellen — getrennt von jedem menschlichen Nutzer und von jedem gemeinsamen Dienstkonto — sodass seine Berechtigungen auf Least Privilege eingegrenzt werden können, seine Aufrufe an andere Agenten und Tools authentifiziert werden können und jede Aktion, die er ausführt, dieser Identität und der Autorität, unter der er gehandelt hat, zurechenbar ist.
Ein gemeinsamer API-Schlüssel oder ein gemeinsames Dienstkonto kann Ihnen nicht sagen, welcher Agent was getan hat oder in wessen Auftrag. Wenn Organisationen Agenten aus dem Pilotbetrieb in die Produktion überführen, wird diese Unklarheit zur Haftung: Ein nicht eingegrenztes Credential, das Produktivsysteme berührt, ist ein dauerhaftes Risiko, und eine Aktion, die niemand zuordnen kann, ist nichts, was Sie auditieren oder verteidigen können. Auf dem AI OS erhält jeder Agent — ob er eine einzige Aufgabe ausführt oder einen ganzen Workflow orchestriert — seine eigene Identität, wird pro Aktion unter Zero-Trust-Richtlinie autorisiert und authentifiziert, wenn er andere Agenten oder Tools aufruft. Das Ergebnis ist Agentenautonomie, die Ihr Compliance-Team tatsächlich freigeben kann: Least Privilege standardmäßig und ein vollständiger Nachweis dessen, was geschehen ist, innerhalb Ihres Perimeters.
KI-Agenten-Identität in der Scrydon-Plattform
Eine integrierte, souveräne Architektur. Hier fügt sich KI-Agenten-Identität ein — hervorgehoben im Kontext des gesamten Stacks, mit dem es zusammenarbeitet.
Das AI OS für Menschen und KI-Agenten
Ontologie- und Semantikschicht: ein zusammenhängendes Modell für Ihre Daten, Ihr Wissen und Ihre Prozesse
Das Beste aus Data Lakes, Data Warehouses und Suche vereint
KI-Agenten, Workflows und Automatisierungen, die über Ihre Systeme hinweg ausgeführt werden
Integrieren Sie über A2A, MCP, Legacy-Systeme und Datenquellen
Sichere Domänenföderation, vertrauenswürdiger Datenaustausch und Intelligenz über Grenzen hinweg
Souveräne Grundlagen
KI-Agenten-Identität im Detail
Agentische KI verwandelt Frontier-Modelle von isolierten Chatbots in echte autonome Akteure des AI OS. Statt lediglich Text zu erzeugen, sind diese Agenten gezielt dafür gebaut, jene Aufgaben auszuführen, die Ihre Mitarbeitenden nicht manuell erledigen sollten — schlussfolgern, planen und handeln über komplexe, mehrstufige Prozesse hinweg.
Das AI OS stützt sich auf ein Fundament aus Kreativität und Kontrolle, um autonome Agenten wirkungsvoll einzusetzen:
- KI-Workflows als Fundament: Der Kern des AI OS basiert auf orchestrierten KI-Workflows, die Frontier-Modelle, interne Tools und Enterprise Memory sicher miteinander verbinden.
- Deterministische und nicht-deterministische Flows: Durch die Kombination der Schlussfolgerungsfähigkeit von Frontier-KI mit strikten, deterministischen Workflows garantiert das AI OS sowohl Anpassungsfähigkeit als auch absolute Vorhersehbarkeit in geschäftskritischen Prozessen.
- Autonome Ausführung: Agenten handeln autonom innerhalb definierter Grenzen, beziehen Kontext aus Ihrem Data Lakehouse und führen Aktionen über freigegebene Tools aus.
Sicher innerhalb Ihrer Infrastruktur bereitgestellt, schöpfen diese Agenten aus Ihrer Cognitive Enterprise, um entschlossen zu handeln. Strikte, richtlinienbasierte Guardrails halten sie fest innerhalb der von Ihrer Organisation definierten Grenzen und sorgen für eine perfekte Balance zwischen Produktivität und Sicherheit auf Enterprise-Niveau.
Das AI OS funktioniert nur, wenn man ihm vertrauen kann. Jede Schicht der Plattform ruht auf einem Zero-Trust-Infrastruktur- und Identitätsfundament, das konsistent arbeitet — von vollständig air-gapped On-Premises-Installationen bis hin zu Hyperscale-Cloud-Umgebungen. Souveränität ist kein obenauf gesetztes Feature — sie ist die Bedingung, unter der alles andere operiert.
- Zero-Trust-Architektur: Kontinuierliche Verifizierung für jede Anfrage, jeden Nutzer und jede Workload — kein implizites Vertrauen, auch nicht innerhalb des Perimeters.
- Föderierte Identität: Nahtlose Integration mit Ihrem bestehenden IdP (SAML, OAuth 2.0, OIDC) für einheitliche, richtliniengesteuerte Zugriffskontrolle.
- Air-Gap-Bereitstellung: Betreiben Sie die komplette Plattform ohne externe Netzwerkabhängigkeiten — ideal für Verteidigung, kritische nationale Infrastruktur und klassifizierte Workloads.
- Confidential Computing: Verschlüsselung von Daten während der Nutzung auf Hardwareebene via AMD SEV-SNP und Intel SGX, wodurch Workloads selbst vor Infrastrukturadministratoren geschützt sind.
Deployment Options: From Air-gapped to Cloud
Setzen Sie die Scrydon-Plattform dort ein, wo es für Sie sinnvoll ist — von Air-Gap-Umgebungen bis zur Public Cloud — mit integrierter Souveränität, Compliance und Auditierbarkeit.
Keine Daten verlassen Ihre Jurisdiktion. Keine Black-Box-KI. Keine Kompromisse bei der Kontrolle.
Das ist Souveränität by Design.
Jedem KI-Agenten seine eigene Identität geben
Wenn ein Agent auf dem AI OS bereitgestellt wird, erhält er seine eigene Identität — und nicht die Kopie eines Tokens, das andere Agenten ebenfalls nutzen. Diese Identität föderiert an Ihren bestehenden Identitätsanbieter, trägt Berechtigungen, die auf die konkrete Aufgabe und die Tools eingegrenzt sind, die der Agent benötigt, und begleitet den Agenten in alles, was er tut: jeden Tool-Aufruf, jede Übergabe an einen anderen Agenten, jede Aktion auf einem realen System. Nichts, was ein Agent berührt, ist anonym oder unter fremdem Namen erreichbar.
Eine Identität, ein Agent — Jeder Agent erhält bei der Bereitstellung seine eigene Identität — kein gemeinsames Token, das über eine ganze Flotte von Agenten kopiert wird.
Verankert in Ihrem IdP — Agenten-Identitäten föderieren an Ihren bestehenden Identitätsanbieter, genau wie menschliche und Workload-Identitäten.
Eingegrenzt pro Aufgabe und Tool — Berechtigungen werden pro Aufgabe und pro Tool vergeben, sodass ein Agent nur das erreichen kann, was seine Aufgabe tatsächlich erfordert.
Bei jedem Aufruf mitgeführt — Die Identität begleitet den Agenten in jeden Tool-Aufruf und jeden Agent-zu-Agent-Austausch, den er vornimmt.
Warum ein gemeinsames Dienstkonto für Agenten nicht gut genug ist
Ein einziges Dienstkonto, das sich eine ganze Flotte von Agenten teilt, wirkt bequem — bis etwas schiefgeht. Es gewährt jedem Agenten dahinter denselben weitreichenden Zugriff, sodass das Eindämmen eines einzelnen kompromittierten oder fehlverhaltenden Agenten bedeutet, das Credential für alle auf einmal zu widerrufen. Schlimmer noch: Ein gemeinsames Credential macht Agenten in Ihren Logs nicht unterscheidbar — Sie sehen, dass „das Dienstkonto“ gehandelt hat, nicht welcher Agent, bei welcher Aufgabe oder unter wessen Autorität er operierte. Eindeutige Identitäten sind das, was Least Privilege und eine saubere Incident Response überhaupt erst möglich macht.
Keine Kontrolle über den Wirkungsradius — Ein gemeinsames Credential gibt jedem Agenten dahinter denselben weitreichenden Zugriff, sodass ein kompromittierter oder fehlverhaltender Agent alles offenlegt, was die anderen erreichen können.
Nicht unterscheidbare Akteure — Wenn sich zehn Agenten ein Konto teilen, sagt Ihnen ein Log-Eintrag, dass das Credential gehandelt hat — nicht welcher Agent, bei welcher Aufgabe oder unter wessen Autorität.
Least Privilege wird unmöglich — Sie können Berechtigungen nicht auf die Aufgabe eines einzelnen Agenten eingrenzen, wenn dasselbe Credential auch von jedem anderen Agenten der Flotte genutzt wird.
Widerruf trifft alle — Ein gemeinsames Konto zu deaktivieren, um einen außer Kontrolle geratenen Agenten einzudämmen, legt jeden anderen davon abhängigen Agenten lahm.
Jede Aktion rückverfolgbar zu einer Identität und einem Geltungsbereich
Sie können die Aktionen eines Agenten nicht auditieren oder steuern, wenn er von einem gemeinsamen Credential nicht zu unterscheiden ist. Weil jeder Agent unter seiner eigenen Identität und einem für diese konkrete Aufgabe autorisierten Geltungsbereich handelt, landet jede Aktion im Audit-Trail, zurechenbar zu einem realen Akteur — welcher Agent, was er getan hat und wer oder was es autorisiert hat. Das ist die Rückverfolgbarkeit auf Akteursebene, die die Pflichten der KI-Verordnung und interne Governance-Prüfungen erwarten, und sie macht aus „ein Agent hat etwas falsch gemacht“ statt einer forensischen Sackgasse einen präzisen Widerruf einer einzigen Identität.
Unveränderlicher Audit-Trail — Jede Aktion, die ein Agent ausführt, wird gegen seine eigene Identität protokolliert, gegen den Geltungsbereich, unter dem er gehandelt hat, und gegen den Menschen oder Workflow, der sie autorisiert hat.
Nachweise bereit für die KI-Verordnung — Eindeutige Agenten-Identitäten geben Prüfern die Rückverfolgbarkeit auf Akteursebene, die die Pflichten der KI-Verordnung für Hochrisiko- und Allzwecksysteme erwarten.
Zero-Trust für Agenten — Kontinuierliche Autorisierung pro Aktion ersetzt dauerhaften weitreichenden Zugriff, sodass ein kompromittierter Agent nicht stillschweigend ausweiten kann, was er berühren darf.
Schnelle, präzise Incident Response — Wenn etwas schiefgeht, können Sie die Identität genau eines Agenten isolieren und widerrufen — ohne den Zugriff eines anderen Agenten anzutasten.
Häufig gestellte Fragen
Was ist KI-Agenten-Identität?+
Warum können sich Agenten nicht einfach ein Dienstkonto teilen?+
Wie werden Agentenberechtigungen eingegrenzt?+
Wie funktioniert Agenten-Identität mit A2A und MCP?+
Hilft Agenten-Identität bei der Konformität mit der KI-Verordnung?+
Ersetzt dies das Identitäts- und Zugriffsmanagement für Menschen?+
Die Plattform entdecken
Schreiben Sie uns
Lieber schreiben? Senden Sie eine E-Mail an hello [at] scrydon.com und wir melden uns bei Ihnen.
Partner
