mjEdit

Zielgruppen und Anwendungsfälle

Wer profitiert von mjEdit – und wie sieht der typische Workflow aus.

mjEdit ist kein Werkzeug für eine einzige Rolle, sondern eine gemeinsame OSCAL-Arbeitsumgebung für alle Personen, die mit Compliance-Inhalten arbeiten – von der strategischen Steuerung bis zur technischen Umsetzung. Auf dieser Seite zeigen wir pro Rolle: typische Tagesaufgaben, der konkrete Schmerz ohne mjEdit, die Antwort von mjEdit und ein praktisches Beispiel.

Drei KI-Säulen, die durchgängig genutzt werden:

  • 🧠 KI-Agent (Claude Desktop, Cursor, VS Code Copilot oder AnythingLLM) als Sprach-Front-End – die Person diktiert, die KI handelt.
  • 🔌 MCP-Protokoll (88 Tools, 22 Ressourcen, 15 Prompts): die Brücke, mit der die KI mjEdit bedient – Dateien anlegen, JSON ändern, validieren, GUI steuern.
  • 📚 AnythingLLM-RAG: lokale Wissensbasis für ISMS-Dokumente, BSI-Kompendium, Betriebshandbücher – die KI antwortet aus Ihren Unterlagen statt aus Halbwissen.

Pro Rolle ist unten markiert, welche dieser drei Säulen den größten Hebel liefert.

1. Informationssicherheitsbeauftragte (ISB / CISO)

Tägliche Arbeit: ISMS-Dokumentation pflegen, Controls implementieren, Audits vorbereiten, Geschäftsführung berichten, Risiken bewerten.

Schmerzen ohne mjEdit

  • ISMS-Dokumentation in Word/Excel verteilt – jede Änderung muss an 5 Stellen nachgezogen werden.
  • Bei einem neuen System (z. B. Cloud-Migration) wird der SSP komplett neu geschrieben.
  • Vor jedem Audit drei Tage suchen, welche Controls aktuell sind und welche nicht.
  • BSI-Grundschutz-Kompendium als 800-Seiten-PDF; Mapping auf eigene Maßnahmen passiert in Köpfen.

Wie mjEdit hilft

  • Vorinstallierte Kataloge: BSI IT-Grundschutz++ (2.128 Controls), NIST SP 800-53 (468 Controls), C5, BSI 200-x Kompendium 2023 als Ausgangsbasis – kein Abtippen.
  • Profil-Tailoring mit include-controls, add/alter-Modifikationen und Resolved-Profile-Export – die Geltungsbereich-Auswahl ist OSCAL-Standard und nicht eine Excel-Spalte.
  • SSP-Generierung direkt aus dem aufgelösten Profil (oscal_generate_tailored_chain für 1 System, oscal_generate_batch_tailored_chain für n Systeme).
  • Assessment-Planung mit EXAMINE/INTERVIEW/TEST-Methoden pro Control.
  • POA&M-Tracking mit Fristen, Verantwortlichen, Status und Risikobewertung.
  • Mapping-Tab zwischen zwei Frameworks (z. B. C5 ↔ ISO 27001) – Auto-Suggest mit lokaler KI.
  • Markdown-Export für die Geschäftsführung; Cross-Reference-Bericht für Audits.

🧠 Mit KI + MCP + AnythingLLM

  • KI-Agent (z. B. Claude Desktop): „Erstelle für unser neues Cloud-Projekt einen SSP auf Basis von BSI Grundschutz++ und C5.“ – die KI ruft über MCP oscal_generate_tailored_chain auf, das Resolved Profile, den SSP und den AP.
  • AnythingLLM-RAG: Die Beschreibungen der implemented-requirement-Einträge werden aus Ihrem ISMS-Korpus (Sicherheitsleitlinie, Betriebshandbuch, Risikoanalyse) zitatfest gefüllt – jede Aussage trägt eine evidence-source-Property.
  • MCP-Prompts wie oscal_compliance_check_prompt führen Sie strukturiert durch eine Compliance-Prüfung – ohne dass Sie sich Tool-Namen merken müssen.

Beispiel: „Wir migrieren in die Hybrid-Cloud“

Sie sagen zur KI in Claude Desktop: „Klone unseren bestehenden SSP nach ssp-cloud.json, ergänze die Komponenten ,Azure App Service’ und ,Azure SQL’, tailore das Profil um C5-Controls und erzeuge eine Mapping-Collection BSI ↔ C5 inkl. Gap-Analyse.“ Die KI ruft über MCP file_copy, oscal_add_component (2×), oscal_profile_tailoring, oscal_create_mapping, oscal_mapping_auto_suggest und oscal_export_gap_report auf. Aufwand: ein Vormittag statt zwei Wochen.

2. Compliance-Auditoren und Prüfer

Tägliche Arbeit: Kontrollen prüfen, Nachweise sammeln, Findings dokumentieren, Berichte erstellen, Folgegespräche führen.

Schmerzen ohne mjEdit

  • Findings in einer Excel-Tabelle, Evidenzen in einem SharePoint, Maßnahmenplan in Word – nichts ist verknüpft.
  • Bei der nächsten Re-Zertifizierung ist die alte Datenbasis nicht mehr nachvollziehbar.
  • Schema-Konformität (OSCAL, ISO, BSI) nur durch händisches Reviewen prüfbar.

Wie mjEdit hilft

  • Assessment Results direkt im Editor mit Findings, Observations und Risks – alles als verlinktes OSCAL-Objekt.
  • Findings-Verknüpfung: Jedes Finding kennt sein zugehöriges Control, seine Severity und sein Evidence-Artefakt.
  • Schema-Validierung auf drei Ebenen: JSON-Schema, OSCAL-Pydantic-Modell, semantische Cross-Refs (UUIDs).
  • Markdown-Export mit eingebetteten Statements für prüfbare Berichte.
  • Reverse-Lookup: Von einer Komponente zu allen zugehörigen Controls und Inventar-Items navigieren.
  • Diff-Funktion zwischen zwei AR-Versionen für die Re-Zertifizierung.
  • Evidence-Source-Properties belegen jede Aussage mit Dokumenten-Referenz.

🧠 Mit KI + MCP + AnythingLLM

  • KI-Agent: „Finde alle offenen Findings aus dem letzten Audit und priorisiere sie nach Severity.“ – die KI ruft über MCP oscal_query und oscal_search, formatiert das Ergebnis als Tabelle.
  • AnythingLLM-RAG: Die KI vergleicht aktuelle Befunde mit historischen Audit-Berichten in der Wissensbasis und markiert wiederkehrende Schwachstellen.
  • MCP-Tool validate_oscal_document plus validate_oscal_references prüfen Schema und UUID-Konsistenz – die KI repariert Brüche selbstständig auf Nachfrage.

Beispiel: „Re-Audit nach 12 Monaten“

Sie sagen zur KI in Cursor: „Klone den ar-2025.json nach ar-2026.json, finde alle Findings mit Status ‚open’, suche in unserer Wissensbasis nach den aktuellen Maßnahmenständen und aktualisiere Status + Evidence.“ Die KI ruft über MCP file_copy, oscal_query, befragt AnythingLLM zu jedem Finding und schreibt mit oscal_update_implementation_status und oscal_add_property (evidence-source) zurück. Früher: drei Stunden Volltext-Suche.

3. IT-Architekten und Systemadministratoren

Tägliche Arbeit: Systeme dokumentieren, Netzwerk-Topologien pflegen, Inventare aktuell halten, Patch-Management, Härtungen.

Schmerzen ohne mjEdit

  • IP-Listen in Excel, Hostnames im DNS, MAC-Adressen im DHCP – nichts korreliert mit der Compliance-Doku.
  • Bei jedem neuen Server: 5 Excel-Sheets aktualisieren und auf Konsistenz prüfen.
  • Netzwerkpläne als Visio-Datei, der niemand mehr traut.

Wie mjEdit hilft

  • Inventory-Items im SSP mit hostname, fqdn, ipv4/ipv6, mac-address als OSCAL-konforme Properties.
  • Komponenten-Bibliothek: Software, Hardware, Services als wiederverwendbare Bausteine (component-definition).
  • CSV-Import/Export für Anbindung an Asset-Management-Systeme (CMDB, Active Directory, Cloud-APIs).
  • NWDiag-Generierung automatisch aus Inventar-Daten – das Diagramm ist die Doku, nicht ein Bild daneben.
  • Reverse-Lookup: Welche Controls greifen auf diese Komponente? Welche Maßnahmen sind betroffen, wenn ich diesen Server abschalte?
  • Batch-Updates über editor_replace und oscal_update_metadata für Patch-Stände.

🧠 Mit KI + MCP + AnythingLLM

  • KI-Agent: „Hier ist eine CSV mit 8 neuen Webservern – erzeuge die komplette OSCAL-Dokumentkette pro Server.“
  • MCP-Tool oscal_generate_batch_tailored_chain macht aus einem Satz 48 schema-validierte Dokumente.
  • AnythingLLM-RAG: Härtungsleitlinien, Patch-Management-Richtlinien und Netzwerk-Segmentierungs-Konzepte aus der Wissensbasis fließen in die description-Felder pro Komponente ein – mit Quellenangabe.
  • MCP-GUI-Tools wie gui_show_tab zeigen das fertige NWDiag sofort im SSP-Tab.

Beispiel: „Server-Roll-out für 8 neue Webserver“

Sie diktieren der KI: „Hier die CSV mit system_id, hostname, IP, OS. Erzeuge die Dokumentkette pro Server, beziehe die Härtungsmaßnahmen aus unserer Wissensbasis ,Linux-Härtung 2025’.“ Die KI ruft über MCP oscal_generate_batch_tailored_chain, holt sich pro Control die Begründungen aus AnythingLLM und legt 48 validierte OSCAL-Dokumente an (8 Server × 6 Dokumente: Profil → Component-Definition → SSP → AP → AR → POA&M).

4. DevSecOps-Teams und KI-Entwickler

Tägliche Arbeit: Security-as-Code, automatisierte Compliance-Pipelines, KI-Workflows mit Claude/Cursor/Copilot, RAG-Integrationen.

Schmerzen ohne mjEdit

  • Compliance-Dokumente sind kein Code – sie können nicht im CI/CD validiert werden.
  • KI-Assistenten dürfen kein Editor-Werkzeug benutzen, sondern nur Texte vorschlagen.
  • ISMS-Wissen liegt verteilt in Dokumenten, ohne KI-zugängliche Schnittstelle.

Wie mjEdit hilft

  • 88 MCP-Tools für programmatische OSCAL-Steuerung – Datei-, JSON-, OSCAL-, qFORM-, Markdown-, Editor- und GUI-Operationen.
  • execute_steps: bis zu 20 Tool-Aufrufe in einem einzigen Request, inkl. transaktionaler Rollback-Möglichkeit.
  • 22 MCP-Ressourcen und 15 MCP-Prompts für geführte Workflows.
  • Direkte Integration in Claude Desktop (STDIO), Cursor, VS Code Copilot, AnythingLLM (SSE/HTTP).
  • AnythingLLM-RAG: lokale Wissensbasis für ISMS-Dokumente; KI ruft mjEdit-Tools auf Basis dieser Dokumente auf.
  • Pydantic-Validierung für OSCAL-Modelle in CI/CD-Pipelines (pytest-fähig).
  • JSON-Schema-Export für eigene Validierungswerkzeuge.

🧠 Mit KI + MCP + AnythingLLM

Für DevSecOps ist mjEdit die KI-Schaltzentrale schlechthin:

  • MCP ist die programmatische Schnittstelle – jeder KI-Agent (Claude, Cursor, Copilot, AnythingLLM) wird zum vollwertigen Co-Editor für OSCAL.
  • execute_steps bündelt bis zu 20 Tool-Aufrufe transaktional in einem Request.
  • AnythingLLM liefert Compliance-Wissen aus Ihren eigenen Repositories über SSE/HTTP – ideal für CI/CD-Server ohne Desktop.
  • MCP-Prüftools lassen sich headless in Pipelines einbinden (validate_oscal_document, validate_oscal_references).

Beispiel: „GitLab-Pipeline mit OSCAL-Validierung + KI-Review“

Ein Pipeline-Schritt startet mjEdit headless als MCP-Server, eine zweite Job-Stufe verbindet sich mit einem KI-Agent (z. B. AnythingLLM SSE), die KI ruft über MCP validate_oscal_document über alle *.json und oscal_diff zwischen Feature-Branch und main. Findet sie Schema-Brüche, posten sie als Pull-Request-Kommentar mit konkreten Korrekturvorschlägen – belegt aus der AnythingLLM-Wissensbasis.

5. Datenschutzbeauftragte (DSB) und Datenschutz-Koordinator/innen

Tägliche Arbeit: Verarbeitungsverzeichnis pflegen, TOMs dokumentieren, DSFAs durchführen, Auskunftsersuchen bearbeiten.

Schmerzen ohne mjEdit

  • Verarbeitungsverzeichnis in Excel, TOMs in Word, DSFAs als PDF – keine maschinenlesbare Verbindung.
  • Cloud-Dienste in den USA: Datenflüsse manuell auflisten und bewerten.
  • Audit der Aufsichtsbehörde: Tagelange Vorbereitung.

Wie mjEdit hilft

  • Data-Sovereignty by Design: mjEdit + AnythingLLM laufen lokal/on-premise – kein Datenabfluss zu Cloud-KIs.
  • Kein API-Key, kein Token verlässt den Rechner – das KI-Embedding-Modell läuft lokal.
  • OSCAL Component-Definitions für Auftragsverarbeiter mit Implementierungs-Nachweisen.
  • Mapping zwischen DSGVO-Anforderungen und technisch-organisatorischen Maßnahmen (TOMs).
  • Markdown-Export für die Aufsichtsbehörde mit Quellenangaben.

🧠 Mit KI + MCP + AnythingLLM – datenschutzfreundlich

  • AnythingLLM läuft on-premise – ihre AVV-Verträge, DSFAs und TOM-Dokumente bleiben im Haus.
  • Embedding-Modell (paraphrase-multilingual-MiniLM-L12-v2) läuft lokal – kein Token verlässt den Rechner, kein API-Key für Drittanbieter.
  • KI-Agent + MCP: „Extrahiere aus dem AVV mit Anbieter X die TOMs nach DSGVO Art. 32 und mappe sie auf BSI-Grundschutz-Maßnahmen.“

Beispiel: „DSFA für ein neues HR-System“

Sie diktieren der KI: „Erstelle einen Component-Definition-Stub für unser neues HR-Tool, extrahiere die TOMs aus dem AVV-Dokument in unserer Wissensbasis und mappe sie auf BSI-Grundschutz Art. 32-relevante Praktiken.“ Die KI nutzt AnythingLLM zum Extrahieren der Vertragsklauseln und ruft über MCP oscal_create_component_definition, oscal_add_property (evidence-source) und oscal_create_mapping auf. Ergebnis: ein auditfester Verarbeitungs-SSP mit Quellenangabe je Aussage – vollständig on-premise erstellt.

6. Auftragnehmer für BSI-/KRITIS-Behörden

Tägliche Arbeit: Compliance-Nachweise für deutsche Behörden, BSI IT-Grundschutz-Zertifizierung, KRITIS-Prüfungen, On-Premise-Anforderungen.

Schmerzen ohne mjEdit

  • US-Cloud-Tools sind aus rechtlichen Gründen nicht einsetzbar.
  • BSI-Kompendium nur als PDF; Maschinenverarbeitung manuell aufgebaut.
  • Mehrsprachige Audits (DE/EN) erfordern doppelte Pflege.

Wie mjEdit hilft

  • 100% On-Premise: Editor + KI-Modell + RAG ohne Cloud-Bindung – BSI-Mindeststandard-tauglich.
  • AGPL-3.0: Quelloffen und auditierbar.
  • Mehrsprachiges Embedding-Modell (DE/EN/FR/IT) für sprachübergreifendes Mapping zwischen BSI (DE) und ISO 27001 (EN).
  • BSI-IT-Grundschutz++ Katalog vorinstalliert (2.128 Controls).
  • Markdown-/PDF-Export mit deutschsprachigen Vorlagen.

🧠 Mit KI + MCP + AnythingLLM – ohne Cloud-Zwang

  • Komplett luftspaltfähig: mjEdit + AnythingLLM + lokales LLM (z. B. Ollama, LM Studio) – kein einziges Byte verlässt die Behordeninfrastruktur.
  • MCP als offenes Protokoll: kein Vendor-Lock-in, jede KI tauschbar.
  • AnythingLLM-RAG mit dem BSI-Grundschutz-Kompendium als Wissensbasis: die KI antwortet zitatgenau aus dem offiziellen BSI-Material.
  • KI-Agent über MCP: „Befrage das Kompendium zu den Pflicht-Anforderungen für Schutzbedarf ,hoch’ und ergänze sie im aktuellen SSP.“

Beispiel: „IT-Grundschutz-Zertifikatsaudit“

Sie diktieren in einem luftspaltgeschützten Netz: „Mappe unsere Sicherheitskonzepte gegen Grundschutz++-Praktiken, erkläre jedes Mapping mit Quellen aus dem Kompendium und exportiere ein Markdown-Audit-Bundle.“ Die lokale KI nutzt über MCP den Mapping-Editor mit Auto-Suggest, AnythingLLM liefert zitatfeste BSI-Quellen, MCP markdown_export_to_pdf erstellt das Bundle. Selbst hochsensible Geheimschutzinhalte sind ohne Datenabflussrisiko bearbeitbar.

7. Ausbildende, Studierende und Forschende

Tägliche Arbeit: OSCAL als Standard kennenlernen, Lehrmaterial erstellen, Forschungsprototypen mit Compliance-Bezug bauen.

Schmerzen ohne mjEdit

  • OSCAL-Spezifikation ist abstrakt; Beispiele in der freien Wildbahn rar.
  • Studentische Arbeiten an Compliance-Themen scheitern an fehlenden Werkzeugen.

Wie mjEdit hilft

  • 8 OSCAL-Dokumenttypen in einem Werkzeug – die ganze Spezifikation greifbar.
  • Vorinstallierte Beispiel-Projekte zum Erkunden.
  • AGPL-3.0: kostenfrei nutzbar in Lehre und Forschung.
  • Pydantic-Modelle als Lerngrundlage für OSCAL-Datenmodellierung.
  • Plugin-Architektur: eigene Forschungs-Tools als mjEdit-Plugin andocken.

🧠 Mit KI + MCP + AnythingLLM – als Lehrobjekt

  • MCP-Protokoll als realer Anwendungsfall für Vorlesungen über AI-Agents und Tool-Use.
  • AnythingLLM-RAG als Beispiel für lokale Wissensbasen – ohne Cloud-Vendor.
  • 88 MCP-Tools quelloffen einsehbar – ideale Studiengrundlage für Forschungsarbeiten zu KI-gestützter Compliance.

Beispiel: „Bachelorarbeit zu OSCAL-zu-ISO-Mapping“

Eine Studierende verbindet AnythingLLM mit dem mjEdit-MCP-Server und lässt die KI über oscal_mapping_auto_suggest Vorschläge zwischen NIST SP 800-53 und ISO 27001 erzeugen. In der Auswertung vergleicht sie die drei Methoden syntactic, semantic und functional quantitativ. Datengrundlage: vorinstallierte Kataloge; Werkzeug: mjEdit + MCP + lokale KI; Auswertung: Markdown-Export → LaTeX.

Tabellenüberblick: Welche Funktionen für welche Rolle?

Funktion / Feature ISB/CISO Auditor IT-Architekt DevSecOps DSB KRITIS Lehre
Vorinstallierte Kataloge (BSI/NIST/C5) ✓ ✓ ✓ ✓ ✓
Profil-Tailoring + Resolution ✓ ✓ ✓ ✓ ✓ ✓
SSP-Generierung (Single/Batch) ✓ ✓ ✓ ✓
Assessment Plan / Results / POA&M ✓ ✓ ✓ ✓
Mapping-Tab mit lokaler KI ✓ ✓ ✓ ✓ ✓ ✓
Inventar (Hostname/IP/MAC) ✓ ✓ ✓ ✓
Component-Definition-Bibliothek ✓ ✓ ✓ ✓ ✓
88 MCP-Tools + AnythingLLM-RAG ✓ ✓ ✓ ✓ ✓
Schema-Validierung 3-stufig ✓ ✓ ✓ ✓ ✓ ✓
Markdown-/PDF-Export ✓ ✓ ✓ ✓ ✓ ✓ ✓
Pydantic-API für CI/CD ✓ ✓
100% on-premise / kein Cloud-Zwang ✓ ✓ ✓ ✓ ✓ ✓ ✓

Sie sind sich unsicher, ob mjEdit zu Ihrer Rolle passt?

Schreiben Sie uns über das Kontaktformular – wir zeigen Ihnen in einer kurzen Demo, wie mjEdit Ihren konkreten Workflow trifft.