Im Zentrum des Beitrags steht die These, dass sich die alte Grundsatzfrage „kaufen oder selbst bauen“ in der Cybersicherheit verschoben hat. Nach Darstellung von Token Security ist diese Gegenüberstellung für die Ära agentischer KI zu eng. Sicherheitsverantwortliche müssten vor allem entscheiden, welche Schicht sie selbst besitzen und gestalten wollen.
Anbieter könnten zwar Dashboards für verbreitete Risiken liefern, etwa überprivilegierte Dienstkonten, veraltete Zugangsdaten, ungenutzte Administratorkonten, zu weitreichende Berechtigungen oder Identitäten mit Zugriff auf Produktionssysteme. Solche Funktionen seien nützlich, reichten aber nicht aus. Die aus Sicht von Token Security entscheidenden Fragen seien oft hochgradig umgebungsspezifisch und hingen von Cloud-Nutzung, SaaS-Stack, Entwicklungspraktiken, Eigentumsmodellen, Compliance-Anforderungen und dem jeweiligen KI-Einsatz ab.
Daraus entstehe eine operative Lücke: Sicherheitsteams könnten Risikokategorien zwar benennen, den für ihre Umgebung passenden Behebungsweg aber nicht immer präzise ableiten. KI-Agenten vergrößerten diese Lücke, weil sie sich schneller bewegten als traditionelle Werkzeugzyklen. Auf Funktionen eines Herstellers über zwei Quartale zu warten, während Agenten weiter Zugriffe ansammeln, sei laut Beitrag keine wirksame Sicherheitsstrategie.
Der Text verweist zudem auf den Trend zu selbst entwickelten Werkzeugen. Laut dem „Build vs. Buy“-Bericht 2026 von Retool haben 35 Prozent der Teams bereits mindestens ein SaaS-Werkzeug durch eine Eigenentwicklung ersetzt, 78 Prozent rechnen damit, in diesem Jahr mehr selbst zu bauen. KI-gestützte Entwicklung beschleunige diesen Trend, weil sich individuelle Werkzeuge deutlich schneller prototypisch umsetzen ließen als früher.
Für Sicherheitsteams liege das eigentliche Problem jedoch nicht im Erzeugen von Code, sondern in der Datenbasis. Ein Sicherheits-Workflow sei nur so gut wie die darunterliegenden Daten zu Identitäten, Zugriffen, Berechtigungen, Zuständigkeiten und Aktivitäten. Nach Darstellung des Beitrags sollten Teams nicht selbst Integrationen über AWS, Azure, GitHub, Salesforce, Okta, Secret Manager, CI/CD-Pipelines, SaaS-Plattformen, Agenten-Frameworks und lokale Systeme hinweg neu bauen müssen. Ebenso wenig sollten sie jedes Schema eigenhändig normalisieren oder fehleranfällige Skripte pflegen, die bei API-Änderungen brechen.
Deshalb plädiert Token Security für eine Aufgabenteilung. Eingekauft werden sollten demnach die strukturell komplexen und breit genutzten Grundlagen: kontinuierliche Erkennung, Integrationen, Normalisierung, Identitätskorrelation, Zugriffsabbildung, Governance-Kontrollen, Auditierbarkeit und sichere Ausführungsgrenzen. Diese Fähigkeiten erforderten Tiefe, Skalierung und ständige Pflege.
Die operative Ebene hingegen sollten Teams selbst verantworten: also Workflows, Anwendungen, Berichte, Prüfungen und Automatisierungen, die die eigene Umgebung abbilden. Dort werde festgelegt, wem welche Agenten gehören, welche Systeme besonders relevant sind, welcher Zugriff akzeptabel ist, welche Ausnahmen gelten, wie Risiken priorisiert werden und welche Abhilfemaßnahmen folgen.
Für KI-Agenten erklärt der Beitrag Identität zur zentralen Grundlage. Jeder relevante Agent benötige letztlich Zugriff, authentifiziere sich, nutze Anmeldedaten, rufe Werkzeuge auf und erreiche Daten. Häufig verfüge ein Agent nicht einmal über eine eigene Identität, sondern nutze die eines Mitarbeiters mit. Dadurch könnten Agenten in Audit-Protokollen nicht von den Personen zu unterscheiden sein, die sie nachahmen. Identität sei deshalb die einzige Steuerungsebene, die Entdeckung, Zuständigkeit, Zugriff und Lebenszyklus für alle Agenten gleichzeitig erfassen und durchsetzen könne. Schutzplanken, Prompt-Filter und Verhaltenskontrollen wirkten darauf, was ein Agent sage; Identität bestimme dagegen, was ein Agent überhaupt erreichen könne.