Nicht-menschliche Identität: warum Ihre Agenten eigene Credentials brauchen
Wenn ein Team seinen ersten Agenten in die Produktion verdrahtet, ist Identität fast nie der interessante Teil. Interessant sind das Denken, die Werkzeuge, die Demo. Also wird der Agent auf dem schnellen Weg angebunden: Er läuft unter dem persönlichen Token einer Entwicklerin oder unter einem Servicekonto mit breitem, stehendem Zugriff, weil das gerade herumlag und die Demo heute funktionieren lässt.
Nur ist genau diese Abkürzung der Befund, der das Mandat im Sicherheitsgremium beendet, und zwar aus einem Grund, der nichts mit der Qualität des Agenten zu tun hat. Ein Agent, der die Credentials eines Menschen ausleiht, erbt dessen Vollmacht, dessen Audit-Mehrdeutigkeit und dessen Wirkradius, während er ein probabilistisches System ist, das den ganzen Tag gegnerische Eingaben liest. Sie haben ein System, das sich zu Dingen überreden lässt, an ein Credential gehängt, das fast alles kann. Kein Freigabeprozess zeichnet das ab, und das ist richtig so.
Die Umdeutung, die das löst, ist einfach zu sagen und strukturell umzusetzen. Ein Agent ist kein Benutzer, und er darf sich nicht als einer authentifizieren. Er ist eine Workload und braucht eine eigene Identität, zugeschnitten auf das, was er tut, die auf einer Zeitskala lebt und stirbt, die ein menschliches Credential nie könnte.
Ein geliehenes Token ist ein Generalschlüssel
Werden wir konkret, warum die Abkürzung disqualifiziert, denn "Best Practice" ist kein Argument, das ein Risikoausschuss akzeptiert.
Das persönliche Token einer Entwicklerin ist für einen Menschen gemacht: langlebig, breit zugeschnitten, interaktiv über viele Systeme genutzt. Das sind exakt die falschen Eigenschaften für einen Agenten. Handelt der Agent unter diesem Token, brechen drei Dinge gleichzeitig. Der Audit-Trail kann Mensch und Agent nicht mehr unterscheiden, Sie können also nicht sagen, wer oder was gehandelt hat. Der Zuschnitt ist weit breiter als die Aufgabe des Agenten, ein Confused-Deputy-Angriff hat also eine enorme Fläche. Und das Credential ist langlebig, leckt es also, bleibt es wochenlang wertvoll.
Diese letzte Eigenschaft macht aus einem Fehler eine Verletzung. Ein gestohlenes langlebiges Token mit stehendem Produktionszugriff ist ein Generalschlüssel. Es funktioniert von überall, lange, gegen viele Systeme. Alles an der üblichen Art, Agenten anzubinden, maximiert den Wert dieses Schlüssels für den Dieb.
Das Ziel der Workload-Identität ist, den Schlüssel wertlos zu machen.
Kurzlebige Workload-Identität mit Least Privilege
Die Produktionshaltung kehrt jede Eigenschaft des geliehenen Tokens um. Jeder Agent läuft unter seiner eigenen nicht-menschlichen Identität, getrennt von jeder Person, von der Plattform ausgestellt und rotiert, exakt auf die Aktionen zugeschnitten, die sein Prozess verlangt, und konstruktionsbedingt kurzlebig.
Das Muster, auf das die Branche dafür konvergiert ist, verdient einen Namen, denn es gibt Ihrem Sicherheitsteam eine bekannte Größe statt etwas Maßgeschneidertem. SPIFFE, das Secure Production Identity Framework for Everyone, definiert eine Standardidentität für eine Workload, und SPIRE, seine Laufzeit, stellt jeder Workload ein kryptografisch verifizierbares Identitätsdokument aus, das bei der Ausstellung attestiert wird und schnell abläuft, oft binnen Minuten. Der Agent hält kein statisches Geheimnis, das lecken könnte. Er weist fortlaufend nach, was er ist, und erhält ein frisches, kurzlebiges Credential, dessen Ausstellung die Plattform in dem Moment einstellen kann, in dem die Workload nicht mehr laufen soll.
Legen Sie Least Privilege darüber, und die Identität trägt nur die schmalen Capabilities, die der Prozess braucht. Nicht "Datenbankzugriff", sondern read_open_invoices. Nicht "Mail senden", sondern submit_decision_for_review. Die Identität ist, was das Credential authentifiziert, die Capabilities sind, was es autorisiert, und beide sind bewusst klein.
Spielen Sie nun den Diebstahl durch. Wer ein Agenten-Credential erbeutet, hält etwas, das in Minuten abläuft, nur für eine Handvoll benannter Aktionen funktioniert und nur von einer attestierten Workload aus. Kein statisches Geheimnis zum Wiederverwenden, kein stehender Zugriff zum Erben, kein breiter Zuschnitt zum Weiterspringen. Der Schlüssel öffnet fast nichts, und fast keine Zeit lang. Das ist das Entwurfsziel: ein gestohlenes Agenten-Credential sollte nahezu nichts wert sein.
Egress ist die andere Hälfte der Identitätsgrenze
Identität steuert, was ein Agent tun darf. Sie steuert für sich genommen nicht, wohin ein Agent Daten senden darf, und für ein System, das den ganzen Tag regulierte Inhalte liest, ist das Wohin ebenso wichtig wie das Was.
Deshalb wird Workload-Identität mit einer expliziten Egress-Allow-List gepaart. Der Agent darf nur die konkreten Ziele erreichen, die sein Prozess verlangt, vorab benannt, und jeder andere ausgehende Pfad wird standardmäßig verweigert. Nicht "das Internet minus einer Blocklist". Das Gegenteil: nichts, plus eine kurze Liste erlaubter Endpunkte.
Der Grund ist Exfiltration, der zehnte Punkt der OWASP-Risikoliste für agentische Systeme. Die meisten früheren Controls versuchen zu verhindern, dass ein Agent manipuliert wird. Die Egress-Allow-List nimmt an, dass eines davon irgendwann versagt, und stellt eine andere Frage: Selbst wenn der Agent erfolgreich umgedreht wurde, wohin kann er die Daten überhaupt senden? Sind die einzigen erlaubten Ziele Ihre eigenen Systeme, hat ein kompromittierter Agent keinen Ort, an den er das Gestohlene verschicken kann. Least Privilege auf Aktionen und Least Privilege auf Egress sind zwei Seiten derselben Grenze, und eine ernsthafte Freigabe sucht nach beidem.
Das ist, was eine Sicherheitsfreigabe tatsächlich besteht
Treten Sie zurück und schauen Sie, was eine Freigabe, die formale Sicherheitsabnahme, die ein reguliertes Unternehmen vor dem Go-live verlangt, wirklich prüft. Sie prüft nicht, ob Ihr Agent klug ist. Sie prüft, ob ein Prüfer darüber nachdenken kann, was das System tun kann, wenn etwas schiefgeht.
Ein geliehenes menschliches Token fällt bei Berührung durch, denn die ehrliche Antwort auf "was kann dieses Credential, wenn es leckt?" lautet "fast alles, wochenlang, von überall". Das lässt sich nicht schönreden. Die Aufgabe des Prüfers ist, sich das Credential in der Hand eines Angreifers vorzustellen, und das Bild ist inakzeptabel.
Workload-Identität besteht, weil sie die Antwort ändert. "Was kann dieses Credential, wenn es leckt?" wird zu "eine Handvoll benannter Aktionen, für ein paar Minuten, nur von einer attestierten Workload aus, und es erreicht nur diese drei internen Endpunkte". Das ist eine begrenzte, testbare, verteidigbare Antwort, und für eine begrenzte Antwort ist eine Abnahme da. Dieselbe Verschiebung macht den Audit-Trail ehrlich, weil jede Aktion nun auf eine konkrete Agentenidentität zurückführt statt auf ein mehrdeutiges geteiltes Konto. Sie können endlich sagen, was gehandelt hat, statt zu raten.
Nichts davon ist exotische Infrastruktur um ihrer selbst willen. Es ist der Unterschied zwischen einem System, das ein Sicherheitsgremium freigeben kann, und einem, das es nicht kann, und dieser Unterschied ist meist der zwischen einem Piloten, der ausgeliefert wird, und einem, der im Review stirbt.
Die Frage für Ihr nächstes Sicherheitsgremium lautet also nicht "ist unser Agent genau genug, um ihm zu vertrauen?". Sie lautet: würde das Credential dieses Agenten heute Nacht gestohlen, was genau könnte der Dieb damit tun, wie lange und zu welchen Zielen? Ist die Antwort größer als eine kurze Liste, die in Minuten abläuft, authentifiziert sich Ihr Agent als Mensch, und das ist der Befund, den Sie zurückbekommen.
Wenn Sie prüfen wollen, wie sich einer Ihrer Agenten authentifiziert und was sein Credential einem Angreifer wert ist, buchen Sie einen Termin.