Zum Inhalt springen
S&L Labs

Go-live-Review

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

Bevor Ihr System live geht oder mehr Rechte bekommt, prüfe ich Architektur und Code und teste das System gezielt gegen eine Staging-Umgebung. Sie erhalten priorisierte Befunde und eine Zielarchitektur, die Ihr Team umsetzen kann.

Umfang
Ein Agenten-, RAG- oder MCP-System mit seinen Tools, Datenquellen und Freigaben. Den genauen Zuschnitt legen wir im Vorgespräch schriftlich fest.
Aufwand
5 bis 8 Tage zum Festpreis. Das Angebot erhalten Sie nach dem Vorgespräch.
Ergebnis
Ein Bericht mit priorisierten Befunden, Umbauvorschlägen und einer Zielarchitektur, dazu eine Abschluss-Session mit Ihrem Team.

Stacks, die ich prüfe

Modelle und Plattformen
  • Claude
  • OpenAI
  • Azure OpenAI
  • Amazon Bedrock
  • Mistral
  • Langdock
Frameworks und Protokolle
  • LangGraph
  • LlamaIndex
  • Vercel AI SDK
  • MCP
Agenten-Plattformen
  • Copilot Studio
  • n8n
Vektorspeicher
  • Qdrant
  • pgvector
App-Builder
  • Lovable
  • Bolt
  • v0
  • Cursor

Produktnamen dienen der Beschreibung, keine Partnerschaft.

Ablauf

Sechs Phasen, eine davon optional

  1. Vorgespräch und Scope

    Wir klären, um welches System es geht, was der Anlass ist und wie weit es gebaut ist. Im Angebot stehen danach Umfang, Testrahmen und Termine schriftlich fest.

  2. Lesen

    Ich lese Architektur, Code, Tool-Definitionen, Prompts und Konfiguration. Daraus entstehen das Threat Model und die Rechteübersicht pro Tool.

  3. Gespräche mit dem Team

    In zwei bis drei Sessions gehe ich mit den Engineers, die das System gebaut haben, Datenflüsse, Rechte und Freigaben durch. Dort klären sich Fragen, die der Code allein nicht beantwortet.

  4. Gezielte Tests gegen Staging

    Ich greife das System dort an, wo Agenten typischerweise verwundbar sind, mit Prompt Injection, Tool-Missbrauch und Versuchen, Daten abfließen zu lassen. Weil Sprachmodelle nicht immer gleich antworten, führe ich jeden Test mehrfach aus und halte fest, wie sich ein Befund reproduzieren lässt. Getestet wird nur in Staging und nur im schriftlich freigegebenen Rahmen.

  5. Bericht und Zielarchitektur

    Sie erhalten die Befunde nach Auswirkung sortiert, jeweils mit Zuordnung zu OWASP Agentic und einem konkreten Umbauvorschlag. In einer Abschluss-Session beantworte ich die Fragen Ihres Teams.

  6. Nachprüfungoptional

    Auf Wunsch prüfe ich die Umsetzung nach einigen Wochen noch einmal und wiederhole dabei die Tests, die zu Befunden geführt haben.

Wo ich prüfe

  1. Person
  2. Prüfpunkt: Identität
  3. Agent
  4. Fremde Inhalte Dokumente, Webseiten, Mails, fließen in den Agenten ein
  5. Prüfpunkt: Rechte pro Tool
  6. Tools und MCP-Server
  7. Prüfpunkt: Freigabe mit Diff und Protokoll
  8. Daten und Systeme
  • Vertrauensgrenze
  • Prüfpunkt im Review

Voraussetzungen

Was Sie bereitstellen

  • Lesender Zugriff auf die Repositories des Systems
  • Eine Staging-Umgebung mit Testaccounts, deren Rollen denen im Produktivbetrieb entsprechen
  • Eine schriftliche Testfreigabe, die Scope, Zeitraum und ausgenommene Systeme festlegt
  • Eine Ansprechperson im Team, die Fragen zu Architektur und Betrieb beantwortet

Produktionsdaten brauche ich nicht. Zugänge gelten nur für die Dauer des Reviews.

Methodik

Woran sich das Review orientiert

Einordnung

Go-live-Review und klassischer Pentest

Beide Prüfungen ergänzen sich. Wenn Ihr System zusätzlich einen Penetrationstest braucht, beschreibe ich im Bericht den Scope, den ein Testhaus prüfen sollte.

Merkmal Go-live-Review Klassischer Pentest
Blickwinkel Von innen. Architektur, Code, Rechte und Datenflüsse, ergänzt um gezielte Angriffe auf die Schwachstellen, die für Agenten typisch sind. Überwiegend von außen. Angriffe auf Anwendung, Schnittstellen und Infrastruktur.
Ergebnis Priorisierte Befunde mit Umbauvorschlägen und eine Zielarchitektur, die Ihr Team umsetzen kann. Gefundene Schwachstellen mit Nachweis und Bewertung, meist mit Empfehlungen zur Behebung.
Umfang Ein Agenten-, RAG- oder MCP-System mit seinen Tools, Datenquellen und Freigaben. Netzwerk, Server, Webanwendungen und Schnittstellen nach vereinbartem Scope.
Wer Ein Software-Architekt, der solche Systeme selbst baut und betreibt. Ein spezialisiertes Testhaus mit eigenem Team.

Beispielbericht

Auszug aus einem Bericht

Der Auszug zeigt Aufbau und Detailtiefe der Befunde. System, Befunde und Testergebnisse sind erfunden.

Fiktives Beispiel System: Support-Agent mit CRM- und Mail-Tool
  1. B-01 Schwere: Hoch ASI03 Identity and Privilege Abuse

    Das CRM-Tool läuft mit einem Service-Account.

    Beschreibung
    Das Tool crm_suche fragt das CRM mit einer technischen Kennung ab, die alle Kundendatensätze lesen darf. Die Rechte der Supportkraft, die den Agenten nutzt, spielen bei der Abfrage keine Rolle.
    Auswirkung
    Über den Agenten lassen sich Datensätze anderer Teams abrufen, die die Supportkraft im CRM selbst nicht sehen dürfte.
    Umbauvorschlag
    Das Tool ruft das CRM mit der Identität der anfragenden Person auf, und das CRM prüft die Rechte. Ein Isolationstest pro Rolle sichert das ab.
  2. B-02 Schwere: Hoch ASI01 Agent Goal Hijack

    Eingehende Mails, CRM-Daten und Versand liegen im selben Kontext.

    Beschreibung
    Der Agent liest eingehende Kundenmails, hat Zugriff auf CRM-Daten und darf mit mail_senden an beliebige Adressen schreiben. Im Test brachte eine präparierte Mail den Agenten in 3 von 10 Durchläufen dazu, Kundendaten an eine fremde Adresse zu senden.
    Auswirkung
    Ein Absender von außen kann Daten aus dem CRM abfließen lassen, ohne Zugang zum System zu haben.
    Umbauvorschlag
    Der Server lässt als Empfänger nur die Adresse des Tickets zu. Versand an andere Adressen läuft über eine Freigabe, die Empfänger und Text in Klartext zeigt.
  3. B-03 Schwere: Mittel ASI09 Human-Agent Trust Exploitation

    Die Freigabe zeigt die Begründung des Modells statt der Mail.

    Beschreibung
    Vor dem Versand zeigt der Dialog die Begründung des Agenten und eine Schaltfläche zum Senden. Empfänger und vollständiger Text sind erst nach einem weiteren Klick sichtbar.
    Auswirkung
    Die freigebende Person bestätigt Mails, deren Empfänger und Inhalt sie nicht gesehen hat. Eine manipulierte Begründung macht die Freigabe wahrscheinlicher.
    Umbauvorschlag
    Der Dialog zeigt Empfänger, Betreff und Text in Klartext und hebt Abweichungen von der Ticketadresse hervor. Die Begründung des Modells entfällt.

Kontakt

Go-live-Review anfragen

Im Erstgespräch klären wir, ob ein Review zu Ihrem System passt und welcher Umfang sinnvoll ist. Danach erhalten Sie ein Festpreisangebot.

Erstgespräch buchen 30 Minuten, technisches Erstgespräch, kein Pitch info@slworks.de