Trust Score
LightNow fasst die verfügbare Trust-Evidenz für einen bewerteten MCP-Server als Score von 0 bis 100, als Level und als Gruppe von Evidenz-Layern zusammen. Nutze das Ergebnis zur Steuerung eines Reviews, nicht als automatische Freigabe oder Garantie für sicheres Verhalten.
Ergebnis in der richtigen Reihenfolge lesen
excellent, high, medium, low, unverified und unknown steuern den
weiteren Review.
Ein failed_critical-Layer überschreibt das Aggregat und erzwingt ein
unverified-Ergebnis.
Ermittle, ob das schwache Signal Identität, Ownership, Endpoint, Source, Reputation oder Vulnerabilities betrifft.
Alte Evidenz und ein Workflow mit großer Auswirkung brauchen mehr Review als ein kurzlebiges persönliches Experiment.
Leite das Level in einer clientseitigen Policy nicht selbst aus dem Zahlenwert ab. Verwende das von LightNow zurückgegebene Level. So bleibt Automation konsistent, wenn sich Bewertungsvertrag oder Schwellenwerte weiterentwickeln.
Evidenz-Layer
| Layer | Welche Frage er beantworten hilft |
|---|---|
| Publisher Identity | Ist die Publisher-Identität konsistent und zuordenbar? |
| Domain Verification | Kontrolliert der Owner die beanspruchte Domain, sofern dieser Proof anwendbar ist? |
| Repository Verification | Kontrolliert der Owner das referenzierte Source-Repository? |
| Endpoint Security | Besitzt der Remote-Endpoint eine akzeptable TLS- und URL-Posture? |
| Source Code | Welche Source-, Lizenz- und Provenance-Evidenz ist verfügbar? |
| Reputation | Welche Reife- und Aktivitätssignale sind für das Upstream-Projekt sichtbar? |
| Vulnerability | Sind bekannte Advisories mit Source oder Package verbunden? |
| System Blocklist | Erzwingt eine kritische Regel die Ablehnung des Ergebnisses? |
not_applicable bedeutet, dass ein Layer für diesen Server keinen relevanten
Input besitzt. Er wird aus dem gewichteten Aggregat ausgeschlossen, statt den
Score zu senken. Ein fehlender oder fehlgeschlagener anwendbarer Layer ist
etwas anderes und muss im Review sichtbar bleiben.
Wie die Aggregation funktioniert
Mehrere Layer können konfigurierte Gewichte besitzen. LightNow normalisiert die gewichtete Summe über die Layer, die tatsächlich anwendbar sind. Sichtbare Prozentwerte sind daher keine einfache Checkliste, die vor der Normalisierung 100 ergeben muss.
Der Zahlenwert hilft beim Vergleich. Layer-Status und Evidenz erklären die Entscheidung.
Level interpretieren
| Level | Interpretation |
|---|---|
excellent oder high | Es liegt kein kritischer Fehler vor und die verfügbare Evidenz ist stark. Prüfe trotzdem Capabilities und Datenzugriff für den Einsatzzweck. |
medium oder low | Mindestens ein relevantes Signal ist schwächer oder unvollständig. Prüfe den Layer und entscheide über Isolation oder zusätzlichen Proof. |
unverified | Ein kritischer Fehler oder ein explizites Unverified-Ergebnis muss vor dem Rollout untersucht werden. |
unknown | Die Bewertung besitzt noch nicht genug anwendbare Daten. Unknown bedeutet nicht sicher. |
Trust ist kontextabhängig
Ein Server kann für einen temporären persönlichen Test akzeptabel und als organisationsweites Standardprofil ungeeignet sein. Berücksichtige:
- welche Tools, Resources und Prompts er anbietet,
- auf welche lokalen Dateien oder entfernten Systeme er zugreifen kann,
- ob Produktionsdaten oder sensible Daten betroffen sind,
- ob Ownership- und Source-Evidenz zu eurer Policy passen und
- ob die Evidenz für die Rollout-Entscheidung aktuell genug ist.
Trust Score ersetzt weder Sandboxing, Least Privilege, Secret Scoping noch ein internes Security-Review.
Wann erneut geprüft werden sollte
Prüfe Trust erneut, wenn sich Serverversion, Publisher, Source-Repository, Endpoint oder Vulnerability-Posture ändern. Ein weiterer Review ist außerdem sinnvoll, bevor ein Server aus einem persönlichen Profil zum Organisationsstandard wird.
- Ownership & Verification erklärt Domain- und Repository-Ownership-Signale.
- Produkt-Tour ordnet das Trust-Review in den Weg von Discovery bis Runtime ein.