MCP-Sicherheit & Fehlerbehebung

Sicherheitsmodell des gehosteten MCP

  • Die öffentliche Adresse https://app.confbuild.com/mcp verlangt für Tools ein OAuth-Bearer-Token.
  • Autorisierungscodes verwenden PKCE S256, sind kurzlebig und einmalig nutzbar.
  • Access Tokens laufen nach einer Stunde ab; Refresh Tokens rotieren und laufen nach 30 Tagen ab.
  • Jeder Refresh Token ist genau einmal einlösbar. Wird ein bereits verwendeter Token erneut vorgelegt, gilt das als Diebstahl: die gesamte Tokenkette dieser Freigabe wird sofort widerrufen, und der Client muss die Freigabe neu erteilen.
  • In Firestore werden nur SHA-256-Hashes der ausgegebenen Tokens gespeichert. Abgelaufene Tokens und nicht eingelöste Autorisierungscodes entfernt eine Firestore-TTL automatisch.
  • Die Client-Registrierung ist wie im MCP-Standard offen, aber pro Absenderadresse und Stunde begrenzt. Gespeichert wird davon nur ein SHA-256-Fingerabdruck, nie die Adresse selbst.
  • Die bestätigte Firebase-UID bestimmt den privaten Besitzerpfad. Projektlinks oder Toolargumente können keinen anderen privaten Owner-Pfad auswählen.
  • Der Remote-Backendadapter nutzt Admin SDK nur innerhalb dieses serverseitig festgelegten UID-Pfads. Firestore-/Storage-Regeln schützen zusätzlich den Browser-Renderkanal.
  • Öffentliche oder schreibgeschützte Projekte werden vor einer Änderung privat geklont.
  • Projekt-Commits verwenden Revisionsschutz gegen unbemerkte Parallelüberschreibungen.
  • Der Server ruft keine OpenAI-, Anthropic-, Gemini- oder confBuild-KI-API auf.
  • Für Support und Missbrauchskontrolle speichert confBuild admin-only den exakten an confbuild_start_design_session übergebenen Nutzerauftrag sowie den jeweils neuesten committed Sheet-Stand. Internes KI-Reasoning, Modellnachrichten, Screenshot-Analysen, Screenshots und die Abschlusszusammenfassung werden dort nicht gespeichert.
  • Für Betriebs- und Kapazitätsauswertungen erfasst confBuild außerdem Tool-Aufrufe, Zeitpunkte, Laufzeiten, Erfolg/Fehlercode, Ein-/Ausgabegrößen, Sheet-Mengen, Commits, Projektaktionen und Renderaktivität. Für den sichtbaren Verbindungsstatus speichert der Backend-Kanal zusätzlich OAuth-Clientname, Gültigkeitszeitraum und letzte Aktivität im Bereich des jeweiligen Nutzers. Diese Daten enthalten keine Prompttexte, Zellwerte, Bilddaten, Fehlermeldungen oder Reasoning-Inhalte. Detailereignisse laufen nach 90 Tagen per Firestore TTL ab; Tagesaggregate bleiben erhalten.

OAuth-Freigabe

Geben Sie Zugriff nur frei, wenn die Consent-Seite den erwarteten Client und die Hinweise auf MCP-Historie und technische Usage-Metriken zeigt. Tragen Sie Passwörter oder Firebase-Tokens niemals in MCP-Konfigurationsfelder oder Nutzerprompts ein. Der MCP-Client erhält ein eigenes OAuth-Token, nicht Ihr confBuild-Passwort.

Zum Entziehen des Zugriffs muss derzeit der betreffende OAuth-Client serverseitig deaktiviert werden. Eine sichtbare Benutzerverwaltung für verbundene MCP-Clients und einzelne Token-Revoke-Aktionen ist als Verbesserung vorgesehen.

Welche Tools Projekte schreiben

  • confbuild_create_project
  • confbuild_clone_project
  • confbuild_begin_edit, wenn dabei automatisch geklont wird
  • confbuild_commit_edit
  • confbuild_restore_project_snapshot

confbuild_apply_sheet_patch verändert nur die temporäre Edit-Session. confbuild_discard_edit verwirft diese Arbeitskopie, aber löscht kein gespeichertes Projekt. Commits behalten Pre-Commit-Rollback-Snapshots im eigenen Projektspeicher; sie liegen im privaten Pfad des Eigentümers und werden automatisch aufgeräumt.

Das strukturierte Abschlussergebnis (Abschlusszustand, Iterationszahl, behobene/verbleibende Defektkategorien) wird nur als inhaltsfreie Enums gespeichert; die Freitext-Zusammenfassung, die der Agent dem Nutzer zeigt, wird nie persistiert.

Privater Browser-Renderkanal

Ein Renderjob wird unter mcpRenderJobs/<uid>/jobs/<jobId> angelegt. Nur der angemeldete Eigentümer darf ihn lesen und um erlaubte Capture-Felder ergänzen. Screenshots liegen unter mcp-renders/<uid>/<jobId> und sind nicht öffentlich.

Der gehostete MCP übernimmt keine fremden Tabs. Er akzeptiert eine Aufnahme nur vom passenden, mit derselben UID angemeldeten confBuild-Projekt. Der lokale Entwicklermodus mit CDP ist davon getrennt.

Häufige Fehler

Der Client öffnet keine OAuth-Freigabe

Ursache: Der Client unterstützt keinen Remote MCP/OAuth, verwendet den falschen Transport oder hat alte Metadaten gecacht.

Lösung: Als Server-URL exakt https://app.confbuild.com/mcp und als Transport Streamable HTTP/Remote MCP verwenden. Verbindung im Client entfernen und neu hinzufügen. Kein /oauth und keine Function-URL manuell eintragen.

Anmeldung oder Freigabe schlägt fehl

Ursache: confBuild-Session abgelaufen, falsches Konto, blockierte Weiterleitung oder ungültige OAuth-Anfrage.

Lösung: Zuerst https://app.confbuild.com im Browser öffnen und anmelden, danach die Verbindung erneut im MCP-Client starten. Prüfen, ob Popup-/Weiterleitungsblocker die Rückkehr zum Client verhindern.

invalid_token

Ursache: Access Token ist abgelaufen, widerrufen oder gehört nicht zu diesem MCP.

Lösung: Den Client neu verbinden beziehungsweise OAuth erneut freigeben. Tokens nie zwischen Clients kopieren.

invalid_grant mit Hinweis auf einen bereits verwendeten Refresh Token

Ursache: Derselbe Refresh Token wurde zweimal eingelöst. Das passiert, wenn eine MCP-Konfiguration samt Token kopiert wurde, zwei Instanzen desselben Clients parallel laufen oder ein Token abgeflossen ist. Zum Schutz wurde die komplette Tokenkette dieser Freigabe widerrufen.

Lösung: Die Verbindung im Client entfernen und OAuth einmal neu freigeben. Kopierte Client-Konfigurationen mit enthaltenen Tokens auf allen weiteren Rechnern löschen; jeder Rechner braucht eine eigene Freigabe.

„No accessible confBuild project was found“

Ursache: Falsche ID, nicht unterstützte URL, Projekt nicht öffentlich oder nicht im eigenen Konto.

Lösung: Eine erlaubte /e/, /editor/, /p/ oder /lib/-URL beziehungsweise die korrekte ID verwenden. Private Projekte anderer Nutzer sind nicht per ID auffindbar.

„The project is read-only“

Lösung: confbuild_begin_edit mit cloneReadOnly: true oder vorher confbuild_clone_project verwenden. Das Original bleibt unverändert.

REVISION_CONFLICT

Das Projekt wurde nach Beginn der Edit-Session im Browser oder von einem anderen Agenten gespeichert. Aktuelle Version neu lesen, Änderungen bewusst rebasen, erneut validieren und committen. Es gibt absichtlich keinen Force-Overwrite-Schalter.

„Validation failed“

confbuild_validate_edit auswerten und jeden Eintrag unter errors korrigieren. Warnungen blockieren den Commit nicht automatisch, müssen aber fachlich bewertet werden.

„Commit the dirty edit before rendering“

Der Browser kann nur die gespeicherte Revision laden. Edit validieren und committen oder mit confbuild_discard_edit verwerfen.

Renderjob bleibt running oder läuft ab

  1. Exakt das angeforderte Projekt im Browser öffnen.
  2. Browser und MCP mit demselben confBuild-Konto verwenden.
  3. Auf vollständig geladene 3D-Szene warten.
  4. Tab geöffnet lassen.
  5. Denselben renderJobId weiter pollen, keinen zweiten Job starten. Bevorzugt waitMs nutzen, damit der Server serverseitig wartet.

Solange kein angemeldeter Editor-Tab mit dem Projekt den Job übernommen hat, meldet confbuild_get_render_result ihn nach wenigen Sekunden als unbeansprucht — samt bisheriger Wartezeit. Dieser Hinweis kommt lange vor dem Ablauf; auf ihn reagieren statt das Expiry abzuwarten.

Keine Bilder im Ergebnis

Nach completed confbuild_get_render_result mit includeImages: true und maxImages zwischen 1 und 4 aufrufen. Ist der Job failed, zuerst den dortigen Fehlertext beheben.

Session fehlt oder ist abgelaufen

Remote Design- und Edit-Sessions laufen nach ungefähr sechs Stunden ab; Renderzustände nach spätestens 24 Stunden. Eine neue Session vom zuletzt committeten Projekt starten. Bereits commitete Änderungen bleiben erhalten.

Große Sheets oder fehlende Chunks

Das Manifest nicht manuell umgehen. Projekt aus einer vollständigen Version erneut speichern oder klonen. Das MCP-Sicherheitslimit liegt bei 2.000.000 Zellen und maximal 450 Chunks pro Commit.

Bekannte Grenzen

  • Screenshots benötigen den passenden geöffneten confBuild-Tab.
  • Mehrere Tabs desselben Projekts können denselben Renderjob sehen; ein künftiger Lease-Mechanismus soll genau einen Tab wählen.
  • Die MCP-Historie ist derzeit nur für Administratoren sichtbar; eine Nutzeroberfläche für Export/Löschung, OAuth-Verbindungen und Projekt-Rollback fehlt noch.
  • Strukturelle Validierung ist kein Statik-, Fertigungs-, Bauordnungs-, Kollisions- oder Solver-Nachweis.
  • Der MCP ist direkt an das aktuelle Projekt-/Chunk-Schema gekoppelt.
  • Dynamische Clientregistrierung ist begrenzt, und abgelaufene Tokens, Codes und Zähler räumt eine TTL automatisch ab. Nicht mehr benutzte Client-Registrierungen bleiben dagegen bestehen, und ein Missbrauchsmonitoring fehlt vor sehr breiter Distribution noch.

Sicherheitscheckliste

  • Erwarteten MCP-Client auf der OAuth-Seite prüfen
  • Private Projektlinks nur an berechtigte Personen weitergeben
  • Öffentliche Vorlagen klonen statt Originale zu verändern
  • Revisionskonflikte rebasen, niemals umgehen
  • Finalen Screenshot- und Diagnosebericht prüfen
  • Sicherheits-, Statik-, Norm- und Fertigungsannahmen menschlich freigeben
  • Nicht mehr benötigte MCP-Verbindungen deaktivieren lassen

Weitere Hilfe

Beginnen Sie bei Einrichtungsproblemen mit MCP einrichten. Toolparameter und Patchformate stehen in der MCP-Tool- & Sheet-Referenz.

Zurück zur Dokumentation