KI-Agenten in der Container-Security: Erfahrungen aus der Praxis

Ein neuer CVE-Bericht landet in der Security-Pipeline, Scanner melden Befunde quer durch den Stack, irgendwo entsteht ein Ticket: Bitte prüfen, ob das Image neu gebaut werden muss. In der Zwischenzeit läuft die betroffene Anwendung weiter – mit einer bekannten Schwachstelle, für die es längst einen Fix gibt 1.

Das ist kein Versagen eines einzelnen Teams. Es ist ein strukturelles Problem: Es gibt so viele gemeldete CVEs, dass menschliche Reviewer sie nicht mehr bewältigen können. Allein im Linux-Kernel kommen pro Jahr Hunderte Sicherheitsmeldungen zusammen, dazu Bibliotheken, Runtimes und Systempakete. Jedes davon muss überwacht, bewertet und bei Bedarf in jedem Image neu gebaut werden, das es enthält 1.

Die klassische Antwort heißt „mehr Automatisierung im CI/CD-Prozess“. Sie ist richtig, aber nicht ausreichend. Automatisierung beschleunigt das Bauen. Sie beantwortet nicht die Frage, wann gebaut wird, was gebaut wird und ob der Rebuild das Sicherheitsproblem tatsächlich löst. Red Hat hat in seinem Hummingbird-Projekt eine andere Antwort ausprobiert: KI-Agenten, die genau diese Urteilsarbeit übernehmen. Was dabei herausgekommen ist, ist ein Erfahrungsbericht mit übertragbaren Erkenntnissen – nicht nur für Red-Hat-Kunden.

Dieser Artikel fasst zusammen, was Red Hat konkret gebaut hat, welche zwei Arten von Arbeit dabei getrennt werden, wie Agenten gegen Prompt Injection abgesichert werden und was Teams daraus übernehmen können.

Kurzantwort

Wie Red Hats Hummingbird-Projekt KI-Agenten einsetzt, um Container-Images in Richtung Zero-CVE zu bewegen – und wo menschliches Urteil unverzichtbar bleibt. Kurz gesagt: cybersecurity praxis ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

Das Problem, das kein Patch-Zyklus löst

Wer Container-Images in Produktion betreibt, kennt den Teufelskreis. Ein Fix in einem RPM-Paket nützt erst etwas, wenn jedes abhängige Image neu gebaut und getestet wurde. Ohne Automatisierung wartet ein Fix auf einen Menschen, der ihn bemerkt und anstößt 1.

Red Hats erklärte Antwort ist Project Hummingbird, ein Open-Source-Projekt, das das CVE-Problem auf der Distributionsseite angehen will. Das Projekt baut und wartet minimale, gehärtete Container-Images – die „Red Hat Hardened Images“ – unter einem vollautomatischen Supply-Chain-Prozess 1.

„Minimal“ heißt dabei wörtlich: Ein Image enthält nur das Nötigste. Shell, Paketmanager und Debug-Tools landen nicht im Produktions-Image. Jede Zeile Code, die nicht im Image ist, reduziert dessen Angriffsfläche. Wer einen Container kompromittieren will, muss mit dem arbeiten, was tatsächlich darin enthalten ist 1.

Das Portfolio umfasst derzeit über 65 Images für Laufzeitumgebungen wie Java, Python, Node.js, Go, .NET und PHP, aufgebaut auf über 400 RPM-Paketen, die kontinuierlich überwacht werden. Das selbst gesetzte Sicherheitsziel, die Sicherheits-SLO, ist konkret gefasst: Von der Bereitstellung eines Fixes bis zum fertig getesteten, ausgelieferten Image vergehen weniger als 24 Stunden 1.

Das erklärte Ziel sind Zero-CVE-Images – Images ohne eine einzige bekannte Schwachstelle zum Auslieferungszeitpunkt. Nach Angaben des Teams wird das täglich erreicht, weil kein Fix auf einen Menschen warten muss 1. Die Projekt-Dokumentation beziffert den Umfang: über 400 Pakete und mehr als 1.750 Image-Builds, die mit der 24-Stunden-SLO betrieben werden 2.

Wichtig für die Einordnung: Der Ansatz ist nicht einzigartig. Chainguard verfolgt mit seiner Wolfi-Distribution eine ähnliche Philosophie – minimale Angriffsfläche, kontinuierliche Updates, SBOM-Transparenz. Der wesentliche Unterschied liegt im Ökosystem: Wolfi kommt aus der Alpine-Linux-Welt und ist musl/apk-basiert. RHEL-Kompatibilitätsgarantien und Zertifizierungen spielen dort keine Rolle 1. Jedes Hummingbird-Image ist außerdem in einer FIPS-Variante mit FIPS-140-3-validierten Kryptomodulen aus RHEL verfügbar, was für regulierte Umgebungen den Unterschied ausmachen kann 1.

Die Kernentscheidung: zwei Klassen von Arbeit trennen

Was Hummingbird von einem „besseren CI/CD-Prozess“ unterscheidet, ist ein Architekturprinzip. Die Pipeline ist keine beschleunigte Version des alten Workflows, sondern anders aufgebaut. Das Credo lautet: so viel deterministische Automatisierung wie möglich, so viel Agentic AI wie nötig 1.

Dahinter liegt eine strikte Trennung zwischen zwei Klassen von Arbeit:

Deterministische Arbeit ist alles, was sich nach definierten Regeln entscheiden lässt. Ein Upstream-Package-Update ist verfügbar. Eine Lockfile-Synchronisierung ist nötig. Ein CVE-Fix liegt im zugehörigen RPM vor. Solche Änderungen werden automatisch als Merge Request erstellt und mergen nach grüner CI selbstständig – ohne Ticket, manuelles Review oder Warteschleife. Auf diese Weise entstehen in den Hummingbird-Repositories über 1.000 automatische Commits pro Woche 1, 2.

Urteilsarbeit ist alles, wofür Regelwerke allein nicht ausreichen. Warum schlägt ein Build auf ARM64 fehl, aber nicht auf x86? Welche der zehn fehlgeschlagenen Tests hängen zusammen? Ist eine API-Änderung ein Breaking Change oder ein harmloses Refactoring? Das sind die Fragen, für die Agenten zuständig sind 1.

Diese Trennung ist der Kern der Architektur. Wird sie nicht gezielt gezogen, drohen zwei Extremfälle: Bei zu viel Automatisierung treffen Agenten zu viele Entscheidungen, die plausibel klingen, aber falsch sind. Bei zu wenig Automatisierung beschäftigen sich Entwickler mit Routinearbeit, für die kein menschliches Urteil nötig wäre 1.

Die Projekt-Dokumentation formuliert das Prinzip noch schärfer als Accountability-Frage: Von Agenten produzierter Code wird nicht ohne menschliche Freigabe gemergt. Der Mensch wird nicht eliminiert, sondern dorthin verschoben, wo sein Urteil tatsächlich zählt 3.

cybersecurity praxis – Illustration 2

Der Stack im Detail

Der technische Unterbau ist überschaubar und weitgehend mit gängiger Open-Source-Software gebaut. Source Control und CI/CD laufen vollständig auf GitLab. Die drei zentralen Repositories (containers, rpms, tools) werden über Konflux gebaut und getestet, einem auf Tekton und OpenShift basierenden Build-System. Pipelines-as-Code steuert, welche Pipeline bei welchem Ereignis ausgelöst wird. Tests laufen auf Testing Farm, Container-Images landen auf Quay.io, RPM-Pakete in Pulp-Repositories. Dependency-Updates übernimmt Renovate, das automatisch Merge Requests für neue Paketversionen öffnet 1.

Entscheidend ist die Rolle der KI in diesem Stack. Renovate arbeitet rein deterministisch – keine Heuristik, keine KI, nur Regeln. Die Agenten kommen erst bei der Urteilsarbeit ins Spiel: als Python-Prozesse in isolierten Sandbox-Containern ohne Zugriff auf Secrets oder Deployment-Token. Lokal läuft das Container-Management über Podman, in der Produktion über OpenShift. Als Modelle kommen derzeit Gemini 3.1 Pro Preview und Claude Sonnet zum Einsatz, je nach Workflow und Repository; andere Modelle sind über Konfigurationsparameter austauschbar 1.

Eine Zahl, die für viele Teams relevant sein dürfte: Über alle drei produktiven Repositories hinweg lagen die API-Kosten im Juni 2026 bei rund 90 US-Dollar für 314 Agent-Sessions – im Schnitt unter 30 Cent pro Session. Prompt-Caching reduziert die Kosten um 60 bis 70 Prozent 1. Bei dieser Art von Arbeit sind die Modellkosten der kleinste Posten.

Die Workflow-Logik ist bewusst außerhalb des Python-Codes gehalten. Jeder Agent liest seine Arbeitsanweisung aus einer Markdown-Datei. Ein gekürzter Ausschnitt aus der Konfiguration zeigt das Muster 1:

# AGENTS.md-Muster
mdworkflows:
  analyze-failures:
    trigger: pipeline          # wird bei jedem Pipeline-Fehler ausgelöst
    prompt: workflows/analyze-failures.md
    action: post_gitlab_note   # Befund als MR-Kommentar
    model: gemini-3.1-pro-preview
    data_sources:
      gitlab: {}               # CI-Logs, MR-Diff
      konflux: {}              # Tekton PipelineRuns und TaskRuns
      testing_farm: {}         # Testergebnisse

  code-review:
    trigger: merge_request
    prompt: workflows/code-review.md
    model: gemini-3.1-pro-preview
    max_iterations: 15
    context_limit: 500000      # Token-Budget für große Diffs

Diese Workflow-Markdown-Dateien sind öffentlich im Hummingbird-Repository einsehbar und beschreiben im Klartext, was der Agent tut: welche Daten er zuerst abruft, wie er Fehler klassifiziert, in welcher Reihenfolge er Review-Prioritäten abarbeitet. Wer das AGENTS.md-Muster übernehmen will, findet dort konkrete Vorbilder 1.

Die beiden produktiven Agenten

Derzeit sind zwei Agenten produktiv im Einsatz, beide mit klar abgegrenzten Aufgaben 1:

Der Failure-Analysis-Agent greift ein, wenn ein Build fehlschlägt. Er wertet CI-Logs, Build-Pipeline-Ergebnisse und Testergebnisse aus, korreliert Fehler über Images und Architekturen hinweg und erkennt Muster – etwa: „Dieser Fehler tritt auf ARM64 in allen Images auf, die eine bestimmte Bibliothek enthalten.“ Was ein Entwickler früher in 30 bis 60 Minuten hätte zusammentragen müssen, erscheint als kommentierter Befundbericht direkt auf dem Merge Request, mit Links zu relevanten Artefakten und einer Hypothese zur Ursache 1.

Der Code-Review-Agent liest jeden Merge Request nach einer definierten Priorität: Sicherheit zuerst, dann Korrektheit, Performance, Wartbarkeit. Er liest vor dem Posten die bisherige Review-Diskussion, um bereits geklärte Punkte nicht erneut aufzuwerfen, und integriert Feedback aus früheren Reviews in spätere Iterationen. Er ersetzt keinen menschlichen Reviewer, sondern übernimmt die Vorarbeit bis zu dem Punkt, an dem Entwickler eingreifen 1.

Weitere Agenten sind in Entwicklung: ein als Product Manager konfigurierter Agent für Priorisierung und Machbarkeitsbewertung, ein Engineering-Agent für autonome Implementierungen, ein Tech-Writer-Agent für Dokumentation und ein Testing-Agent für Testgenerierung 1. In der Praxis gilt der Leitsatz: Agenten produzieren Merge Requests, Menschen entscheiden 1, 3.

Prompt Injection: Isolation auf zwei Ebenen

Bei Agenten in sicherheitskritischen Pipelines stellt sich immer die Frage nach der Gefahr durch Prompt Injection. Schon ein manipuliertes Paket-Changelog oder eine präparierte CI-Ausgabe kann einen Agenten zu unerwünschten Aktionen verleiten. Red Hat begegnet dem mit Isolation auf zwei Ebenen 1.

Erstens laufen Agenten in isolierten Sandbox-Containern ohne direkten Zugriff auf Secrets oder Deployment-Token. Was der Agent sehen und tun kann, ist durch den Container definiert – nicht durch das, was er zu analysieren bekommt. Zweitens sind Schreib- und Leseberechtigungen konsequent getrennt. Secrets liegen in HashiCorp Vault. Der Orchestrator authentifiziert sich per AppRole mit Read-only-Zugriff und injiziert Token in die Datenbankverbindungen, ohne sie je in den Sandbox-Container zu übergeben. Schreib-Token für GitLab laufen in einem separaten Codepfad, der nie mit dem Modell-Loop in Berührung kommt. Das Sicherheitsmodell greift unabhängig davon, was in den Eingabedaten steht 1.

Die Projekt-Dokumentation bringt den zentralen Gedanken auf den Punkt: Ein Agent, der keine Zugangsdaten lesen und nicht auf externe Systeme schreiben kann, ist in der Praxis nur ein weiterer Contributor. Damit wird Prompt Injection als Bedrohung praktisch neutralisiert – der schlimmste Fall ist ein Merge Request niedriger Qualität, und genau den soll der Review-Prozess auffangen 3.

Der eigentlich limitierende Faktor: Kontext

Die wichtigste Erkenntnis aus über einem Jahr produktiver Arbeit mit Agentic AI ist zunächst enttäuschend für alle, die auf das nächste Modell hoffen: Der limitierende Faktor ist nicht das Modell, sondern der Kontext, den es bekommt 1.

Ein Agent, der ohne Hintergrundinformationen in ein Repository geworfen wird, produziert Code, der technisch korrekt ist, aber nicht zum Kontext passt. Er kennt weder die Invarianten des Projekts noch die Konventionen oder die Entscheidungen, die bereits getroffen wurden – und warum. Das gilt für jede Form von Dokumentation, nicht nur für AGENTS.md-Dateien: ein gepflegtes README, klare Commit-Messages, kommentierte Architekturentscheidungen und ein aktuelles Changelog sind allesamt Kontext, den ein Agent nutzen kann 1.

In Hummingbird wurde deshalb das AGENTS.md-Muster eingeführt: Jedes Repository enthält eine Datei, die dem Agenten erklärt, wie das Repository aufgebaut ist, welche kritischen Invarianten gelten, welche Konventionen üblich sind und welche Fehler in der Vergangenheit teure Folgen hatten. Der Agent liest sie, bevor er irgendetwas produziert. Die Qualität lässt sich direkt messen: Aussagekräftige Dokumentation führt zu funktionierenden ersten Entwürfen, fehlende oder unklare Dokumentation zu vielen Iterationsrunden 1.

Die Projekt-Dokumentation formuliert das Prinzip als „Documentation as Infrastructure“: Die Qualität dessen, was ein Agent produziert, ist begrenzt durch die Qualität dessen, was er lesen kann. Ein Agent mit guter Dokumentation denkt von derselben Grundlage aus wie das Team; ein Agent ohne sie rät 3.

Feedback ist nicht Bonus, sondern Produkt

Der am häufigsten fehlende Kontext beim Einstieg ist eine andere Information: Was wurde in der Vergangenheit abgelehnt, und warum? Deshalb behandelt Red Hat die Review-Kommentare menschlicher Entwickler auf agentenproduzierten Merge Requests als Produktionsdaten – was hat der Agent falsch eingeschätzt, wo war der Prompt unscharf, welche Information fehlte in der AGENTS.md? Diese Antworten fließen systematisch zurück in Dokumentation, Prompt-Definitionen und Workflow-Beschreibungen 1.

Das erhöht den organisatorischen Aufwand, ist aber nötig. Ein Agent ohne Feedback kann sich über Monate nicht weiterentwickeln; einer im strukturierten Feedback-Loop verbessert sich messbar, weil er präziseren Kontext erhält. Entscheidend ist die Unterscheidung: Man wartet nicht auf das nächste Modell, sondern verbessert die Eingaben 1.

Auch hier deckt sich die Außendarstellung mit dem internen Bericht. Die Dokumentation beschreibt denselben Mechanismus als „Learning from Feedback“: Wenn ein Reviewer einen agentenproduzierten Merge Request kommentiert, liest der Agent die Diskussion, integriert das Feedback und aktualisiert seine Arbeit. Dieses Feedback wird gespeichert, damit spätere Läufe darauf aufbauen können 3.

Was Agenten heute noch nicht können

Der Erfahrungsbericht bleibt an dieser Stelle ehrlich. Agenten leisten gute Dienste bei lokal abgrenzbaren Aufgaben: einen Test für eine bekannte Funktion schreiben, eine bestehende Logik auf einen neuen Fall ausdehnen oder einen Fehler analysieren, dessen Kontext vollständig in den Logs steht. Deutlich schwächer sind sie bei Aufgaben, die latentes Architekturwissen erfordern: Warum wurde diese Schnittstelle so entworfen? Welche Downstream-Abhängigkeiten bricht die Änderung? Wo liegt die richtige Grenze eines Moduls 1?

Für Project Hummingbird heißt das: Architekturentscheidungen bleiben beim Menschen, die Umsetzung übernehmen zunehmend Agenten. Die Fähigkeit, diese Grenze richtig zu ziehen – zu wissen, was man selbst entscheiden muss und was sich sinnvoll delegieren lässt – ist die wichtigste Kompetenz, die sich seit dem Start Anfang 2025 entwickelt hat 1.

Drei Erkenntnisse bleiben nach einem Jahr intensiver Arbeit in einer produktionskritischen Pipeline 1:

Determinismus geht vor Agenten. Erst definieren, was sich als Regel formulieren lässt, dann fragen, wofür ein Agent gebraucht wird. Wer das umdreht, delegiert Unklarheit statt Aufgaben.

Dokumentation bedeutet Kontext, Kontext liefert Qualität. Der limitierende Faktor ist nicht das Modell. Eine AGENTS.md pro Repository ist ein konkreter erster Schritt.

Feedback schlägt Modellstärke. Statt auf das nächste KI-Modell zu warten, die Eingaben verbessern – systematisch und nach jedem Review-Zyklus.

Übertragbar auf jeden Stack

Das beschriebene Modell ist kein exklusives Red-Hat-Spielzeug. Der Stack selbst spielt eine untergeordnete Rolle – das gilt gleichermaßen mit Konflux, GitHub Actions, RPMs oder apk. Die Trennung zwischen deterministischer Arbeit und Urteilsarbeit, das AGENTS.md-Muster und der Feedback-Loop zwischen menschlichem Review und Agenten-Kontext lassen sich auf jede Organisation übertragen, die Container-Images oder andere Softwareartefakte in Pipelines baut. Es zählt allein die Disziplin, die Grenze zu ziehen 1.

Ein offenes Problem bleibt die Laufzeitumgebung der Agenten selbst. Heute betreibt Red Hat eigenen Python-Code für Isolation, Credential-Handling und die Integration mit GitLab und Konflux. Das funktioniert, ist aber kein Standard, den andere ohne Weiteres übernehmen können. Als vielversprechende Ablösung nennt das Team OpenShell von Nvidia, eine sichere, isolierte Laufzeit für autonome Agenten, die Isolation auf mehreren Ebenen (Dateisystem, Netzwerk, Prozess, Credential-Zugriff) über deklarative YAML-Policies erzwingt. Das Projekt ist noch im Alpha-Stadium, zeigt aber in die richtige Richtung; Red Hat beteiligt sich aktiv als Maintainer 1.

Drei konkrete Startpunkte für eigene Pipelines nennt der Bericht 1:

Identifiziere den teuersten manuellen Schritt. Welcher wiederkehrende Schritt verbraucht am meisten menschliche Aufmerksamkeit? Zuerst prüfen, ob er sich als deterministische Regel formulieren lässt – oft lautet die Antwort ja.

Lege für das erste Repository mit Agenten eine AGENTS.md an. Beschreibe die Invarianten, Konventionen und teuersten Fehler der Vergangenheit. Vorbilder finden sich unter agents.md und in den öffentlichen Hummingbird-Repositories 1, 4.

Baue einen Feedback-Loop. Behandle die Review-Kommentare des Teams auf agentenproduzierten Merge Requests als Eingabe für den nächsten Prompt.

Was man daraus für die eigene Pipeline mitnehmen kann

Die Übertragung auf das eigene Setup ist die eigentliche Leseraufgabe dieses Artikels. Die Struktur dafür ist aus den oben genannten Fakten direkt ableitbar und weder an Red Hat noch an ein bestimmtes Modell gebunden.

Erstens: Inventar der eigenen Vorgänge erstellen und nach den beiden Klassen sortieren. Was sich als Regel formulieren lässt, gehört in deterministische Automatisierung. Was übrig bleibt, ist potenzielle Urteilsarbeit.

Zweitens: Nicht jede Urteilsarbeit braucht einen Agenten. Der Bericht macht einen Umkehrschluss explizit: Wer versucht, einem Agenten eine Aufgabe zu erklären, und dabei feststellt, dass er sie selbst nicht klar beschreiben kann, hat ein untrügliches Signal dafür, dass die passende Regel fehlt 1. Der Klärungsprozess ist anstrengend, lohnt aber – ihn zu überspringen delegiert nur Unklarheit.

Drittens: Wer einen Agenten einsetzt, muss den Kontext liefern, bevor er das Modell startet. Die minimale Umsetzung ist eine AGENTS.md im Repository, die Invarianten und historische Fehler benennt. Ohne sie rät der Agent – und das zeigt sich als viele Iterationsrunden 1, 3.

Viertens: Prompt Injection nicht als theoretisches Problem behandeln, sondern als Architekturfrage lösen. Die beiden Hebel aus dem Bericht sind übertragbar: Agenten ohne Zugriff auf Secrets und ohne Schreibrechte auf externe Systeme laufen lassen, und Lese- von Schreibpfaden strikt trennen, sodass der Modell-Loop nie mit einem Schreib-Token in Berührung kommt 1, 3.

Wer den direkten Vergleich sucht: Red Hats Hummingbird zielt als Early-Access-Programm auf Red-Hat-Abonnementkunden mit einem Katalog minimaler, gehärteter Images 5. Die Methodik dahinter – Trennung von Regel und Urteil, Dokumentation als Agentenkontext, strukturierter Feedback-Loop – ist der übertragbare Teil und funktioniert unabhängig davon, ob man Red-Hat-Kunde ist oder nicht 1.

Worauf es nicht ankommt

Der Bericht räumt mit zwei verbreiteten Annahmen auf, die sich nicht belegen lassen.

Die erste: Es brauche das neueste und stärkste Modell. Das Team nutzt mehrere Modelle je nach Workflow und tauscht sie über Konfigurationsparameter aus; die Aussage „Wir warten auf das nächste Modell“ wird explizit als falscher Fokus markiert 1. Entscheidender sind Kontext und Feedback.

Die zweite: Mehr Automatisierung sei automatisch besser. Der Bericht warnt vor zu hohem Automatisierungsgrad, bei dem Agenten plausibel klingende, aber falsche Entscheidungen treffen 1. Die Grenze zwischen Determinismus und Urteil muss aktiv gezogen und gepflegt werden.

Passende Produktrecherchen

Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

cybersecurity praxis – Illustration 3

Weiterführende Artikel

Häufige Fragen

Was beantwortet dieser Beitrag zu KI-Agenten in der Container-Security: Erfahrungen aus der Praxis?

Er ordnet die genannten Quellen ein und übersetzt sie in Prüfpunkte für die eigene Entscheidung. Er ersetzt keine individuelle Planung, Beratung oder Wirtschaftlichkeitsrechnung.

Welche Angaben sollte ich vor einer Entscheidung selbst prüfen?

Entscheidend sind die eigenen Verbrauchs- und Nutzungsdaten, Kosten, technische Voraussetzungen und die aktuell geltenden Regeln. Die Quellen am Ende zeigen, welche Aussagen aus der Meldung stammen und wo die Grenzen der Einordnung liegen.

Sind die genannten Zahlen auf jeden Haushalt übertragbar?

Nein. Umfrage- und Marktwerte beschreiben Gruppen oder Zeitpunkte. Ob eine Maßnahme im Einzelfall passt, hängt von den konkreten Voraussetzungen vor Ort ab.

Grenzen der Einordnung

Die zitierten Daten beschreiben eine Erhebung beziehungsweise einen allgemeinen Markt- oder Regelungsstand. Sie ersetzen weder eine technische Prüfung noch eine individuelle Kostenrechnung. Änderungen bei Preisen, Förderung, Netzentgelten oder Vorgaben können das Ergebnis beeinflussen; daher sollten Leserinnen und Leser die Primärquellen vor einer konkreten Entscheidung erneut prüfen.

Transparenzhinweis

Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.

Quellen

[1] Valentin Rothberg, Michael Krausch-Hofmann: „KI-Agenten in der Container-Security: Erfahrungen aus der Praxis“ – heise Developer, 01.09.2026, https://www.heise.de/hintergrund/KI-Agenten-in-der-Container-Security-Erfahrungen-aus-der-Praxis-11400640.html

[2] Project Hummingbird: „Agentic SDLC“ – hummingbird-project.io, https://hummingbird-project.io/docs/agentic-sdlc/

[3] Project Hummingbird: „Agentic SDLC“ (Abschnitte Responsible AI, Security, Learning from Feedback, Documentation as Infrastructure) – https://hummingbird-project.io/docs/agentic-sdlc/

[4] agents.md – Referenz für das AGENTS.md-Muster, https://agents.md/

[5] Red Hat: „Red Hat Introduces Project Hummingbird for ‚Zero-CVE‘ Strategies“ – Pressemitteilung, https://www.redhat.com/en/about/press-releases/red-hat-introduces-project-hummingbird-zero-cve-strategies