Sichere Aktionen in Chat, MCP und Windows-Integration

Web-Chat und MCP verwenden denselben Capability-Katalog und dieselben versionierten Fachservices. Dadurch gelten für Lesen und Schreiben dieselben Projekt-, Rollen-, Objekt- und Versionsprüfungen. Unterstützte Aktionen decken unter anderem Testbibliothek, Anforderungen, Planung, Durchführung, Ergebnisse, Reviews, Beziehungen, Defekte, Anhänge, Release-/Änderungswissen, Administration und Word-Import/-Export ab.

Eine KI-Antwort oder MCP-Vorschau ändert noch keine Projektdaten. Schreibaktionen werden ausdrücklich vorbereitet, geprüft, bestätigt und auditiert.

Vorbereiten, prüfen, bestätigen

1. Prepare: Chat oder MCP erstellt aus der gewünschten Fachaktion eine konkrete, berechtigungsgeprüfte Vorbereitung.
2. Preview: Prüfen Sie Zielobjekt, Änderung, Auswirkungen, Warnungen und gegebenenfalls die erwartete Objektversion.
3. Commit: Bestätigen Sie nur eine unveränderte und verstandene Vorschau. Bei Konflikten oder abgelaufener Vorschau beginnen Sie neu.
4. Audit: Prüfen Sie Ergebnis, Deep-Link und Auditspur. Wiederholte technische Aufrufe dürfen durch Idempotenz nicht unbemerkt dieselbe Änderung doppelt ausführen.

Fehlende Berechtigung, veraltete Version, unbekannte Capability oder ungültige Argumente führen zu einem geschlossenen Fehler statt zu einer teilweisen Änderung.

MCP sicher einrichten

MCP verwendet JSON-RPC 2.0 über POST /mcp. Persönliche projektbezogene API-Schlüssel arbeiten mit den Rollen und Berechtigungen des zugehörigen aktiven Projektbenutzers. Globale administrative Schlüssel sind getrennt; Projektzugriff für einen globalen Schlüssel muss ausdrücklich erlaubt werden.

• Erstellen Sie Schlüssel in der vorgesehenen MCP-API-Schlüsselverwaltung und kopieren Sie das Geheimnis sofort; es wird später nicht erneut angezeigt.
• Vergeben Sie kurze Laufzeiten, minimale Scopes und einen eindeutigen Zweck.
• Übergeben Sie ein Projekt über dessen eindeutige ID oder den freigegebenen Projektpfad und verlassen Sie sich nicht auf einen globalen Standardkontext.
• Nutzen Sie Werkzeugkatalog und Capability-Explorer, bevor Sie eine Aktion automatisieren.
• Widerrufen Sie nicht mehr benötigte oder möglicherweise offengelegte Schlüssel sofort.

Local Bridge und kontrollierte lokale Aktionen

Die Zeta Test Local Bridge verbindet freigegebene Web-Abläufe mit kontrollierten lokalen Windows-Funktionen. Der Webserver startet keine beliebigen lokalen Prozesse. Chrome oder Edge sprechen über die Browsererweiterung mit einem installierten Native-Messaging-Host; eine maschinenweite Richtlinie erlaubt nur benannte, typisierte Aktionen.

1. Ein Administrator stellt Native Host und Browsererweiterung bereit und verbindet ausschließlich die vorgesehene ZTM-Website.
2. Die Kunden-IT hinterlegt freigegebene Prozessaktionen in der Local-Bridge-Richtlinie. Freie Kommandozeilen und älteres Lua bleiben im Web gesperrt.
3. Externe Werkzeuge verwenden eine strukturierte Referenz wie ztm-local-bridge:action-id. Nur eine vorhandene und erlaubte Aktion kann ausgeführt werden.
4. Prüfen Sie in der Administration Status, Version, Prüfsumme, Endpunkte und die vorgeschlagenen Chrome-/Edge-Richtlinienwerte.

Behandeln Sie Browsererweiterung, Native Host, Website-Zuordnung und lokale Richtlinie als gemeinsame Sicherheitsgrenze. Eine verbundene Bridge ersetzt keine Projekt- oder Objektberechtigung.