So handhaben Sie Unknown-Traffic in Ihrer App

Ist Unknown ein Fehler oder ein Ergebnis?

Wenn Sie beginnen, Interaktionen als Human, Human + AI, Agent oder Unknown zu klassifizieren, ist der Unknown-Bereich oft größer, als viele erwarten. Es liegt nahe, das als Lücke zu behandeln, die man verstecken sollte, entweder indem man Unknown zu Human zusammenfasst oder indem man es als verdächtig einstuft. Beide Ansätze verursachen Probleme.

Unknown bedeutet, dass die verfügbare Evidenz keine verlässliche Bestimmung trägt. Eine Anfrage von einem Client, der kein JavaScript ausführt, ein Aufruf an einen Endpoint, bei dem Sie keine Signale erfassen, eine Sitzung, die nach einer Seite endet: All das kann völlig legitim sein, und keines davon liefert genug, um zu sagen, wer oder was gehandelt hat.

Unknown ehrlich auszuweisen ist das, was die anderen Klassen vertrauenswürdig hält. Wenn Ihr System nie Unknown sagt, ist jedes Human-Ergebnis teilweise geraten, und Sie können nicht erkennen, welcher Teil das ist. Unser Beitrag über warum Unknown ein gültiges Ergebnis bei der Klassifizierung von KI-Traffic ist erläutert die Begründung ausführlicher.

Dieser Leitfaden behandelt, wie Sie Unknown in der Praxis handhaben: explizite Fallbacks pro Route, die Regeln, die verhindern, dass es in andere Klassen ausläuft, wie Sie es überwachen und wie Sie es dort reduzieren, wo es wichtig ist.

Schritt 1: Niemals standardmäßig Human verwenden

Der häufigste Fehler ist eine Klassifizierungsfunktion, die Human zurückgibt, sobald sie kein Automatisierungssignal findet. Es klingt vernünftig und ist falsch. Das Fehlen eines Bot-Signals ist kein Vorhandensein eines Mensch-Signals.

// Wrong: silence becomes Human
function classifyWrong(e: Evidence) {
  if (e.signatureValid) return { actor: "agent", basis: "verified" };
  if (e.declaredAgent) return { actor: "agent", basis: "declared" };
  return { actor: "human", basis: "inferred" };
}

// Right: Human requires positive evidence, otherwise Unknown
function classify(e: Evidence) {
  if (e.signatureValid) return { actor: "agent", basis: "verified" };
  if (e.declaredAgent) return { actor: "agent", basis: "declared" };
  if (e.interactiveSession) return { actor: "human", basis: "inferred" };
  return { actor: "unknown", basis: "unknown" };
}

Wenden Sie dieselbe Regel überall dort an, wo Ergebnisse erzeugt werden: Timeouts, Fehler, veraltete Cache-Einträge und fehlende Telemetrie ergeben alle Unknown. Schreiben Sie für jeden dieser Pfade einen Test, damit das Verhalten nicht unbemerkt zurückfällt. Das folgende Beispiel verwendet den integrierten Node.js test runner.

import { test } from "node:test";
import assert from "node:assert/strict";

test("missing evidence is unknown, not human", () => {
  const r = classify({ signatureValid: false, declaredAgent: false, interactiveSession: false });
  assert.equal(r.actor, "unknown");
});

Schritt 2: Geben Sie jeder Route einen expliziten Fallback

Unknown braucht ein definiertes Verhalten, und das richtige Verhalten hängt von der Route ab. Entscheiden Sie es pro Route, halten Sie es schriftlich fest und bewahren Sie es in der Konfiguration auf. Wie diese Fallbacks in ein breiteres Policy-Modell passen, sehen Sie in Designing app-level policies for humans and AI agents.

Das Muster ist einfach. Für risikoarme Routen verhält sich Unknown wie normaler Traffic. Für risikoreiche Routen erhält Unknown denselben Schutz, den die Route bereits hat. In keinem Fall verschlechtert das Actor-Ergebnis die Lage eines nicht klassifizierten, aber legitimen Nutzers.

type Fallback = "allow" | "standard_limit" | "existing_checks" | "review";

const unknownFallback: Record<string, Fallback> = {
  "GET /docs/*": "allow",
  "GET /api/catalog": "standard_limit",
  "POST /signup": "existing_checks",
  "POST /account/password": "existing_checks",
  "POST /exports": "review",
};

Schritt 3: Behandeln Sie Timeouts und Fehler auf dieselbe Weise

Die Actor-Auswertung liegt im Request-Pfad und braucht daher ein striktes Zeitbudget. Wenn das Budget überschritten wird, erzeugen Sie Unknown und wenden den Route-Fallback an. Blockieren Sie eine Anfrage niemals nur deshalb, weil die Auswertung langsam war.

async function withBudget<T>(work: Promise<T>, ms: number, onTimeout: T): Promise<T> {
  let timer: NodeJS.Timeout;
  const timeout = new Promise<T>((resolve) => {
    timer = setTimeout(() => resolve(onTimeout), ms);
  });
  try {
    return await Promise.race([work, timeout]);
  } finally {
    clearTimeout(timer!);
  }
}

const result = await withBudget(evaluateActor(req), 150, { actor: "unknown", basis: "unknown" });

Protokollieren Sie, warum ein Ergebnis Unknown ist: keine Evidenz, Timeout, Auswertungsfehler oder veraltete Evidenz. Diese Gründe zeigen Ihnen, was Sie beheben müssen.

Schritt 4: Behandeln Sie Unknown nicht als verdächtig

Unknown ist kein Risikoscore. Viele legitime Clients werden auf manchen Routen immer Unknown sein: Kommandozeilen-Tools, serverseitige Integrationen ohne Signaturen, Accessibility-Tools, datenschutzorientierte Browser und einfache Feed-Reader. Selbst große KI-Betreiber identifizieren ihre Fetcher heute meist über User-Agent und veröffentlichte IP-Bereiche. Die OpenAI crawler documentation listet zum Beispiel Stand November 2026 für jeden ihrer Bots einen User-Agent-String und eine veröffentlichte IP-Adressdatei auf.

Wenn Sie auf verdächtiges Verhalten reagieren wollen, stützen Sie sich auf Verhalten, das Sie beschreiben können, etwa Request-Raten, fehlgeschlagene Login-Muster oder Abuse-Berichte, mit eigener Evidenz. Halten Sie diese Logik von der Actor-Klasse getrennt, damit sich beides nicht gegenseitig verzerrt.

Schritt 5: Wie überwachen Sie Ihre Unknown-Rate?

Die Unknown-Rate ist der Anteil der Interaktionen, die als Unknown klassifiziert wurden. Verfolgen Sie sie pro Route, pro Integrationskontext und im Zeitverlauf. Sie ist eine der nützlichsten Gesundheitsmetriken, die Sie haben.

type Row = { route: string; actor: string };

export function unknownRate(rows: Row[]) {
  const byRoute = new Map<string, { total: number; unknown: number }>();
  for (const r of rows) {
    const s = byRoute.get(r.route) ?? { total: 0, unknown: 0 };
    s.total += 1;
    if (r.actor === "unknown") s.unknown += 1;
    byRoute.set(r.route, s);
  }
  return [...byRoute].map(([route, s]) => ({ route, rate: s.unknown / s.total, total: s.total }));
}

Was die Zahlen Ihnen sagen:

• Eine hohe, stabile Rate auf einer Route bedeutet meist, dass Ihnen dort ein Signal fehlt. Eine Seite, die nie Ihre Browser-Integration lädt, oder eine API, die nie signierte Requests sieht, bleibt überwiegend Unknown.
• Ein plötzlicher Anstieg bedeutet oft, dass sich in Ihrem Stack etwas geändert hat, etwa ein Release, das einen Header entfernt hat, eine CDN-Regel, die Signature-Header entfernt, oder eine Frontend-Änderung, die das Senden Ihrer App-Deklarationen gestoppt hat.
• Ein plötzlicher Rückgang sollte ebenfalls geprüft werden. Wenn Unknown sinkt, während Human steigt, bestätigen Sie, dass neue Evidenz angekommen ist, statt dass sich stillschweigend ein Fallback geändert hat.

Setzen Sie Alarme auf starke Veränderungen, nicht auf absolute Werte. Jede Anwendung hat ihr eigenes Normal.

Schritt 6: Wie reduzieren Sie Unknown dort, wo es zählt?

Sie müssen Unknown nicht auf null bringen. Sie brauchen nur genug Evidenz auf den Routen, auf denen Entscheidungen wichtig sind. Arbeiten Sie sie nach Wirkung geordnet ab:

1. Fügen Sie zuerst Evidenz auf Routen mit hoher Wirkung hinzu. Wenn Kontoänderungen meist Unknown sind, ist das der Punkt, an dem eine Browser-Integration oder eine serverseitige Prüfung sich auszahlt.
2. Bitten Sie automatisierte Clients, sich auszuweisen. Veröffentlichen Sie Dokumentation für Ihre API, die erklärt, wie Agenten Requests mit HTTP Message Signatures und den IETF Web Bot Auth conventions signieren können, und geben Sie verifizierten Clients ein besseres Erlebnis, etwa höhere Limits oder strukturierte Antworten. Clients, die sich verifizieren können, werden damit beginnen.
3. Nutzen Sie Ihr eigenes Anwendungswissen. Wenn Nutzer mit Ihrem eingebauten Assistenten interagieren, protokollieren Sie das als Deklaration. Ihre App weiß oft mehr als das Netzwerk.
4. Beheben Sie die Infrastruktur. Stellen Sie sicher, dass Proxies die Header weiterleiten, auf die Sie sich verlassen, und dass die Auswertung genügend Zeitbudget hat, um abgeschlossen zu werden.

Für einen praktischen Blick auf die Signale, die Traffic aus Unknown herausführen, lesen Sie how to tell if website traffic comes from AI agents.

Schritt 7: Zeigen Sie Unknown in Dashboards ehrlich an

Stellen Sie Unknown als eigene Serie mit demselben visuellen Gewicht wie die anderen Klassen dar. Verstecken Sie es nicht in einem "other"-Bereich, und färben Sie es nicht wie einen Alarm. Wenn Stakeholder einen großen Unknown-Anteil sehen, ist die richtige Reaktion nicht "wo sind die Bots", sondern "wo brauchen wir mehr Evidenz".

Schritt 8: Prüfen Sie Unknown anhand von Ergebnissen, nicht von Annahmen

Nehmen Sie alle paar Wochen eine Stichprobe von Unknown-Interaktionen aus Ihren wichtigsten Routen und sehen Sie sich an, was tatsächlich passiert ist. Wurde die Sitzung abgeschlossen, ein Kauf getätigt, ein Projekt erstellt, drei Artikel gelesen oder kam es wiederholt zu Login-Fehlern? Ergebnisse zeigen Ihnen, welche Art von Traffic in dem Bereich liegt, ohne ihm vorschnell ein Label aufzuzwingen.

Ordnen Sie Ihre Beobachtungen in drei praktische Kategorien ein:

1. Legitim und geringes Risiko. Feed-Reader, Link-Vorschauen, Monitoring-Tools und Menschen mit Datenschutzeinstellungen. Lassen Sie den Route-Fallback unverändert.
2. Legitime Automatisierung, die sich selbst ausweisen könnte. Integrationen und Agenten, die gerne einen strukturierten Pfad nutzen oder Requests signieren würden, wenn Sie einen anbieten. Veröffentlichen Sie Hinweise und nehmen Sie Kontakt auf, wo Sie können.
3. Verhalten, das eine eigene Steuerung braucht. Credential Stuffing oder Scraping-Muster, beides katalogisiert im Projekt OWASP Automated Threats to Web Applications. Behandeln Sie diese mit verhaltensbasierten Kontrollen, die ihre eigene Evidenz haben, etwa Login-Fehlerraten, und halten Sie sie von der Actor-Klasse getrennt.

Diese Prüfung hält Ihre Fallbacks an Ihrem echten Traffic ausgerichtet und gibt Ihnen eine klare Liste, wo Sie als Nächstes Evidenz hinzufügen sollten.

Häufige Fragen

Soll Unknown zu den Ratelimits zählen? Verwenden Sie Ihre Standardlimits. Ratelimitierung nach Klasse ist für verifizierte Agenten in Ordnung, die höhere Limits verdienen können, aber Unknown sollte das normale Limit erhalten, kein strafendes.

Können wir Unknown-Nutzer challengen? Nur dort, wo die Route in dieser Situation ohnehin alle challengt. Einen Challenge nur deshalb hinzuzufügen, weil ein Ergebnis Unknown ist, benachteiligt legitime Nutzer, deren Clients weniger Signale senden.

Wird Unknown kleiner, wenn Standards reifen? Wenn mehr automatisierte Clients Requests signieren, wandert mehr Agent-Traffic von Unknown oder declared zu verified. Ihr Monitoring zeigt diese Verschiebung Route für Route.

Wo Proof of Actor passt

Proof of Actor meldet Unknown als erstklassiges Ergebnis, mit der Begründung, und wandelt es niemals in Human um. Ihre Anwendung wählt den Fallback für jede Route, und die Analysen zeigen, wo die Abdeckung endet, damit Sie dort Evidenz hinzufügen können, wo es zählt.

Um das gemeinsam mit unserem Team in einer Produktionsanwendung einzurichten, beantragen Sie frühzeitigen Zugriff. Um genau zu verstehen, was die Evidenz belegen kann, lesen Sie Detection & Limitations.

Quellen

• RFC 9421: HTTP Message Signatures: der Standard, mit dem automatisierte Clients Requests signieren können
• draft-ietf-webbotauth-httpsig-protocol: IETF-Entwurf zu Web Bot Auth für signierten automatisierten Traffic (Stand November 2026 in Arbeit)
• OpenAI: Overview of OpenAI Crawlers: User-Agent-Strings und veröffentlichte IP-Adressdateien für die Bots von OpenAI
• OWASP Automated Threats to Web Applications: Taxonomie automatisierter Bedrohungen wie Credential Stuffing und Scraping
• Node.js test runner: das node:test-Modul, das im Beispiel verwendet wird