AI-Agenten brauchen Identity Governance statt Shared Secrets: Warum diese Security-Schicht jetzt dringend wird

Unternehmen bewegen sich gerade von AI-Experimenten zu AI-Operatoren. Coding-Assistenten, Support-Bots, Workflow-Automationen und interne Copilots greifen zunehmend auf reale Systeme zu und nicht nur auf Testumgebungen. Damit verändert sich die Sicherheitsfrage. Es reicht nicht mehr zu wissen, was ein AI-Agent tun kann. Teams müssen klären, wer der Agent ist, welche Rechte er hat, wie dieser Zugriff genehmigt wird und wie er entzogen werden kann.

Die NewCore-Meldung ist deshalb relevant, weil sie auf ein reales Architekturproblem zeigt: Die meisten Identity-Stacks wurden für Menschen, Service-Accounts und klassische Machine-Workloads gebaut. AI-Agenten passen nur schlecht in diese Kategorien. Sie handeln teilweise autonom, greifen auf mehrere Systeme zu und erzeugen Aktionen in Maschinengeschwindigkeit, während viele Unternehmen sie noch immer über statische Secrets, gemeinsame Tokens oder Entwickler-Workarounds anbinden.

Warum AI-Agent-Identität zu einem Sicherheitsproblem erster Ordnung wird

Ein AI-Agent mit Zugriff auf Repositories, Ticketsysteme, Cloud-Konsolen, Kundendaten oder interne Dokumentation ist faktisch ein privilegierter Akteur. Wenn sein Identitätsmodell schwach ist, werden alle nachgelagerten Kontrollen ebenfalls schwächer. Logging wird unklar, Freigaben werden unscharf und die Incident Response verlangsamt sich, weil niemand sauber beantworten kann, welcher Agent was, in welchem Kontext und mit welchem Rechteumfang getan hat.

• Gemeinsame API-Keys verschleiern Verantwortung und machen Audit-Trails unzuverlässig.
• Zu breite Rechte vergrößern den Blast Radius, wenn Agenten Aktionen über mehrere Tools verketten.
• Manuelle Secret-Verteilung skaliert nicht, wenn in kurzer Zeit viele Agent-Workflows entstehen.
• Der Entzug von Rechten ist oft unklar, sobald aus einem Experiment eine produktive Abhängigkeit wird.

Was sich ändert, wenn Agenten als verwaltete Identitäten behandelt werden

Der praktische Wandel besteht darin, AI-Zugriffe nicht länger als Ausnahme zu behandeln. Stattdessen sollten Agenten in dieselbe Governance-Sprache überführt werden, die Unternehmen bereits für Menschen und Systeme nutzen: Identity-Lifecycle, Least Privilege, Freigabeketten, Monitoring, Ablaufzeiten und Break-Glass-Kontrollen. Die technische Umsetzung kann variieren, die betriebliche Disziplin sollte vertraut sein.

1) Jeder Agent braucht einen klaren Owner

Ein Agent ohne Verantwortlichen wird schnell zu Shadow Automation. Jemand muss für Zweck, Rechte, Datenzugriff und Abschaltpfad geradestehen. In reifen Umgebungen ist das nicht nur der Entwickler, der das Tool verbunden hat, sondern der Business- oder Plattform-Owner, der das operative Risiko akzeptiert.

2) Least Privilege muss real sein, nicht symbolisch

Ein Code-Agent sollte nicht denselben Wirkungsbereich bekommen wie ein Senior Engineer. Ein Support-Agent sollte nicht breit auf das CRM zugreifen dürfen, nur weil die Integration so einfacher war. Rechte sollten nach Aufgabe, Umgebung und Zeitfenster begrenzt werden. Sonst wird die erste Bequemlichkeitsabkürzung schnell zum nächsten Incident Review.

3) Revocation und Ablaufzeiten müssen eingebaut sein

Für Menschen existieren typische Lifecycle-Hooks: Joiner, Mover, Leaver. Agenten brauchen ein vergleichbares Modell. Temporäre Piloten sollten automatisch ablaufen. Inaktive Agenten sollten deaktiviert werden. Zugriffe für Hochrisiko-Operationen sollten aktiv erneuert werden müssen. Wenn Revocation davon abhängt, dass jemand sich an einen gespeicherten Token erinnert, ist die Kontrolle im Betrieb nicht glaubwürdig.

Ein pragmatisches Rollout-Modell für Unternehmen

Die meisten Organisationen brauchen nicht am ersten Tag eine komplett neue Plattform. Sie brauchen aber eine Policy und eine operative Basis, bevor sich Agenten über Engineering, Support und Business Automation verbreiten.

• Erstellen Sie ein Inventar aller produktionsnahen AI-Agenten und dokumentieren Sie Owner, Zweck, angebundene Systeme und Datensensibilität.
• Trennen Sie experimentelle Agenten von Agenten, die schreiben, deployen, freigeben, einkaufen oder Kunden kontaktieren dürfen.
• Ersetzen Sie Shared Credentials möglichst durch verwaltete Identitäten, begrenzte Tokens oder vermittelte Zugriffe.
• Fordern Sie Logging und verständliche Audit-Trails für jede Agent-Aktion, die Systemzustand verändert.
• Definieren Sie Revocation-, Ablauf- und Notfall-Deaktivierungsprozesse, bevor die Nutzung skaliert.

Wo der Business Impact liegt

Das ist kein Nischenthema für Security-Teams. Es beeinflusst Liefergeschwindigkeit, Compliance-Sicherheit und operative Resilienz. Teams, die AI-Agenten sauber onboarden können, automatisieren mehr, ohne verdeckte Risiken aufzubauen. Teams ohne Identitätsdisziplin sind vielleicht ein Quartal schneller, verlieren danach aber Zeit in Audits, Incident Handling und Nacharbeit.

Die übergeordnete Lehre ist einfach: Wenn Agenten zu digitalen Mitarbeitern werden, wird Identität zu Infrastruktur. Unternehmen, die Agent-Governance als Teil ihrer Kern-Sicherheitsarchitektur behandeln und nicht als Nebenthema im Prompt-Tooling, sind deutlich besser auf skalierende Unternehmensautomatisierung vorbereitet.