KI-Agenten-Memory ist jetzt Teil der Sicherheitsarchitektur

KI-Agenten werden nützlicher, weil sie sich Dinge merken.

Sie erinnern sich an frühere Gespräche. Sie durchsuchen Dokumente. Sie fassen Aufgaben zusammen. Sie entwickeln ein Bild von einem Projekt, einer Codebasis, einem Kunden, einem Prozess oder einem Team. Sie verbinden sich mit Notion, Slack, Google Drive, GitHub, Tickets, CRM-Systemen, Produktspezifikationen und internen Wikis.

Genau dieses Gedächtnis sorgt dafür, dass sie sich weniger wie Chatbots und mehr wie Kollegen anfühlen.

Es macht sie aber auch riskanter.

In aktuellen Sicherheitsdiskussionen rund um KI-Agenten geht es immer stärker um Memory und Context Poisoning: also darum, dass ein Agent bösartige, irreführende oder einfach minderwertige Informationen speichert, abruft oder als Kontext vertraut und diesen Einfluss in spätere Aufgaben mitnimmt. OWASP führt dieses Risiko in den Top 10 for Agentic Applications als eigene Kategorie: Memory & Context Poisoning.

Für Gründer, CTOs und Product Owner ist das kein abstraktes KI-Sicherheitsthema.

Es ist ein Architekturthema.

Wenn ein Agent sich erinnern kann, ist Memory Teil des Systems. Wenn der Agent außerdem Werkzeuge nutzen darf, wird Memory Teil des Steuerungspfads. Und wenn dieses Memory mit Unternehmensdokumenten, Kundendaten, Repositories oder Workflows verbunden ist, braucht es dieselbe Ernsthaftigkeit wie jede andere produktive Abhängigkeit.

Prompt Injection war die erste Warnung

Die meisten Teams haben inzwischen von Prompt Injection gehört.

Ein KI-System liest nicht vertrauenswürdigen Inhalt. Dieser Inhalt enthält Anweisungen. Das Modell kann diesen Anweisungen folgen, obwohl sie aus einem Dokument, einer Webseite, einer E-Mail oder einer Nutzernachricht stammen und nicht vom eigentlichen Betreiber.

Das ist bereits ernst.

Aber Prompt Injection wird oft als momentanes Problem verstanden: Das Modell hat in dieser Interaktion etwas Schädliches gesehen, also kann diese Antwort oder dieser Tool-Aufruf unsicher sein.

Memory Poisoning ist unangenehmer, weil es dauerhaft wirken kann.

Statt nur eine Antwort zu beeinflussen, wird der bösartige oder irreführende Kontext in einen Memory Store geschrieben, in eine Projekthistorie zusammengefasst, in eine Vektordatenbank eingebettet, in eine gemeinsame Wissensbasis aufgenommen oder als Präferenz behalten. Die ursprüngliche Eingabe verschwindet vielleicht aus dem Blickfeld. Der Einfluss bleibt.

Später ruft der Agent diesen Kontext wieder ab und behandelt ihn als nützlichen Hintergrund.

Damit verändert sich das Risiko.

Die Frage lautet nicht mehr nur: “Kann das Modell die Anweisung in diesem Dokument ignorieren?” Sie lautet: “Was darf dieses System aus diesem Dokument speichern, und woran erkennen wir später, ob diese Erinnerung vertrauenswürdig ist?”

Memory ist nicht neutral

Es ist verführerisch, KI-Memory als Komfortfunktion zu betrachten.

In der Praxis ist Memory ein Ranking-System, ein Vertrauenssystem und manchmal ein Entscheidungssystem.

Wenn ein Agent an einem Softwareprojekt arbeitet, kann gespeicherter Kontext beeinflussen, welche Architekturmuster er bevorzugt, welcher Service für einen Fachbegriff zuständig ist, welche Tests angeblich unzuverlässig sind, welcher Deployment-Weg normal ist oder welche Kundenanforderung besonders wichtig sein soll.

Wenn ein interner KI-Assistent einem Fachteam hilft, kann gespeicherter Kontext beeinflussen, welche Richtlinie er anwendet, welche Kundendaten er zeigt, welche Lieferantenkonditionen er für gültig hält oder welchen nächsten Workflow-Schritt er empfiehlt.

Wenn dieses Memory falsch ist, erzeugt der Agent nicht nur einen falschen Satz. Er kann wiederholt die falsche Art von Entscheidung treffen.

Noch schärfer wird das Risiko, wenn Memory geteilt wird:

• ein Mitarbeiter lädt ein Dokument hoch, das später alle beeinflusst;
• eine Projektzusammenfassung trägt eine falsche Sicherheitsannahme in künftige Arbeit;
• ein Supportgespräch wird Kontext für einen anderen Kunden;
• eine Quelle mit geringem Vertrauen landet in derselben Wissensbasis wie geprüfte Dokumente;
• ein Agent fasst vergifteten Inhalt in eine sauber klingende Notiz zusammen, die ihre Warnsignale verliert.

Der letzte Punkt ist wichtig. Sobald nicht vertrauenswürdiger Inhalt zusammengefasst wurde, wirkt er oft vertrauenswürdiger als vorher.

Hier helfen normale Architekturinstinkte aus der Softwareentwicklung. Wir wissen bereits, dass Daten Quelle, Verantwortung, Validierung, Aufbewahrung und Zugriffsregeln brauchen. KI-Memory ist davon nicht ausgenommen, nur weil daneben ein Modell steht.

Die gefährliche Abkürzung: “Wir verbinden einfach die Wissensbasis”

Viele KI-Agenten-Projekte beginnen harmlos.

“Wir verbinden ihn mit unseren Dokumenten.”

Das klingt sinnvoll. In den meisten Unternehmen ist Wissen über viele Werkzeuge verteilt: Google Drive, SharePoint, Notion, Slack, Jira, GitHub, E-Mail, PDFs, Tabellen und alte Wikis. Ein Assistent, der diesen Kontext nutzen kann, kann echte Reibung reduzieren.

Aber eine Unternehmenswissensbasis ist selten sauber.

Sie enthält Entwürfe, veraltete Prozesse, doppelte Richtlinien, widersprüchliche Entscheidungen, kundenspezifische Ausnahmen, alte Zugangsdaten in Dokumenten, Testdaten, private HR-Notizen, Vertriebsversprechen, Screenshots, Kommentare, TODOs und Meinungen, die nie operative Wahrheit werden sollten.

Menschen gehen mit diesem Durcheinander durch Urteilskraft um. Wir wissen, dass ein Dokument von 2022 veraltet sein kann, dass eine Slack-Nachricht beiläufig sein kann, dass ein Angebotsentwurf kein unterschriebener Vertrag ist und dass die Notiz eines Engineers nicht automatisch die Architektur ist.

Ein Agent braucht diese Urteilskraft als Systemdesign.

Wenn jedes abrufbare Element dasselbe Gewicht hat, erkennt der Agent nicht zuverlässig den Unterschied zwischen:

• freigegebener Richtlinie und altem Entwurf;
• Produktionsarchitektur und Brainstorming-Notiz;
• kundenspezifischem Workaround und allgemeiner Regel;
• vertrauenswürdiger Quelle und hochgeladenem, potenziell fremdgesteuertem Inhalt;
• interner Tatsache und Text aus dem öffentlichen Internet.

Das Ergebnis kann in Demos beeindruckend aussehen und trotzdem für den Produktivbetrieb ungeeignet sein.

Was vor persistentem Memory geklärt werden sollte

KI-Memory braucht nicht vor jedem sinnvollen Einsatz ein riesiges Governance-Programm. Aber es braucht bewusste Grenzen.

Die erste Frage ist einfach:

Was darf dieser Agent speichern?

Die Antwort sollte enger sein als “alles, was er sieht”. Viele nützliche Agenten brauchen kein dauerhaftes Memory für jedes Gespräch, jede Datei oder jede Aufgabe. Manche brauchen nur kurzlebigen Aufgaben-Kontext. Manche brauchen Projekt-Memory, aber kein Kunden-Memory. Manche sollten Dokumente abrufen können, aber keine neuen langfristigen Fakten ohne Freigabe speichern.

Die zweite Frage lautet:

Wer oder was darf Memory schreiben?

Es ist ein großer Unterschied, ob ein Mensch ausdrücklich eine Projektentscheidung speichert oder ob ein Agent automatisch ein nicht vertrauenswürdiges Dokument in einen dauerhaften Speicher zusammenfasst. Automatische Memory-Writes sind bequem, aber genau dort kann vergifteter Inhalt dauerhaft werden.

Die dritte Frage lautet:

Wie wird Vertrauen dargestellt?

Ein Memory-Eintrag sollte nicht nur Text sein. Er sollte Herkunft tragen: Quelle, Zeitpunkt, Owner, Geltungsbereich, Vertrauensniveau, Aufbewahrungsregel und, wo relevant, Freigabestatus. Ein aktueller unterschriebener Vertrag darf nicht behandelt werden wie eine drei Jahre alte Meetingnotiz. Ein Incident-Runbook für die Produktion darf nicht denselben Status haben wie eine KI-generierte Zusammenfassung, die niemand geprüft hat.

Die vierte Frage lautet:

Kann Memory geprüft, korrigiert und zurückgerollt werden?

Wenn ein Agent sich merkwürdig verhält, muss das Team sehen können, welchen Kontext er abgerufen hat und was zuletzt hinzugefügt wurde. Ohne Logs und Rollback werden Memory-Probleme schwer zu diagnostizieren. Der Agent kann plausible Antworten geben und dabei still auf schlechten Kontext vertrauen.

Die fünfte Frage lautet:

Welche Aktionen brauchen frische Verifikation?

Selbst vertrauenswürdiges Memory sollte für folgenreiche Aktionen nicht ausreichen. Wenn ein Agent deployen, löschen, abrechnen, freigeben, E-Mails senden, Berechtigungen ändern oder Kundendaten sichtbar machen soll, muss er gegen aktuelle autoritative Quellen prüfen und in vielen Fällen menschliche Zustimmung einholen.

Memory ist nützlich. Es ist keine Autorität.

Eine praktische Memory-Architektur für interne Agenten

Für viele Unternehmen ist ein sicherer Start nicht kompliziert. Er ist strukturiert.

Trennen Sie Memory in Kategorien.

Es gibt Working Memory: temporären Kontext für die aktuelle Aufgabe. Er darf nützlich und unordentlich sein, weil er schnell verfällt.

Es gibt Projekt-Memory: Entscheidungen, Architekturhinweise, akzeptierte Begriffe, offene Risiken und betriebliche Grenzen. Dieses Memory braucht Herkunft und Prüfregeln.

Es gibt abgerufenes Wissen: Dokumente, die der Agent durchsuchen kann, denen er aber nicht automatisch als Wahrheit vertrauen sollte. Retrieval muss Zugriffsrechte, Mandantengrenzen und Aktualität respektieren.

Es gibt autoritative Daten: führende Systeme wie CRM, ERP, Abrechnungssystem, Produktionsdatenbank oder Source Repository. Der Agent kann sie über kontrollierte APIs lesen, aber er sollte ihre Autorität nicht durch gespeicherte Zusammenfassungen ersetzen.

Diese Kategorien dürfen nicht verschwimmen.

Ein schlechtes Muster ist ein globaler Memory-Eimer für alles: Chats, Zusammenfassungen, hochgeladene Dokumente, generierte Notizen, kundenspezifische Fakten und operative Anweisungen. Das ist leicht zu bauen. Es ist schwer zu verstehen.

Ein besseres Muster ist Memory mit klaren Grenzen:

• Isolation nach Nutzer und Mandant;
• getrennte Speicher für temporären und dauerhaften Kontext;
• Freigabe, bevor wichtige Memory-Writes dauerhaft werden;
• Quellenangaben für abgerufene Ausschnitte;
• Ablaufregeln für unsichere oder temporäre Informationen;
• Quarantäne für nicht vertrauenswürdige Uploads;
• Logs für Memory Reads und Writes;
• Tests, die vergiftete Dokumente und irreführende Zusammenfassungen simulieren.

Das macht das System nicht perfekt. Aber es macht das Risiko sichtbar und beherrschbar.

Warum das für KI-gestützte Softwareentwicklung wichtig ist

Coding Agents sind ein besonders interessanter Fall.

Sie arbeiten besser, wenn sie die Codebasis verstehen. Sie brauchen Kontext: Konventionen, Architekturentscheidungen, gescheiterte Ansätze, Teststrategie, Deployment-Regeln und Produktgrenzen. Ein Coding Agent ohne Memory verliert Zeit, weil er dieselben Dinge immer wieder neu herausfindet.

Ein Coding Agent mit unkontrolliertem Memory kann aber auch schlechte Annahmen weitertragen.

Er könnte sich merken, dass ein fehlschlagender Test “wahrscheinlich flaky” ist, obwohl er einen kritischen Randfall schützt. Oder dass direkte Datenbankwrites normal sind, weil er ein altes Migrationsskript gesehen hat. Oder dass eine Servicegrenze ignoriert werden kann, weil ein Notfallpatch das vor sechs Monaten einmal getan hat. Oder dass eine Abhängigkeit freigegeben ist, weil ein technischer Entwurf das behauptete.

Der Agent beschädigt das System dann vielleicht nicht in einer spektakulären Einzelaktion. Er normalisiert langsam das falsche Muster.

Deshalb gehört Memory-Design neben Architektur- und Review-Design. Das Team sollte entscheiden, welche Konventionen offiziell sind, welche Notizen nur Historie darstellen, welche Tests verpflichtend sind, welche Umgebungen tabu sind und welche Änderungen menschliche Prüfung brauchen.

Die Haltung von McDougall Digital ist einfach: KI-gestützte Entwicklung ist wertvoll, wenn sie Lieferfähigkeit erhöht, ohne Architekturverantwortung zu schwächen. Persistenter Kontext kann helfen, aber nur wenn das Team sehen kann, woher dieser Kontext kommt und wie viel Autorität er haben darf.

Die Kundenfrage: Bauen Sie einen Assistenten oder einen operativen Akteur?

Wie vorsichtig ein Team sein muss, hängt davon ab, was das KI-System tun kann.

Wenn ein Assistent nur interne Texte entwirft und kein persistentes Memory hat, ist das Risiko begrenzt.

Wenn er Unternehmensdokumente abruft, steigt das Risiko.

Wenn er Memory schreibt, das spätere Antworten beeinflusst, steigt es erneut.

Wenn er Tools aufrufen, Systeme aktualisieren, Pull Requests erstellen, Nachrichten senden, Daten ändern, Workflow-Schritte freigeben oder mit Kunden interagieren kann, wird Memory Teil der operativen Sicherheit.

An diesem Punkt sollte das Team das Projekt nicht mehr als “KI-Feature” behandeln, sondern als Softwarearchitektur.

Bevor ein Agent mit echten Geschäftsworkflows verbunden wird, sollten Sie fragen:

• Welche Quellen darf er lesen?
• Welche Quellen sind autoritativ?
• Was darf er dauerhaft speichern?
• Wer kann diese Quellen absichtlich oder versehentlich vergiften?
• Wie wird Memory zwischen Nutzern, Kunden und Projekten getrennt?
• Was wird geloggt, wenn Memory sich ändert?
• Wer kann Memory-Einträge prüfen oder löschen?
• Welche Aktionen brauchen aktuelle Quellenprüfung statt erinnerten Kontext?
• Was passiert, wenn der Memory Store falsch ist?

Das sind keine theoretischen Fragen. Sie entscheiden darüber, ob ein interner Assistent hilfreich ist oder still operatives Risiko ansammelt.

Wie McDougall Digital helfen kann

KI-Agenten können in ernsthaften Produkten und internen Systemen wirklich nützlich sein. Sie können wiederholte Arbeit reduzieren, Unternehmenswissen leichter nutzbar machen, Entwicklungsteams unterstützen und eng begrenzte operative Workflows automatisieren.

Aber sie brauchen klare Architektur rund um Memory, Tools und Verantwortung.

McDougall Digital hilft Teams dabei, KI-Agenten- und RAG-basierte Systeme zu prüfen, bevor sie produktive Abhängigkeiten werden. Dazu kann gehören: vertrauenswürdigen und nicht vertrauenswürdigen Kontext zu trennen, temporäres von dauerhaftem Memory abzugrenzen, Retrieval-Grenzen zu definieren, Zugriffskontrollen zu prüfen, Freigabepunkte zu entwerfen, Audit Trails einzubauen und die umliegende Software zu härten.

Das Ziel ist nicht, KI-Einführung langsam zu machen.

Das Ziel ist, sie vertrauenswürdig genug zu machen, dass sie wirklich tragen kann.

Wenn Ihr Unternehmen Agenten mit Dokumenten, Repositories, Kundendaten oder internen Tools verbindet, lautet die richtige Frage nicht mehr nur: “Antwortet das Modell gut?”

Die bessere Frage lautet:

Was darf dieser Agent sich merken, und warum sollten wir ihm dabei vertrauen?