The Agent Baseline: 35 Kontrollen – aber wo sollten Sie anfangen?

Vor zwei Wochen haben wir gemeinsam mit Docker und Keycard die Agent Baseline veröffentlicht. Darin beschreiben wir sechs Sicherheitsziele, 35 Kontrollen und eine offene Referenzarchitektur für den Einsatz von KI-Agents in Unternehmen. Letzte Woche haben wir sie einem Stresstest unterzogen: Bei einer Podiumsdiskussion auf der Black Hat stellten wir uns etwa eine Stunde lang kritischen Fragen dazu.

Play Video: Snyk x Docker x Keycard | Agent Baseline Panel @ Black Hat 2026

Die hilfreichste Frage kam von jemandem, der die Baseline tatsächlich bereits gelesen hatte. Sie sagte ungefähr: Das ist richtig, aber ich weiß immer noch nicht, was ich am Montag tun soll.

Und das ist berechtigt. Die Frage verdient eine fundierte Antwort, denn sie macht auf etwas aufmerksam, das wir im Paper bewusst offengelassen haben. Außerdem ist es genau die Art von Lücke, die Leserinnen und Leser hoffentlich aufdecken, solange die Baseline noch kommentiert werden kann.

Die Unsicherheit ist real – und wir stecken mittendrin

Wenn Sie nach Hilfe suchen, um KI-Agents abzusichern, stoßen Sie schnell auf eine Wand aus Behauptungen: Jeder Anbieter am Markt – Snyk eingeschlossen – erklärt, die Sicherheit von Agents zu gewährleisten. Alle beschreiben etwas Reales. Was fast nie klar wird, ist, welchen Teil des Problems sie meinen oder wie ihr Beitrag mit den anderen erforderlichen Maßnahmen zusammenspielt.

Das ist allerdings keine Frage der Unehrlichkeit. Es ist ein Symptom eines Marktes, der schneller entstanden ist als die Begriffe, mit denen wir ihn beschreiben. „Agent Governance“ kann je nach Anbieter mindestens fünf verschiedene Dinge bedeuten. Und für Käufer gibt es keine verlässliche Möglichkeit festzustellen, ob sich zwei Produkte überschneiden, ergänzen oder eine Lücke zwischen sich lassen, die niemand erwähnt hat – oder, noch beunruhigender, überhaupt erkannt hat.

Das wirkt sich in beide Richtungen aus. Anbieter möchten klar vermitteln, welchen Mehrwert sie bieten und wie sich ihre Lösung in die übrige Architektur eines Kunden einfügt. Ohne eine gemeinsame Begriffswelt klingt das jedoch wie dieselbe undifferenzierte Behauptung, die alle anderen aufstellen.

Auch Security-Praktiker brauchen mehr als einen Übersetzungsleitfaden für Anbieter: Der Abgleich mit den sechs Sicherheitszielen zeigt, wo Sie externe Lösungen benötigen und wo Sie bereits intern gut aufgestellt sind. So wird die Frage „Kaufen oder selbst entwickeln?“ deutlich leichter zu beantworten, wenn die Lücken benannt sind.

Nehmen wir zwei Produkte, die beide als Agent Governance vermarktet werden und deren Beschreibungen jeweils zutreffen.

Das erste sitzt am Netzwerkrand. Es überwacht alle ausgehenden Aufrufe eines Agents, kann deren Inhalt prüfen und sie richtlinienbasiert blockieren. Es meldet Ihnen, wenn eine Anfrage mit Kundendaten an einen Ort gelangt ist, an den sie nicht gelangen sollte. Was es Ihnen nicht sagen kann: Welche Skill-Datei dem Agent diese Anweisung überhaupt in den sprichwörtlichen Kopf gesetzt hat. Denn diese Datei kommt ihm nie unter.

Das zweite ist eine Identitätsschicht. Sie stellt im Moment der Nutzung kurzlebige, klar eingegrenzte Zugangsdaten bereit, sodass sich für jede Aktion nachvollziehbar feststellen lässt, wer sie ausgelöst hat und mit welcher Berechtigung. Sie sagt Ihnen präzise, dass der Agent die ausgeführte Aktion durchführen durfte. Was sie Ihnen nicht sagen kann: ob die Aktion eine gute Idee war.

Ordnen wir nun beide den sechs Sicherheitszielen zu: Das erste deckt Teile von Constrain und Observe ab, das zweite Authorize. Keines übertreibt, und sie überschneiden sich nicht. Zusammen lassen sie Validate jedoch unangetastet. Niemand hat getestet, ob sich der Agent bei einem Angriff sicher verhält, und niemand hat überprüft, was er erzeugt hat. Ein Käufer, der beide Lösungen einsetzt und ganz vernünftig davon ausgeht, dass die Agent Governance damit abgedeckt ist, hat dieses Gespräch noch nie geführt – denn in keinem der Verkaufsgespräche kam es auf.

Die Baseline wurde genau dafür entwickelt, solche Vergleiche zu ermöglichen. Sie definiert das Problem anhand der Sicherheitsziele, die ein Unternehmen erreichen muss, und nicht anhand von Produktkategorien: Discover, Constrain, Authorize, Observe, Validate und Respond. Vergleichen Sie beliebige Plattformen, Produkte oder interne Entwicklungen mit diesen sechs Zielen, wird schnell klar, worin ihre Stärken liegen – aber auch, wo ergänzende Lösungen sinnvoll sein könnten.

Was wir zu wenig berücksichtigt haben, ist die Reihenfolge. Sechs Sicherheitsziele und 35 Kontrollen eignen sich zur Prüfung der Abdeckung. Doch eine Abdeckungsprüfung ist noch kein Plan. (Entschuldigen Sie das etwas holprige Wortspiel, aber es zeigt auch, warum die Reihenfolge wichtig ist: Wir haben den Inhalt abgedeckt, er ist verständlich – doch in der falschen Reihenfolge braucht man eine Sekunde länger, um ihn zu erfassen.)

Wenn Sie das Paper jetzt als Aufgabenliste lesen, kommen Sie nicht ins Tun, denn der Einstieg wirkt wie ein zweijähriges Programm. Deshalb schulden wir Ihnen noch eines: die Reihenfolge.

Die meisten Unternehmen betreiben noch keine Software-Fabrik

Eine Annahme hat sich bei der Podiumsdiskussion auf der Black Hat bestätigt: Nur sehr wenige Unternehmen betreiben heute Software-Fabriken, und viele entwickeln auch nicht in nennenswertem Umfang darauf hin. Das sollten wir klar aussprechen, denn eine Referenzarchitektur kann wie ein Vorwurf wirken, wenn Sie noch nicht so weit sind. Das ist sie nicht. Wenn Sie kurz davorstehen – und das tun die meisten –, ist dies das Gerüst, an dem Sie Ihre Entwicklung ausrichten können. Es ermöglicht dem Security-Team, die Automatisierung und Produktivitätssteigerung vorzubereiten, statt erst im Nachhinein darauf zu reagieren.

Die fehlende Dimension: der Anwendungsfall

Das Paper folgt der Autonomiekurve: vom Coding-Agent auf einem Laptop bis zum unbeaufsichtigt arbeitenden Dienst, der um 3 Uhr morgens Abhängigkeiten aktualisiert. Das erklärt zwar richtig, warum es die Kontrollen gibt, hilft aber nicht dabei zu entscheiden, welche davon Sie zuerst brauchen. Die meisten Unternehmen bewegen sich nämlich nicht auf einer einzigen Kurve nach oben, sondern betreiben gleichzeitig mehrere unterschiedliche Systeme – und nennen sie alle „Agents“.

Drei Muster decken den Großteil dessen ab, was wir beobachten:

1. Coding-Agents für Entwickler. Jemand im Unternehmen lädt einen Coding-Agent herunter und setzt ihn in einem echten Repository ein.
2. Gemeinsam genutzte interne Agents. Ein Agent wird von vielen Beschäftigten genutzt, zum Beispiel als HR-Assistent, Finanzfreigabe-Agent oder Ops-Copilot.
3. Produktiv eingesetzte Agents. Diese Agents arbeiten mit Kunden, Transaktionen und führenden Systemen – oft mit nur sehr geringer menschlicher Beteiligung.

Sie haben also 35 Kontrollen, aber die Reihenfolge, in der sie „zum Einsatz kommen“, unterscheidet sich grundlegend. Problematisch wird es, wenn Sie sie als ein einziges Programm behandeln: Die wichtigste Kontrolle für den ersten Anwendungsfall ist für den dritten nahezu irrelevant – und umgekehrt. Wenn die Reihenfolge nicht stimmt, verbringen Sie Monate mit dem Aufbau eines Agent-Registers, während Ihre tatsächliche Angriffsfläche ganz woanders liegt.

Coding-Agents für Entwickler: Beginnen Sie mit Constrain und stimmen Sie Discover darauf ab

Der erste Impuls wäre hier, mit Discover anzufangen: Sie möchten jeden einzelnen Agent finden und dann entscheiden, was zu tun ist. Bei diesem Anwendungsfall ist das jedoch der falsche erste Schritt. Das Paper erklärt den Grund in einem Satz: Ein Register und ein Genehmigungsprozess bringen nichts, wenn der Agent auf einem Host läuft, der beides nicht durchsetzt.

Was tatsächlich passiert: Ein Entwickler installiert einen Coding-Agent, der jedes Mal um Erlaubnis bittet, wenn er einen Ordner lesen oder einen Befehl ausführen muss. Die ständigen Abfragen werden lästig. Also erlaubt der Entwickler häufig genutzte Befehle, erweitert den Dateisystemzugriff oder deaktiviert sogar die Sandbox. Von da an ist der Agent ein gewöhnlicher Prozess, der mit den Rechten dieses Entwicklers läuft und alles erreichen kann, worauf dessen Shell Zugriff hat.

Der Zugriff wächst mit jeder Verbindung: GitHub öffnet einen OAuth-Ablauf, ein Cloud-Tool findet eine bestehende Anmeldung, ein MCP-Server fordert ein Token an, SSH verwendet den bereits auf dem Rechner geladenen Schlüssel und so weiter. Sie verstehen das Prinzip.

Jeder einzelne Schritt wirkt für sich genommen vernünftig. Am Ende verfügt der Agent jedoch über weitreichende Berechtigungen in Systemen, die keinen gemeinsamen Überblick haben – und in deren Protokollen steht überall, der Entwickler habe gehandelt.

Beginnen Sie also an der Grenze. Isolierte Ausführung und auf den Anwendungsfall zugeschnittene Berechtigungsprofile (CON-03, CON-04) geben dem Agent nur die Berechtigungen, die seine jeweilige Aufgabenklasse erfordert. Diese werden zentral definiert, versioniert und können nicht vom Agent selbst bearbeitet werden. Danach folgt das Komponentenregister (DIS-04): MCP-Server, Skills, Plugins, Modelle und Tools – jeweils mit Quelle und Version. Als Nächstes kommen Tests vor der Freigabe (VAL-03), denn vom Agent erzeugter Code muss dieselben Freigabeprüfungen durchlaufen wie alles andere.

Am meisten überrascht viele, dass sich dadurch der Arbeitsalltag der Entwickler verbessert – nicht verschlechtert. Werden Zugangsdaten von einem Broker genau bei Bedarf und passend zur Aufgabe bereitgestellt, muss der Agent nicht mehr bei jedem „harmlosen“ Befehl um Genehmigung bitten. Denn mit den passenden Berechtigungen können harmlose Befehle keinen Schaden mehr anrichten. Weniger Abfragen und zugleich eine strengere Grenze – alles durch dieselbe Kontrolle. Das ist selten genug, um es ausdrücklich zu betonen.

Damit kommt Discover wieder ins Spiel: nicht als erster Schritt, sondern als Voraussetzung dafür, den ersten so gut wie möglich umzusetzen.

Ein Berechtigungsprofil ist nur so gut wie das Bild, auf dem es basiert. Erstellen Sie es nach bloßer Annahme, sind zwei Fehler möglich: Ist es zu weit gefasst, plant der Agent mit Zugriffen, die für die Aufgabe nie nötig waren. Ist es zu eng gefasst, wird die Grenze nach und nach mit jedem Klick auf „Immer zulassen“ aufgeweicht. Beide Fehler haben dieselbe Ursache: Das Profil wurde erstellt, ohne vorher hinzusehen.

Sehen Sie also genau hin. Die Ermittlung effektiver Zugriffe (DIS-06) zeigt Ihnen, welche Identitäten und Zugangsdaten ein Agent tatsächlich erreichen kann und welche Berechtigungen damit verbunden sind. Das Komponentenregister zeigt, welche MCP-Server, Skills und Modelle wirklich zum Einsatz kommen – nicht nur jene, von denen Sie ausgehen.

Und damit ist es nicht am ersten Tag getan: Der Abgleich (DIS-07) zeigt Ihnen, wenn das Profil nicht mehr aktuell ist – etwa durch einen neuen MCP-Server oder eine veränderte Aufgabe. Das Paper stellt ausdrücklich klar: Discover ist kein statisches Register, sondern eine kontinuierlich abgeglichene operative Sicht.

Mit Constrain beginnen Sie, Kontrollen durchzusetzen; mit Discover finden Sie heraus, was durchgesetzt werden muss. Setzen Sie beides nacheinander um, aber trennen Sie es nicht voneinander: Discover liefert eine äußerst wichtige Grundlage dafür, wie Sie Einschränkungen definieren. Deshalb sollte es gleich zu Beginn angegangen werden.

Gemeinsam genutzte interne Agents: Beginnen Sie mit Authorize

Sandboxing bringt hier kaum etwas, denn das Risiko liegt nicht im möglichen Schadensradius auf einem Host, sondern beim „Confused Deputy“. (Es geht um Berechtigungen. Das Konzept stammt von Norm Hardy aus dem Jahr 1988: Ein Programm mit legitimen Berechtigungen wird dazu verleitet, sie im Auftrag des falschen Prinzipals einzusetzen. Es wird nichts kompromittiert, nichts entkommt der Isolation und keine Sicherheitslücke wird ausgenutzt – doch der Stellvertreter kann einfach nicht erkennen, in wessen Namen er handelt.)

Bei der schnellsten Integration erhält der Agent ein einziges Servicekonto, über das alle Anfragen laufen. Das funktioniert sofort – und genau das ist das Problem. Jede Anfrage landet nun im selben Berechtigungspool. Wenn eine Anfrage die interne API erreicht, ist nicht mehr erkennbar, von wem sie stammt. So kann ein Prompt mit Daten von Alice Berechtigungen nutzen, die eigentlich für Bob vorgesehen sind. Dem Modell aufzutragen, die Arbeit der beiden getrennt zu halten, ist eine Bitte – keine Sicherheitsgrenze.

Bei diesem Anwendungsfall müssen Berechtigungen strukturell geregelt sein: Jede Partei, die an einer Aktion beteiligt ist, benötigt eine eigene, überprüfbare Identität, die der auslösenden Person oder einem genehmigten autonomen Zweck zugeordnet ist (AUT-01). Die Berechtigungen müssen auf die Aufgabe beschränkt sein und dürfen nicht einfach vom Konto übernommen werden (AUT-02): Das Prinzip der geringsten Berechtigungen begrenzt den Umfang des Zugriffs, während die Delegation festlegt, warum, wofür und wie lange er gilt. Durch die Abstufung entlang der Aufrufkette (AUT-03) erhält ein nachgelagerter Agent niemals mehr Berechtigungen als der aufrufende Agent.

Dann kommt die Korrelation (OBS-02), denn bei einem Agent, den mehrere Personen nutzen, lautet die Audit-Frage nicht „Ist etwas passiert?“, sondern „In wessen Namen ist es passiert?“. Ohne eine Laufkennung, die Anfrage und Aktion verknüpft, können Sie diese Frage im Nachhinein nicht beantworten – und genau dann wird man sie Ihnen stellen.

Produktiv eingesetzte Agents: Beginnen Sie mit Respond und Validate

Bei Agenten, die mit Kunden und Transaktionen interagieren, sind vor allem die Kontrollen wichtig, an die niemand denkt, bis sie gebraucht werden. Beginnen Sie deshalb mit einer Frage: Was würde mit der Arbeit passieren, wenn Sie diesen Agenten sofort stoppen müssten?

Das Problem: Die meisten Teams können diese Frage nicht beantworten – und genau hier wird die Lücke sichtbar. RES-01 besagt, dass ein Stopp bedeutet, neue Arbeit zu blockieren, laufende Ausführungen anzuhalten und die dabei erstellten Anmeldedaten, Berechtigungen, delegierten Zugriffsrechte und Sitzungen zu widerrufen – entlang der Delegationskette, nicht nur beim sichtbaren Prozess. Wenn Sie den Container löschen, aber das Token aktiv lassen, haben Sie nichts gestoppt. RES-02 ergänzt den wirklich neuen Aspekt: Bei der Quarantäne geht es oft um eine Komponente, nicht um einen Host. Eine manipulierte Skill-Datei oder ein kompromittierter MCP-Server kann von Dutzenden Agenten gemeinsam genutzt werden. Da die Bereitstellung so einfach sein kann wie das Ablegen einer Datei in einem Verzeichnis, bewirkt das Entfernen einer einzelnen Kopie nichts.

Dann gibt es noch RES-04 – die Kontrolle, die unserer Einschätzung nach fast überall fehlt: eine Alternative ohne Agent für Arbeiten, die nicht warten können. Sobald ein Workflow von einem Agenten abhängt, liegt die Fähigkeit, die Arbeit zu erledigen, beim Agenten statt bei der Plattform. Stoppen Sie ihn, bleibt die Arbeit liegen. Für welche Workflows braucht es einen dokumentierten manuellen Ablauf – und wie sieht dieser aus? Das müssen Sie vor dem Vorfall entscheiden.

Und auf der Validierungsseite steht VAL04: Ein Agent kann eine Aktion erfolgreich ausführen und trotzdem das falsche Ergebnis erzielen, denn eine Berechtigung garantiert keine Korrektheit. Besonders bei irreversiblen Aktionen sollten Sie das geplante Ergebnis vor dem Abschluss validieren, nicht erst das Resultat danach.

Mit diesem Teil der Architektur beschäftigen wir uns bei Snyk. Es geht nicht nur darum, ob der Code und die Abhängigkeiten eines Agenten sicher sind, sondern auch darum, ob sein Verhalten zur Laufzeit innerhalb seiner Befugnisse bleibt: was er tun darf, in wessen Auftrag und was passiert, wenn er diese Grenzen überschreitet. Viele Bereiche der Baseline liegen außerhalb unseres Zuständigkeitsbereichs – genau darum geht es bei einem herstellerunabhängigen Modell.

Die Balance ist eine Designentscheidung, nicht zwangsläufig ein Kompromiss

Wenn die Lage beunruhigend wird, ist der erste Impuls oft, alles zu blockieren: Tools verbieten, abwarten, bis sich der Markt beruhigt hat, und sagen: „Darüber sprechen wir nächstes Jahr noch einmal.“

Das funktioniert jedoch nicht – und zwar nicht aus dem üblicherweise genannten Grund. Es geht nicht nur darum, dass die Schattennutzung weitergeht (denn das tut sie), sondern auch darum, dass Sie durch eine Blockade den Einblick in genau das verlieren, worüber Sie sich Sorgen machen, während das Unternehmen es trotzdem einsetzt. So tragen Sie dasselbe Risiko, haben aber weniger Informationen darüber.

Noch problematischer ist der gegenteilige Impuls: alles genehmigen, ein wenig überwachen und das Ganze „Governance“ nennen. Einen Agenten zu beobachten, ist nicht dasselbe, wie seine Handlungsspielräume zu begrenzen.

Was tatsächlich funktioniert, ähnelt weniger einer Entscheidung als vielmehr einer Architektur. Die Kontrollen der Baseline sind so konzipiert, dass sie außerhalb des Modells greifen, denn sie dürfen nicht davon abhängen, dass der Agent Anweisungen befolgt. So lässt sich die Produktivitätsfrage sachlich angehen: Sie entscheiden nicht, wie sehr Sie dem Agenten vertrauen, sondern wie viele Befugnisse die Arbeit erfordert – und setzen diese Grenze dann an einer Stelle durch, an der der Agent sie nicht infrage stellen kann. Innerhalb dieser Grenze kann er arbeiten.

Auch abgestufte Reaktionen sind wichtig. Eine Ablehnung, die nur „Nein“ sagt, lädt zu erneuten Versuchen und Umgehungen ein. Eine Ablehnung hingegen, die den Grund und den geregelten nächsten Schritt nennt, registriert die Komponente, fordert eine begrenzte Erhöhung der Berechtigungen mit Begründung an, holt eine unabhängige Genehmigung ein und lenkt die Ausführung zurück in die vorgesehenen Grenzen, ohne sie zu beenden. Zwischen Lenken und Stoppen kann die Berechtigung der laufenden Ausführung vorübergehend eingeschränkt werden, während eine Person entscheidet. Wenn Sie sofort komplett stoppen, wird jede Anomalie zum Dienstausfall.

Was im Dokument noch fehlt

In der Agent Baseline fehlen zwei Dinge. Wir möchten sie lieber offen ansprechen, statt Sie selbst darauf stoßen zu lassen.

Erstens gibt es kein Reifegradmodell. Die Kontrollen zeigen, wie ein guter Zustand aussieht, sagen aber nicht, worin sich „gut auf Stufe eins“ von „gut auf Stufe drei“ unterscheidet. Jede Organisation, die das hier liest, steht an einem anderen Punkt. Ein Abdeckungstest, der ein Unternehmen der Series B und eine globale Bank gleichbehandelt, hilft keiner der beiden Seiten wirklich weiter. Die oben beschriebene Priorisierung nach Anwendungsfall ist nur der Anfang dieser Arbeit, nicht ihr Abschluss.

Zweitens fehlt in Version 1.0 die Perspektive nach Anwendungsfällen vollständig. Sie finden sie hier, weil sie aus Gesprächen wie unserem bei Black Hat hervorgegangen ist. Das spricht dafür, dass der Prüfprozess funktioniert – und noch mehr dafür, dass uns dieser Punkt früher hätte auffallen sollen.

Lesen Sie die Baseline und wirken Sie daran mit

Wir sind sehr zufrieden mit diesem Ausgangspunkt. Zugleich wissen wir, dass es Menschen gibt, die diese Arbeit schon länger steuern und messen, als es die Baseline gibt – mit klaren Ansichten und belegbaren Erfahrungen. Genau von diesen Menschen möchten wir hören, und zwar jetzt: Die Baseline steht bis zum 30. September zur Kommentierung offen und bleibt unabhängig davon Open Source.

Die Baseline ist ein Entwurf, der bis zum 30. September zur Kommentierung offensteht. Die Kontrollen haben dauerhafte Kennungen. So können Sie sie in einem Audit-Befund, einem Richtliniendokument oder einer RFP-Antwort zitieren und sicher sein, dass der Verweis auch künftig gültig bleibt.

Mit einem Issue können Sie der Baseline dauerhaft widersprechen. Ist eine Kontrolle in der Praxis unwirksam, fehlt eine wichtige Kontrolle oder kostet ihre Umsetzung mehr, als sie an Risiko reduziert? Genau für dieses Feedback gibt es die Prüfphase. Ziel ist ein gemeinsames, herstellerunabhängiges Modell, an dem wir uns orientieren und an dem wir unsere Fortschritte messen können.

Sehen Sie sich die Agent Baseline an, lesen Sie das Whitepaper und hinterlassen Sie einen Kommentar auf GitHub, um mitzuwirken.