Zum Inhalt springen
S&L Labs

S&L Labs · by Simon Liedtke

Agenten mit klaren Grenzen in Produktion bringen.

Ich prüfe die Architektur von Agenten-, RAG- und MCP-Systemen und entwerfe den Umbau. Solche Systeme baue und betreibe ich selbst.

Go-live-Review anfragen So läuft ein Review

KertosZuletzt: Agenten-Plattform bei Kertos gebaut und zu zahlenden Kunden gebracht.

Ausgangslage

Weil Prompt Injection nicht gelöst ist, gehören die Grenzen in die Architektur.

Ein Sprachmodell trennt Anweisungen und Daten nicht zuverlässig. Das BSI hält fest, dass keine Gegenmaßnahme das Problem vollständig beseitigt. Bei einem System, das Werkzeuge aufruft, Dokumente liest und Daten ändert, kommt es deshalb darauf an, was ein erfolgreicher Angriff erreichen kann.

An diesen drei Stellen haben solche Systeme typischerweise Lücken:

Rechte.
Tools laufen mit den Rechten eines Service-Accounts statt mit denen der fragenden Person. Der Agent sieht dann mehr, als die Person sehen dürfte.
Lethal Trifecta.
Private Daten, fremde Inhalte und ein Weg nach außen liegen im selben Kontext. Dann kann ein präpariertes Dokument genügen, um Daten abfließen zu lassen.
Schreibzugriffe.
Ein Agent mit Schreibrechten braucht eine Freigabe, die die Änderung vorher zeigt, und ein Protokoll, das sich nicht unbemerkt manipulieren lässt.

Leistungen

Angebote

Festpreis, 5 bis 8 Tage

Go-live-Review für Agenten, RAG und MCP

Ablauf, Methodik und Beispielbericht

Bevor Ihr System live geht oder mehr Rechte bekommt, prüfe ich Architektur und Code auf die Risiken der OWASP Top 10 for Agentic Applications 2026. Sie erhalten:

  • Threat Model für Ihr System, gemappt auf OWASP Agentic
  • Rechteübersicht pro Tool: welches Werkzeug welche Daten mit welcher Identität erreicht
  • Analyse der Lethal Trifecta: wo private Daten, fremde Inhalte und Außenkommunikation im selben Kontext zusammentreffen
  • Freigabepunkte: wo der Agent auf eine Person warten muss und was die Freigabe ihr zeigen sollte
  • Datenfluss zum LLM-Anbieter: welche Daten Ihr Unternehmen verlassen, wohin sie gehen und wo sie sich maskieren lassen
  • Gezielte Angriffstests gegen Staging: Prompt Injection, Tool-Missbrauch und Datenabfluss, mehrfach ausgeführt, mit reproduzierbaren Befunden
  • Bericht mit priorisierten Befunden und einer Zielarchitektur, die Ihr Team umsetzen kann

1 bis 2 Tage, mit Ihrem Engineering-Team

Threat-Modeling-Workshop

Wir modellieren gemeinsam ein konkretes System, vom Eingang fremder Inhalte bis zum letzten Tool-Aufruf. Sie erhalten ein Threat Model, das Ihr Team weiterpflegt, und eine Liste der Stellen, die genauer geprüft werden sollten. Das Format passt, wenn das System noch im Bau ist.

Entwurf und Bau, Umfang nach Absprache

Agent-Trust-Architektur

Ich entwerfe und baue die Schicht, die Agenten im Betrieb begrenzt, allein oder zusammen mit Ihrem Team:

  • Berechtigungen bis auf Dokumentebene, auch im Retrieval
  • Mandantentrennung mit Isolationstests
  • Schreibfreigaben mit Klartext-Diff und revisionssicherem Protokoll
  • Maskierung personenbezogener Daten vor dem Modell und in Testdaten
  • OAuth 2.1 für MCP-Server und externe Clients

Vorgehen

So läuft ein Go-live-Review

  1. Vorgespräch

    Wir klären, um welches System es geht, was der Anlass ist und wie weit es gebaut ist. Danach erhalten Sie ein Festpreisangebot mit definiertem Umfang und schriftlich vereinbartem Testrahmen.

  2. Lesen

    Ich lese Architektur, Code, Tool-Definitionen, Prompts und Konfiguration. Dafür genügt lesender Zugriff auf das Repository.

  3. Gespräche

    Ich führe zwei bis drei Sessions mit den Engineers, die das System gebaut haben. Dort klären sich Fragen, die der Code allein nicht beantwortet.

  4. Testen

    Ich greife das System in einer Staging-Umgebung gezielt an, mit Prompt Injection, Tool-Missbrauch und Versuchen, Daten abfließen zu lassen. Staging-Zugang und Testaccounts stellen Sie bereit. Produktionsdaten brauche ich nicht.

  5. Bericht und Zielarchitektur

    Sie erhalten die Befunde nach Auswirkung sortiert, zu jedem Befund einen konkreten Umbauvorschlag. In einer Abschluss-Session beantworte ich die Fragen Ihres Teams.

Praxis

Aus eigenen Produktivsystemen

Die Muster, die ich prüfe, habe ich selbst gebaut und betrieben, zum Beispiel bei Kertos, einer Compliance-SaaS mit 26 Mandanten-Anwendungen:

RAG
Mandantengetrennte RAG-Pipeline.
Jeder Mandant hat einen eigenen Wissensindex, der in Echtzeit synchronisiert wird. Das Abfrage-Tool des Agenten sucht nur im Index des eigenen Mandanten.
PII
PII-Maskierung über 26 Mandanten-Anwendungen.
Maskierte Daten laufen über eine eigene Export- und Importstrecke mit Leak-Absicherung und Monitoring.
MCP-Auth
OAuth 2.1 für MCP.
Umgesetzt sind Authorization-Code- und Device-Flow, Discovery nach RFC 8414 und RFC 9728 sowie die Freigabe externer Clients pro Organisation.
Freigabe
Deklarierte Schreiboperationen.
Jeder Schreibzugriff des Agenten läuft über eine deklarierte Operation mit serverseitiger Statusprüfung. Die freigebende Person sieht ein Klartext-Diff und gibt einzeln oder gesammelt frei. Jeder Vorgang landet in einem revisionssicheren Protokoll mit Korrelations-ID.
Fail-closed
Fail-closed-Freigaben.
Was nicht ausdrücklich erlaubt ist, bleibt gesperrt, auch wenn ein Teil der Prüfung ausfällt.
Rechte
Berechtigungshärtung über 18 Module.
Die Zugriffsrechte sind objektbasiert und durch deterministische Isolationstests abgesichert.

Diese Bausteine sind in mehreren Produktivsystemen umgesetzt.

„Simon hat die Architektur rund um unseren Compliance-Agenten KAIA entworfen und ihn bis zu zahlenden Kunden gebracht. Er hat maßgeblich Evals etabliert und die Qualität unserer KI messbar gemacht. Simon übernimmt weitreichende Verantwortung, nimmt das Team mit und sorgt für höchste Sicherheit und Verlässlichkeit, selbst bei den komplexesten Aufgaben.“
Alexander Prams, CTO & Co-Founder, Kertos

Abgrenzung

Umfang und Grenzen

Ich prüfe, wie Ihr System innen gebaut ist, teste es gezielt an den Stellen, an denen Agenten verwundbar sind, und entwerfe den Umbau. Ein Penetrationstest prüft dagegen Anwendung und Infrastruktur in der Breite, eine Compliance-Prüfung, ob Nachweise vorliegen. Filterplattformen prüfen Eingaben.

Gilt für jeden Auftrag
  • Gezielte Tests statt Testfabrik. Im Review greife ich Ihr System dort an, wo Agenten typischerweise verwundbar sind: Prompt Injection, Tool-Missbrauch, Datenabfluss. Das geschieht gegen eine Staging-Umgebung und im vorher schriftlich vereinbarten Rahmen. Einen klassischen Penetrationstest Ihrer Infrastruktur ersetzt das nicht. Wenn Sie einen brauchen, beschreibe ich den Scope, den ein Testhaus prüfen sollte.
  • Keine Rechtsberatung. Ob NIS2 oder der AI Act für Sie gilt, klären Ihre Jurist:innen. Was daraus technisch folgt, gehört zu meiner Arbeit.
  • Keine Zertifizierung. Der Bericht ist eine fachliche Einschätzung, kein Prüfsiegel.
Simon Liedtke

Über mich

Simon Liedtke

Ich bin Software-Architekt aus München und baue seit fast 20 Jahren Software, seit 2025 vor allem Agenten-Systeme, MCP-Server und RAG-Pipelines für den produktiven Einsatz. Dazu gehören Evals, LLM-Observability und die Rechte- und Freigabeschicht, um die es auf dieser Seite geht. Ich arbeite allein und eigenverantwortlich, jeder Auftrag ist klar abgegrenzt.

Mehr zu meiner übrigen Arbeit: slworks.de

Projekte, an denen ich gearbeitet habe

  • Kertos
  • Allianz SE
  • Vitolus Services
  • Hasso-Plattner-Institut

Kontakt

Go-live-Review anfragen

Buchen Sie ein Erstgespräch oder schreiben Sie mir, welches System Sie live bringen wollen und bis wann. Auf E-Mails antworte ich innerhalb von zwei Werktagen.

Erstgespräch buchen 30 Minuten, technisches Erstgespräch, kein Pitch

Oder per E-Mail an info@slworks.de

Der Buchungslink führt zu Cal.com. Impressum · Datenschutz