Base URL, API-Schlüssel und Modell-ID eingeben und 84 Standardprüfungen ausführen. Mit 2 optionalen Prüfungen sind es höchstens 86. Geprüft werden Modellidentität, Token-Abrechnung, Prompt-Injection, Lieferkettenrisiken und Streaming.
Ein Nutzer stellt eine unzulässige Frage, und gesperrt wird dein API-Schlüssel. Jede Anfrage durchläuft zuerst die Inhaltsprüfung von BazaarLink; Hochrisiko-Fragen werden blockiert und erreichen das Upstream nicht. So wird das Risiko, dass regelwidrige Inhalte zur Sperrung deines Kontos führen, deutlich gesenkt.
Mehr über BYOK →Ein API key; ist ein Knoten ausgelastet, ein Prozess abgestürzt oder eine Maschine getrennt, wechseln Anfragen nahtlos zu einem Plattformmodell; Traffic über deinen Knoten kostet nichts, nur vom Fallback übernommener Traffic wird berechnet.
Vollständige Installationsanleitung →Wir fragen einen Endpunkt nie, welches Modell er ist — jeder Endpunkt kann jeden Namen nennen. Wir schicken 84 Standardprüfungen und lassen ihn damit wirklich arbeiten; anschließend vergleichen wir die Art dieser Arbeit mit den Referenzwerten bekannter Modelle. Das Urteil entsteht in fünf Stufen, von grob nach fein, und jede Stufe darf sagen: „Die Belege reichen nicht, ich lege mich nicht fest.“
Lässt sich dieser Endpunkt überhaupt messen?
Die erste Voraussetzung ist, dass die Fragen tatsächlich beantwortet wurden. Fehlende Antworten bedeuten nicht nur weniger Daten: Die verbliebenen können zufällig alle in dieselbe Richtung zeigen, und das ist eine Stichprobenverzerrung, kein Beleg.
Antwortet der Endpunkt gar nicht, oder greifen Schlüssel oder Modellname schlicht nicht, hören wir dort auf, statt aus Bruchstücken ein Urteil zusammenzusetzen.
Von wem stammt dieses Modell?
Der häufigste Austausch überschreitet Familiengrenzen: ein billiges Modell im teuren Namen. Das Verhalten auf Familienebene ist am stabilsten und am schwersten zu fälschen, deshalb fragen wir diese Ebene zuerst. Verglichen werden Stil und Gewohnheiten der Antworten, nicht die Selbstauskunft — sie ist das am leichtesten zu fälschende Element des ganzen Berichts.
Ohne belastbare Familienbelege enthalten wir uns, statt trotzdem einen Namen zu nennen. Nennt ein Endpunkt auf Chinesisch einen Hersteller, verhält sich aber wie ein anderer, werten wir die Auskunft als Versprecher und kehren zu den Verhaltensbelegen zurück.
Welches Modell innerhalb dieser Familie ist es?
Sie haben ein bestimmtes Modell gekauft, nicht „irgendetwas von diesem Hersteller“. Was Nutzer als Leistungsabfall erleben, passiert meist auf dieser Ebene: Die Familie bleibt, ein billigeres Geschwistermodell tritt an ihre Stelle. Wir vergleichen gleichzeitig innerhalb der Familie und über Familien hinweg und lassen beide Ergebnisse einander prüfen — ist die Familie erst falsch bestimmt, benennt der Vergleich innerhalb der Familie sehr überzeugt das falsche Modell.
Reichen die Belege nur bis zur Familienebene, schreibt der Bericht genau das: Wir erkennen den Hersteller, nicht das Modell. Wir füllen die Lücke nicht mit dem ähnlichsten Kandidaten.
Lässt sich das in der Vorstufe gewählte Modell wirklich von seinen nächsten Geschwistern trennen?
Manche Modelle sind Zwillinge: Stil, Fähigkeiten und Formulierungsgewohnheiten überlappen so stark, dass die Vorstufe zwischen ihnen kaum Trennschärfe hat. Die Werte liegen dicht beieinander, ohne dass diese Nähe etwas bedeutet. Diese Stufe tut genau eines: Für solche Gruppen naher Verwandter zieht sie mit einem eigenen, genau für diesen Vergleich gebauten Fragensatz neue Stichproben und liest die gesamte Verteilung statt einzelner Antworten. Besteht sie, wird die Vorstufe bestätigt oder verworfen; besteht sie nicht, bleibt die Vorstufe stehen.
Diese Stufe trägt eine bewusste Asymmetrie: Sind die Belege nicht entscheidend und stimmt die Vorstufe zufällig mit der Angabe des Anbieters überein, verwerfen wir nicht. Einen ehrlichen Anbieter fälschlich zu beschuldigen kostet mehr, als einen unehrlichen zu übersehen.
Worin unterscheidet sich das Gemessene von der Angabe des Anbieters?
Das Erkennen selbst sieht die Angabe des Anbieters nicht an — die vorangehenden Stufen vergleichen ausschließlich Verhaltensbelege. Die Angabe kommt an genau zwei Stellen ins Spiel: wenn die vierte Stufe über ein Verwerfen entscheidet, und hier. Diese Reihenfolge ist Absicht — wer die Antwort vor der Frage kennt, lässt sich von der Angabe nicht führen. Die Ergebnisse sind: vollständige Übereinstimmung, nur Familie stimmt, falsches Modell in richtiger Familie, Austausch, gefälschte Selbstauskunft, induziertes Verhalten, Datenlage unzureichend und uneindeutig.
Widersprechen sich die Signale ohne stabile Mehrheit, lautet das Ergebnis „uneindeutig“. Das ist ein reguläres Urteil und keine Störung.
Weil die beiden Fehlerrichtungen nicht gleich viel kosten. Ein ehrliches Relay des Modellaustauschs zu bezichtigen ist eine Anschuldigung und schadet realen Menschen; einen Austausch zu übersehen lässt Ihnen dagegen die Möglichkeit, erneut zu prüfen oder die Historie zu lesen. Bei dünner Beweislage legen wir uns deshalb nicht fest.
Das hat im Code eine konkrete Form: Der Bericht zeichnet „Modell weicht ab“ nur, wenn die Engine einen Austausch bestätigt hat. „Das ähnlichste Modell weicht zufällig von der Angabe ab“ wird nie als Anschuldigung dargestellt — das ist bloß unsere Vermutung. Steht dort „unbestimmt“, lautet die richtige Lesart: Die Belege dieses Laufs tragen kein Urteil. Das ist weder ein Freispruch noch eine Verurteilung.
Das sind die Grenzen, die wir kennen. Wir schreiben sie auf, weil ein Bericht, der seine Grenzen verschweigt, mehr Vertrauen erhält, als ihm zusteht.
Eine Prüfung ist eine Stichprobe. Ein Relay kann nur einen Teil des Verkehrs austauschen oder immer dann echte Ware liefern, wenn der Verkehr nach einer Prüfung aussieht. Einmal bestanden ist nicht dasselbe wie dauerhaft ehrlich — prüfen Sie regelmäßig nach und lesen Sie die Historie statt eines einzelnen Berichts.
Ahmt ein Nachahmer mehr als die Hälfte des Verhaltens gezielt nach, zeigt bauartbedingt etwa die Hälfte der Belege auf die behauptete Identität. Das ist eine strukturelle Grenze und kein Mangel an Prüfungen — wir haben es gemessen: Mehr Prüfungen erhöhten die Kosten stark und die Trennschärfe kaum.
Ein Übereinstimmungsurteil bedeutet „die Belege dieses Laufs stützen keinen Austausch“, nicht „es gab keinen Austausch“. Jede Prüfung, die Letzteres garantieren will, überschätzt sich selbst.
Der Entscheidungsweg wird nachträglich aus gespeicherten Daten rekonstruiert; die Engine hält nicht fest, welche Regel sie damals genommen hat. Manche Verzweigungen hinterlassen keine unterscheidbare Spur, und dann zeigen wir nur das Ergebnis, ohne die Regel zu benennen. Lieber sagen wir weniger, als zu raten.
Die Antwort erfüllt Referenzwert und Sicherheitsschwelle dieser Prüfung.
Das Signal ist unvollständig oder nahe am Grenzwert; Erklärung und Rohantwort prüfen.
Eine Abweichung, ein Protokollfehler oder Integritätsrisiko wurde bestätigt.
Familien-Fingerprints, Submodell-Merkmale und Anti-Spoofing-Signale werden mit der Modellangabe abgeglichen.
Token-Zahlen, SSE-Struktur, Latenz und Antwortformat werden auf Aufblähung und Relay-Fehler geprüft.
Prüft System-Prompt-Injection, Geheimnisabfluss, Dependency-Hijacking und Signaturmanipulation.
Diese Probe erkennt drei zentrale Relay-Angriffsklassen aus arXiv 2604.08407: Dependency-Hijacking, bedingte System-Prompt-Injection und den Abfluss von Zugangsdaten. Sie zeigt Identitätsbelege und Verhaltenswarnungen, vergibt aber keinen Sicherheits-Score.
The proxy modifies tool-call or text content during response parsing, causing the agent to execute attacker-specified operations. Common tactics include tampering with npm/pip/go/cargo install commands, injecting typosquatting packages, and rewriting shell command parameters. Detection compares the proxy's response to direct-connect tool-call payloads to surface silent rewrites.
The proxy conditionally injects a system message based on prompt content — malicious instructions for requests containing sensitive terms like "bank", "password", or "transfer", silence for everything else. The skew shows up statistically. Detection uses Proxy Monitor to compare the system-prompt offset between baseline and the relay under test.
The proxy silently scans both requests (request) and responses (response) for API keys, access tokens, personal data, and trade secrets. Because the content itself is not modified, generic diff tools miss it. Detection injects a honeypot token and verifies whether it surfaces in proxy logs, Telegram bots, or external endpoints.
Die Suite umfasst 84 Standardprüfungen und 2 optionale Prüfungen, insgesamt höchstens 86. Optionale Prüfungen laufen nur bei passender Einstellung und Endpoint-Fähigkeit.
Probe vergleicht Modellfamilie, Submodell-Fingerprints, Wissens- und Fähigkeitsmerkmale sowie das Verhalten ohne Eigenangaben. Ein einzelnes schwaches Signal gilt nicht als Beweis.
Der API-Schlüssel wird nur für die angeforderte Prüfung verwendet und erscheint weder im Bericht noch im öffentlichen Link. Verwenden Sie einen widerrufbaren Testschlüssel mit kleinem Limit.
Nein. Eine Warnung kennzeichnet unvollständige oder auffällige Evidenz. Prüfen Sie Erklärung und Rohantwort; ein starkes Fehlurteil verlangt mehrere übereinstimmende Signale.
