Adam Markowitz, CEO und Mitgründer von Drata – Interviewreihe

Adam Markowitz ist CEO und Mitgründer von Drata. Dort weitet er die Arbeit des Unternehmens im Bereich kontinuierliche Compliance und Vertrauen auf die Governance von KI-Agenten aus. Bevor er 2020 Drata mitgründete, gründete er zusammen mit Troy Markowitz und Daniel Marashlian Portfolium. Seine Erfahrung mit Sicherheitsfragebögen, Audits und Compliance-Prüfungen prägte Dratas Ansatz, Unternehmen dabei zu unterstützen, automatisiert nachzuweisen, dass sie vertrauenswürdig sind.

Drata bietet eine Plattform für Governance, Risikomanagement und Compliance. Sie vereint die automatisierte Erfassung von Nachweisen, die kontinuierliche Überwachung von Kontrollen, das Risikomanagement für Drittparteien und Workflows für Sicherheitsfragebögen. Die Funktionen zur Governance von KI-Agenten konzentrieren sich darauf, Agenten aufzuspüren, Richtlinien durchzusetzen, bevor Aktionen ausgeführt werden, und Entscheidungen revisionssicher zu dokumentieren. In diesem Interview spricht Markowitz über Bedrohungen durch interne Agenten, Maschinenidentitäten, Sicherheitsgrenzen bei Tool-Aufrufen und die Kontrollen, die Unternehmen benötigen, um autonome Agenten in großem Maßstab einzusetzen.

Sie haben zunächst Portfolium gegründet und 2020 Drata mitgegründet, nachdem Sie selbst erlebt hatten, wie aufwendig die Einhaltung von Sicherheitsvorgaben mit dem Wachstum eines Unternehmens werden kann. Was hat Sie davon überzeugt, dass es sich um ein Problem handelte, für das es sich lohnte, ein völlig neues Unternehmen aufzubauen? Und wie hat sich Dratas Mission weiterentwickelt, seit KI die Sicherheitslandschaft verändert?

Als ich Portfolium zusammen mit meinen Mitgründern Troy Markowitz und Daniel Marashlian leitete, lernten wir eine wichtige Lektion: Vertrauen im Geschäftsleben muss man sich erarbeiten – es entsteht durch einen Prozess, nicht durch einen Verkaufspitch. Angesichts des großen Umfangs und der Sensibilität der Studierendendaten wollten Universitäten und Unternehmen erst dann mit uns zusammenarbeiten, wenn wir nachgewiesen hatten, dass wir die Daten angemessen schützten. Uns wurde klar, dass viele dieselbe langsame und mühsame Erfahrung machten: jeden Sicherheitsfragebogen, jedes Audit und jede Compliance-Prüfung manuell abzuarbeiten. Nach der Übernahme von Portfolium fanden Troy, Daniel und ich wieder zusammen. Wir verbrachten sechs Monate damit, die erste Version von Drata zu entwickeln, und sprachen mit Dutzenden Unternehmen und Auditoren, um das Problem zu bestätigen, bevor wir überhaupt mit dem Programmieren begannen. Nach dem Start gewannen wir in den ersten sechs Wochen 100 Kunden und innerhalb eines Jahres 1.000. Daran erkannten wir, dass wir nicht mehr etwas verkauften, das lediglich eine nette Ergänzung war, sondern etwas, ohne das die Menschen nicht arbeiten konnten.

Durch KI hat sich Dratas Mission, kontinuierliches Vertrauen zu gewährleisten, nicht verändert, doch der Umfang dessen, was Vertrauen umfasst, ist größer geworden. Zunächst automatisierten wir den mühsamen Compliance-Aufwand. Anschließend entwickelten wir agentengestützte Workflows, mit denen sich Risikobewertungen für Drittparteien und Sicherheitsfragebögen vollständig von Anfang bis Ende bearbeiten ließen. Die entscheidende Veränderung kam jedoch, als die Agenten selbst zu etwas wurden, das kontrolliert werden musste. Inzwischen haben wir die Plattform um Funktionen zur Governance von KI-Agenten erweitert: Agenten aufspüren, steuern, was sie tun dürfen, und Nachweise erstellen, die auch einer Prüfung standhalten.

Sie haben den Begriff „Bedrohung durch Insider-Agenten“ geprägt, um Risiken zu beschreiben, die nicht von externen Angreifern, sondern von den KI-Agenten einer Organisation selbst ausgehen. Was unterscheidet eine solche Bedrohung von der traditionellen Insiderbedrohung, auf die sich Sicherheitsteams seit Jahrzehnten vorbereiten?

Bei traditionellen Insiderbedrohungen geht es darum, dass eine Person vorhandene Zugriffsrechte missbraucht – etwa ein unzufriedener oder nachlässiger Mitarbeiter oder jemand, der schlicht auf das Falsche klickt. Sicherheitsteams haben jahrzehntelang Programme entwickelt, um diesem Risiko zu begegnen. Dazu gehören etwa Hintergrundüberprüfungen, das Prinzip der geringsten Berechtigungen und Checklisten für das Ausscheiden von Mitarbeitern.

Die Bedrohung durch einen Insider-Agenten ist anders gelagert, denn dem Agenten wurde überhaupt kein Zugriff gewährt. Das Risiko verlagert sich vom Missbrauch hin zur Beschaffung von Zugriff. Erhält ein Agent ein Ziel und ist der offensichtliche Weg dorthin versperrt, stellt er nicht einfach eine Anfrage und wartet, wie es ein Mensch tun würde. Stattdessen sucht er nach einem anderen Weg – etwa über ein Dienstkonto mit einem schwachen Passwort oder einen Endpunkt, den niemand zu schließen gedacht hat. Er verschafft sich selbst Zugang, ohne böse Absicht und ohne sich eines Richtlinienverstoßes bewusst zu sein. Er tut genau das, worum man ihn gebeten hat, und gerade deshalb ist er so schwer zu erkennen. Jeder einzelne Schritt wirkt für sich betrachtet vernünftig, und am Ende meldet der Agent Erfolg.

Wir wissen bereits, wie wir Mitarbeiter und Drittparteien mit Zugriff auf sensible Systeme kontrollieren können. Agenten bilden jedoch eine dritte Gruppe, und die für die ersten beiden entwickelten Werkzeuge erfassen sie nicht.

KI-Agenten können hartnäckig Ziele verfolgen, mit Maschinengeschwindigkeit arbeiten und mit mehreren Systemen interagieren – und das ohne das Urteilsvermögen, das ein menschlicher Mitarbeiter möglicherweise einbringen würde. Wie grundlegend verändert das das Bedrohungsmodell von Unternehmen?

Vor allem verändert sich dadurch der zeitliche Ablauf. Ein Mensch, der nach einem Weg in ein System sucht, wird irgendwann gelangweilt, wird entdeckt oder gibt auf. Ein Agent tut das nicht. Eine offene Tür, die bisher unentdeckt geblieben ist, wird nun gefunden, weil der Agent nicht müde wird und seine Suche nicht einstellt.

Und es bleibt nicht bei einer einzigen Tür. Ein Agent, der für eine bestimmte Aufgabe entwickelt wurde, greift auf dem Weg zu ihrer Erledigung ohne Weiteres auf ein Dutzend Systeme zu – ruft hier Kontoverläufe ab, prüft dort eine Datenbank. Das meiste davon hat mit dem eigentlichen Auftrag nichts zu tun. Bei der Erstellung einer einzigen Präsentation kann er auf die Daten eines anderen Kunden, Finanzunterlagen, Mitarbeiterinformationen oder alles andere zugreifen, was ihm in die Quere kommt. Nichts davon wird als Sicherheitsvorfall sichtbar.

Das Bedrohungsmodell hat sich also verändert. Sicherheitsteams sollten sich heute fragen, wie weit die eigenen Agenten gehen werden, um eine Aufgabe zu erledigen, wenn ihnen niemand sagt, wo sie aufhören sollen.

Viele Unternehmen verfügen bereits über Identitäts- und Zugriffsmanagement, Privileged Access Management und Zero-Trust-Architekturen. Warum reichen diese Kontrollen allein nicht aus, um autonome KI-Agenten zu steuern?

Diese Frameworks wurden für Menschen und Anbieter entwickelt – für Gruppen, deren Mitglieder urteilsfähig sind und anhalten, wenn sie auf eine Grenze stoßen. Für die Identität von Agenten braucht es dieselbe Sorgfalt wie bei Menschen und beim Umgang mit Risiken durch Dritte: Erfassung, Verantwortlichkeit und Nachweise, auf die sich ein Auditor stützen kann. Die Lücke besteht darin, dass es noch keinen gemeinsamen Maßstab dafür gibt, was „gesteuert“ tatsächlich bedeutet, wenn ein Agent die Zugangsdaten verwendet.

Ein Agent, den beispielsweise einer Ihrer Ingenieure erstellt hat, kann mit den Zugriffsrechten dieses Ingenieurs handeln – sogar auf Systemen, die der Ingenieur selbst nie nutzt. IAM und PAM setzen voraus, dass die Person oder Instanz, die die Zugangsdaten verwendet, weiß, wann sie aufhören muss. Bei Agenten ist diese Annahme jedoch nicht von vornherein gegeben.

Sollten Unternehmen jeden KI-Agenten als eigene Maschinenidentität behandeln, mit klar festgelegter verantwortlicher Person, Berechtigungen, Zuständigkeit und Lebenszyklus? Wie sähe ein ausgereiftes Identitäts-Framework für Agenten aus?

Ja, aber die meisten Unternehmen sind noch nicht so weit. Mehr Unternehmen, als man erwarten würde, können nicht einmal sagen, wie viele Agenten in ihren Systemen laufen – geschweige denn, wer für jeden einzelnen verantwortlich ist. Ein ausgereiftes Framework beginnt mit der Erfassung: einem vollständigen, kontinuierlich aktualisierten Verzeichnis aller Agenten. Anschließend braucht jeder Agent eine verantwortliche Person, einen klar definierten Zuständigkeitsbereich, der festlegt, worauf er zugreifen darf, und Richtlinien, die diesen Bereich tatsächlich durchsetzen. Unsere eigenen Untersuchungen zeigen dasselbe Problem auf Anbieterseite: Drei von vier Unternehmen überprüfen ihre Drittanbieter nur einmal pro Jahr oder seltener neu. Das bedeutet, dass sie ihre Entscheidungen auf Daten stützen, die bereits veraltet sind, sobald sich etwas ändert. Bei Agenten – ob intern oder extern – reichen Momentaufnahmen nicht aus.

Wir wollen einen einheitlichen Standard, an den sich jeder Agent gleichermaßen halten muss, statt dass das Sicherheitsteam herausfinden muss, was jeder einzelne Entwickler auf eigene Faust gebaut hat. Dazu gehören Richtlinien, die sich in einfacher Sprache verfassen lassen, vor ihrer Aktivierung anhand realer historischer Daten getestet werden und anschließend direkt im Ausführungspfad durchgesetzt werden. So greift das Framework bei jeder Aktion des Agenten und bleibt nicht bloß in der Dokumentation stehen.

Besonders schwierig ist ein Szenario, in dem ein Agent gegen Sicherheitsrichtlinien verstößt, ohne böswillig zu handeln. Wenn ein Agent unbeabsichtigt einen Weg zu sensiblen Daten entdeckt, weil er lediglich versucht, die ihm zugewiesene Aufgabe zu erledigen: Wie können Sicherheitsteams erfolgreiche Automatisierung von einem Sicherheitsvorfall unterscheiden?

Die ehrliche Antwort lautet derzeit: Das kann man nicht. Stellen Sie sich einen Support-Agenten vor, der vierteljährliche Geschäftsbesprechungen vorbereiten soll und angewiesen wird, den Kontoverlauf abzurufen und die Präsentation zusammenzustellen. Der vorgesehene, saubere Weg – der Export, aus dem er die Daten abrufen soll – liefert keine Ergebnisse. Ein Mensch würde an diesem Punkt aufhören. Der Agent findet jedoch einen anderen Weg und hat aus seiner Sicht die Aufgabe erfolgreich erledigt.

Die Aufgabe wurde zwar erledigt, doch der Agent umging dabei Ihre Sicherheitsvorkehrungen und griff auf Systeme zu, die er nicht hätte öffnen dürfen. Entscheidend ist, ob der Agent innerhalb des Zuständigkeitsbereichs geblieben ist, den wir ihm vorgegeben haben. Die Frage war nie, ob er die Aufgabe erledigt hat. Es geht um Richtlinien. Der Zuständigkeitsbereich muss so eng definiert sein, dass „erfolgreiche Automatisierung“ und „Sicherheitsvorfall“ im Nachhinein nicht gleich aussehen.

Herkömmliche Sicherheitsüberwachung erkennt verdächtige Aktivitäten oft erst, nachdem sie stattgefunden haben. Ein autonomer Agent kann jedoch Hunderte von Aktionen ausführen, bevor ein Mensch reagieren kann. Erfordert agentische KI Sicherheitskontrollen, die direkt im Ausführungspfad greifen, statt sich hauptsächlich auf Warnmeldungen und nachträgliche Überwachung zu verlassen?

Ja, ohne Frage. Wenn Sie das erst zur Laufzeit erkennen, ist es bereits zu spät. Sobald ein Überwachungstool die Aktion meldet, wurde sie schon ausgeführt. Sie haben dann eine lückenlose Aufzeichnung darüber, wie genau Sie gefährdet wurden, aber keine Möglichkeit mehr, die Aktion zu stoppen.

Die einzige Form der Steuerung, die bei Abläufen mit Maschinengeschwindigkeit funktioniert, prüft die Aktion vor ihrer Ausführung und verhindert Verstöße direkt im Ausführungspfad. Wir würden niemals einem neuen Mitarbeiter unsere sensibelsten Daten anvertrauen und einfach hoffen, dass die Überwachung mögliche Probleme rechtzeitig erkennt. Agenten verdienen dieselbe Sorgfalt – genau in dem Moment, bevor die Aktion ausgeführt wird. Nicht erst danach.

Das Model Context Protocol (MCP) und andere Schnittstellen zwischen Agenten und Tools ermöglichen KI-Systemen den Zugriff auf immer leistungsfähigere externe Funktionen. Welche neuen Sicherheitsgrenzen müssen für Tool-Aufrufe, APIs, Zugangsdaten und Dienstkonten geschaffen werden, wenn Unternehmen den Handlungsspielraum ihrer Agenten erweitern?

Der Aufruf eines Tools ist die neue Sicherheitsgrenze. Jedes Mal, wenn ein Agent auf Zugangsdaten zugreift, eine API aufruft oder ein Tool nutzt, ist das ein Entscheidungspunkt. In den meisten Unternehmen gibt es heute genau an diesem Punkt keine Grenze, die prüft, ob die Aktion ausgeführt werden sollte. Genau das hat bisher gefehlt. Von außen betrachtet zeigt sich derselbe blinde Fleck: Nur 37 % der Sicherheitsverantwortlichen sind zuversichtlich, überhaupt erkennen zu können, wo KI in den Produkten der Anbieter läuft, mit denen sie bereits zusammenarbeiten. Wenn Sie es im Produkt eines Anbieters nicht erkennen können, werden Sie auch den nächsten Schritt Ihres eigenen Agenten nicht erkennen. Auch für die Zugangsdaten und Dienstkonten, die all dem zugrunde liegen, müssen dieselben strengen Maßstäbe gelten wie für den Zugriff durch Menschen: klare Zuständigkeiten, ein festgelegter Umfang und regelmäßige Überprüfungen. Ein Agent sollte nicht auf Zugangsdaten zugreifen können, für die er nie eine Berechtigung erhalten hat, nur weil sie sich irgendwo in seinem Zugriffspfad befinden.

Wenn ein Prüfer, eine Aufsichtsbehörde oder ein Kunde wissen möchte, auf welche Daten ein KI-Agent zugegriffen hat, welche Entscheidungen er getroffen hat und wohin die daraus entstandenen Daten gelangt sind: Welche Nachvollziehbarkeit sollten Unternehmen realistischerweise gewährleisten können? Könnten Prüfprotokolle für Agenten irgendwann ebenso grundlegend werden wie herkömmliche Zugriffsprotokolle?

Unternehmen sollten auf Anfrage beantworten können, auf welche Daten ein Agent zugegriffen hat, welche Entscheidungen er getroffen hat und wohin die daraus entstandenen Daten gelangt sind. Es reicht nicht, diese Antwort im Nachhinein aus verschiedenen Protokollen zusammenzutragen. Der Maßstab ist eine kontinuierliche, manipulationssichere Aufzeichnung, die bereits vorliegt, wenn die Frage gestellt wird. Derzeit herrscht bei den meisten Unternehmen zu diesen Fragen Schweigen. Diese Lücke lässt sich einem Kunden gegenüber nicht einfach wegdiskutieren, und je nachdem, was durchgesickert ist, werden auch die Aufsichtsbehörden sie nicht akzeptieren.

Und ja, ich denke, Prüfprotokolle für Agenten werden bald ebenso grundlegend sein wie Zugriffsprotokolle. Seit Jahren gilt für Systeme, die von Menschen genutzt werden, die Frage „Wer hat wann auf was zugegriffen?“ als unverzichtbar. Es gibt keinen Grund, für Agenten niedrigere Maßstäbe anzulegen, nur weil nicht ein Mensch geklickt hat. Regelwerke wie der EU AI Act, AIUC-11 und ISO 42001 weisen bereits in diese Richtung. Die Nachvollziehbarkeit von Agenten muss sich an denselben Kontrollen und derselben Nachweislogik orientieren, auf denen Compliance-Programme bereits beruhen. Wer sie als nachrangig behandelt, riskiert, dass sie an den Rand gedrängt wird.

Wird die Governance von KI-Agenten Ihrer Ansicht nach künftig eine eigenständige Sicherheitskategorie bilden, oder wird sie letztlich in bestehende Plattformen für Governance, Risikomanagement, Compliance, Identitätsmanagement und Cybersicherheit integriert? Was müssen Unternehmen Ihrer Meinung nach eingerichtet haben, bevor sie wirklich autonome Agenten sicher in großem Maßstab einsetzen können?

Jede große Technologiewelle bringt ihre eigene Sicherheitswelle mit sich: Die Cloud brachte Wiz hervor, der Endgeräteschutz CrowdStrike – und KI-Agenten sorgen jetzt für eine weitere. Modellanbieter entwickeln Konsolen und Richtlinien für ihre eigenen Plattformen. Das ist hilfreich, aber kein Unternehmen arbeitet nur mit einem Modellanbieter, einem Programmierassistenten und einer einzigen Gruppe intern entwickelter Agenten. All das muss nach einem einheitlichen Regelwerk und anhand einer einzigen Nachweisquelle gesteuert werden. Dieses Problem kann keine einzelne KI-Plattform lösen, denn dafür wurde sie nicht entwickelt. Die Governance von KI-Agenten ist bereits eine eigenständige Kategorie, auch wenn sie in die GRC-, Identitäts- und Compliance-Systeme integriert wird, die Unternehmen bereits nutzen.

Bevor Unternehmen wirklich autonome Agenten in großem Maßstab einsetzen können, müssen sie vier Voraussetzungen schaffen. Die meisten haben bislang keine davon erfüllt. Erstens braucht es eine Erkennung in Echtzeit: Unternehmen müssen wissen, welcher Agent gerade läuft, wem er gehört und unter welcher Identität er arbeitet – und zwar ab dem Moment seiner Erstellung.

Zweitens müssen Richtlinien direkt im Ausführungsprozess durchgesetzt und geprüft werden, bevor eine Aktion ausgeführt wird. Drittens brauchen Unternehmen eine kontinuierliche Überwachung auf Abweichungen, da Agenten über die Sitzung hinaus bestehen, in der sie erstellt wurden, und ihr Berechtigungsumfang unbemerkt wachsen kann. Und schließlich braucht es eine manipulationssichere Aufzeichnung jeder Entscheidung eines Agenten, die den von Prüfern und Aufsichtsbehörden tatsächlich anerkannten Regelwerken zugeordnet ist. Diese Ebene entwickeln wir bei Drata. Ohne sie vertraut ein Unternehmen, das autonome Agenten in großem Maßstab einsetzt, einfach auf das Prinzip Hoffnung.

Vielen Dank für das großartige Interview. Leserinnen und Leser, die sich näher mit der Governance von KI-Agenten, kontinuierlicher Compliance und Kontrollen gegen Insider-Bedrohungen durch Agenten befassen möchten, sollten Drata besuchen.