Eine Richtlinie für alle reicht nicht mehr aus
Die meisten Anwendungen wurden für einen einzigen Nutzertyp entworfen: eine Person, die durch eine Oberfläche klickt und in einem Konto angemeldet ist. Die Zugriffskontrolle folgte dieser Annahme. Wenn die Sitzung gültig ist, wird die Anfrage durchgelassen. Wenn sie automatisiert wirkt, erscheint eine CAPTCHA oder eine Sperre.
Dieses Modell bricht auf. Heute bedient dieselbe Anwendung Menschen, Menschen mit KI-Assistenten und autonome Agenten, die im Auftrag von jemandem handeln. Manche Agenten sind eigene Integrationen von Kunden. Manche sind KI-Assistenten, die Dokumentation abrufen. Manche sind Crawler. Einige versuchen, Ihr Produkt missbräuchlich zu verwenden. Eine einzelne Ja-oder-Nein-Regel kann all dem nicht gerecht werden.
Routing- und Zugriffsrichtlinien für KI-Agenten ersetzen diese einzelne Regel durch eine Reihe bewusster Entscheidungen: Welche Akteure bekommen welches Erlebnis, auf welchen Routen, unter welchen Bedingungen. Proof of Actor liefert Ihrer Anwendung die Evidenz, um diese Entscheidungen zu treffen, und lässt die Entscheidungen selbst bei Ihnen. Für die Gestaltungsprinzipien hinter diesem Ansatz lesen Sie App-Richtlinien für Menschen und KI-Agenten entwerfen und sehen Sie sich den Use Case für SaaS-Anwendungen an, wie Richtlinien auf reale Produkt-Workflows abgebildet werden.
So sieht eine gute Richtlinie für Agenten aus
Eine nützliche Richtlinie ist konkret. Sie benennt eine Route oder einen Workflow, eine Akteurklasse, die erforderliche Evidenzstärke und die Reaktion. Zum Beispiel:
- Nur-Lese-Katalogrouten: verifizierte Agenten zulassen und eine strukturierte Antwort liefern; deklarierte Agenten mit dem Standard-Rate-Limit zulassen.
- Aktionen mit Kontoänderungen: Ihre bestehende erneute Authentifizierung für alle beibehalten; eine Prüfung hinzufügen, wenn der Akteur Unknown ist und die Aktion hohe Auswirkungen hat.
- Support-Einreichungen: offengelegte KI-gestützte Inhalte annehmen und für das Routing kennzeichnen.
- Registrierung: bestehende Prüfungen beibehalten; niemals allein auf Basis eines inferierten Actor-Ergebnisses entscheiden.
Jede dieser Maßnahmen reagiert auf den Akteur, ohne jeden Agenten als Missbrauch zu behandeln und ohne jedem Agenten blind zu vertrauen. Genau dieses Gleichgewicht ist der Kern eines agentenbewussten Zugriffs, und der Blogbeitrag App-Richtlinien für Menschen und KI-Agenten entwerfen geht Route für Route weitere Beispiele durch.
Die fünf Reaktionen
Die Route-Funktion von Proof of Actor ist um fünf Reaktionen herum aufgebaut, zwischen denen Ihre Richtlinien wählen können.
Erlauben
Die Anfrage läuft wie gewohnt weiter. Der meiste Verkehr, einschließlich des meisten Agentenverkehrs auf öffentlichen oder risikoarmen Routen, sollte einfach erlaubt werden.
Anpassen
Passen Sie das Erlebnis an den Akteur an. Liefern Sie einem verifizierten Agenten eine strukturierte API-Antwort oder eine Markdown-Version einer Seite statt einer menschenorientierten Oberfläche. Der Leitfaden zu KI-Agenten mit strukturierten Inhalten versorgen behandelt dieses Muster.
Herausfordern
Fordern Sie etwas Stärkeres an: eine frische Anmeldung, eine zusätzliche Berechtigung, eine Bestätigung des Kontoinhabers. Verwenden Sie Herausforderungen auf Routen, auf denen die Kosten einer falschen Entscheidung hoch sind.
Prüfen
Lassen Sie die Aktion in eine Warteschlange laufen statt direkt abgeschlossen zu werden, oder markieren Sie sie zur Prüfung durch einen Menschen. Prüfen ist nützlich, wenn ein Blockieren legitime Nutzer beeinträchtigen würde, ein unbeaufsichtigter Abschluss aber zu riskant ist.
Begrenzen
Wenden Sie ein auf den Akteur und die Route abgestimmtes Rate- oder Volumenlimit an, damit automatisierte Aufrufer einen für Menschen gedachten Workflow nicht überlasten können.
Warum robots.txt keine Zugriffsrichtlinie ist
Viele Teams beginnen mit robots.txt, und das ist ein sinnvoller erster Hinweis für Crawler. Es ist jedoch keine Zugriffsrichtlinie für Agenten. Betreiber von Crawlern dokumentieren unterschiedliches Verhalten für unterschiedliche User-Agents: Anthropic gibt an, dass seine Bots robots.txt-Direktiven befolgen (Anthropic crawler documentation), während OpenAI darauf hinweist, dass für ChatGPT-User, der handelt, wenn ein Nutzer ChatGPT eine Frage stellt, robots.txt-Regeln möglicherweise nicht gelten, weil die Aktion vom Nutzer ausgelöst wird (OpenAI crawler documentation). robots.txt sagt außerdem nichts über APIs, MCP-Tools oder angemeldete Workflows aus.
Eine Zugriffsrichtlinie muss dort ausgeführt werden, wo die Anfrage verarbeitet wird, Evidenz wie eine unter RFC 9421 geprüfte Signatur lesen und pro Route eine Reaktion wählen. Für MCP server definiert die MCP authorization specification, wie Clients über HTTP Zugriffstoken erhalten; Richtlinien für Akteure ergänzen das um Kontext, sie ersetzen es nicht.
Wie Proof of Actor Ihre Richtlinien speist
Jede Anfrage, die Ihre Integration auswertet, erzeugt ein Actor-Ergebnis mit vier Bestandteilen, die Ihre Richtlinie lesen kann:
- Klasse: Human, Human + AI, Agent oder Unknown.
- Grundlage: Verified, Declared, Inferred oder Unknown, damit Ihre Richtlinie eine validierte Signatur anders behandeln kann als einen selbst deklarierten Client-Namen.
- Evidenzzusammenfassung: eine lesbare Beschreibung, worauf das Ergebnis beruht, nützlich für Protokollierung und Prüfung.
- Kontext: welche Integration und welche Route es erzeugt haben.
Da die Grundlage explizit ist, können Ihre Richtlinien präzise sein. "Agenten zulassen" wird zu "verifizierte Agenten auf Lese-Routen zulassen, deklarierte Agenten drosseln, den Unknown-Fallback auf alles andere anwenden." Der vollständige Ablauf von der Anfrage bis zur Entscheidung wird auf So funktioniert es beschrieben.
Fallbacks sind Teil der Richtlinie
Eine Richtlinie ist nur so gut wie ihr Verhalten, wenn Evidenz fehlt. Proof of Actor macht diese Fälle explizit, statt sie zu verbergen.
- Unknown: Die Evidenz hat keine eindeutige Bestimmung zugelassen. Ihre Richtlinie sagt, was Unknown auf jeder Route bedeutet. Es wird niemals zu Human umgewandelt und standardmäßig niemals als böswillig behandelt.
- Timeout: Das Ergebnis kam nicht rechtzeitig an. Ihre Integration wendet den Fallback an, den Sie für diese Route gewählt haben.
- Fehlende Signale: Ein Collector lief nicht oder ein Header fehlte. Das Ergebnis bildet das ab, und Ihre Richtlinie behandelt es entsprechend.
Für jede Route wählen Sie, ob Sie fail open oder fail closed verwenden. Fail open bedeutet, dass die Anfrage so weiterläuft, als gäbe es Proof of Actor nicht; fail closed bedeutet, dass Ihre bestehende stärkere Prüfung greift. Routen mit niedrigem Risiko sind meist fail open. Sensible Aktionen sind meist fail closed. Sie legen das pro Risikostufe fest, nicht global.
Identität, Anmeldedaten und Autorisierung getrennt halten
Richtlinien für Agentenzugriff sitzen auf drei unterschiedlichen Ebenen, und ihre Trennung verhindert die schwerwiegendsten Fehler.
- Identitäts-Evidenz beantwortet, welche Art von Akteur anfragt und was das belegt. Das liefert Proof of Actor.
- Anmeldedaten beantworten, welches Konto verantwortlich ist. Ihre Sitzung, Ihr Token oder Ihr API-Schlüssel liefert das.
- Autorisierung beantwortet, ob dieser Aufrufer diese Aktion ausführen darf. Ihr Berechtigungsmodell liefert das.
Eine verifizierte Agentenidentität bedeutet nicht, dass der Agent autorisiert ist, dass eine Person ihm Befugnisse übertragen hat oder dass seine Aktion sicher ist. Verwenden Sie Actor-Ergebnisse für Routing und Kontext. Verwenden Sie Ihr Autorisierungsmodell, um Berechtigungen zu erteilen. Die Seite Detection & Limitations erklärt genau, was jede Evidenzart belegen kann.
Einführung, ohne etwas zu beschädigen
Der sicherste Weg, Richtlinien für Agentenzugriff einzuführen, ist stufenweise.
- Beobachten. Installieren Sie Proof of Actor im Beobachtungsmodus. Für Ihre Nutzer ändert sich nichts; die Ergebnisse werden protokolliert.
- Verstehen. Prüfen Sie, welche Akteure welche Routen nutzen, wie hoch die Unknown-Rate auf jeder Route ist und welche Ergebnisse dem widersprechen, was Sie bereits wissen.
- Vorschau. Führen Sie eine Richtlinie in der Vorschau aus und protokollieren Sie, was sie getan hätte, ohne sie durchzusetzen.
- Gezielt durchsetzen. Aktivieren Sie die Richtlinie auf einer Route, auf der die Evidenz sie klar stützt. Beobachten Sie die Ergebnisse.
- Erweitern. Weiten Sie sie auf weitere Routen aus, wenn das Vertrauen wächst.
Der Leitfaden zum sicheren stufenweisen Einführen akteurbewusster Richtlinien führt durch jede Phase, und sensible Aktionen schützen, ohne Agenten zu blockieren behandelt die risikoreichen Routen.
Was Ihr Team bekommt
Mit Proof of Actor erhält Ihr Team eine Integration mit drei Fähigkeiten. Detect sammelt Actor-Signale und trennt verifizierte Aussagen von Inferenz. Understand zeigt Actor-Analysen, Trends und die Evidenz hinter jedem Ergebnis, wobei Unknown sichtbar bleibt. Route ermöglicht es Ihnen, die auf dieser Seite beschriebenen Richtlinien zu schreiben und dort anzuwenden, wo Sie möchten. Während der privaten Beta werden Routing-Richtlinien gemeinsam mit jedem Gründungsteam entworfen und im Code Ihrer eigenen Anwendung ausgeführt, sodass Sie die volle Kontrolle behalten.
Häufige Richtlinienfehler, die Sie vermeiden sollten
Teams, die zum ersten Mal Agentenzugriff entwerfen, wiederholen oft eine Handvoll Fehler. Sie zu vermeiden spart Wochen an Nacharbeit.
- Jeden Agenten standardmäßig blockieren. Legitime Agenten umgehen Sie dann, oft indem sie die für Menschen gebaute Oberfläche auslesen, die sich schwerer schützen lässt als ein strukturierter Pfad.
- Einem deklarierten Namen vertrauen. Ein Client, der sich nur selbst benennt, hat eine Behauptung aufgestellt, keinen Beweis geliefert. Behandeln Sie ihn so, wie Sie einen nicht verifizierten Aufrufer behandeln würden.
- Überall denselben Fallback verwenden. Unknown auf einer öffentlichen Preisseite und Unknown bei einer Passwortänderung sind unterschiedliche Situationen. Jede Route braucht ihre eigene Antwort.
- Über Menschen auf Grundlage einer Inferenz entscheiden. Actor-Ergebnisse sind Kontext für Routing, kein Urteil über eine Person. Lassen Sie folgenschwere Entscheidungen bei Ihren eigenen Kontrollen und Ihrer Prüfung.
- Auf Beobachtung verzichten. Wenn Sie am ersten Tag durchsetzen, entdecken Sie Fehlalarme über Kundenbeschwerden. Erst beobachten, dann dort durchsetzen, wo die Evidenz klar ist.
Eine kurze Richtlinienprüfung mit Ihren Leads aus Security, Produkt und Support vor jedem Durchsetzungsschritt entdeckt die meisten dieser Fehler früh.
Starten Sie mit dem Founding Developer Program
Proof of Actor befindet sich in der privaten Beta. Ausgewählte Gründungsteams können bis zu 12 Monate kostenlosen Zugang innerhalb vereinbarter Nutzungsgrenzen erhalten, mit direkter Unterstützung durch unsere Ingenieure, während Sie Ihre ersten Richtlinien entwerfen.
Wenn Sie entscheiden, wie Ihre Anwendung KI-Agenten behandeln soll, bewerben Sie sich für den frühen Zugang. Teilen Sie uns mit, welche Routen am wichtigsten sind und welche Entscheidungen Sie treffen möchten, und wir helfen Ihnen, passende Richtlinien zu entwickeln. Sie können außerdem sehen, wie sich das auf APIs und MCP server auswirkt.
Quellen
- Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
- Overview of OpenAI crawlers, OpenAI.
- RFC 9421: HTTP Message Signatures, IETF, Februar 2024.
- MCP authorization, modelcontextprotocol.io.