Wie Sie sensible Aktionen schützen, ohne legitime Agents zu blockieren

Warum nicht einfach Agents von sensiblen Aktionen ausschließen?

Einige Aktionen in Ihrer Anwendung sind wichtiger als andere. Ein Passwort ändern, ein Teammitglied hinzufügen, Daten exportieren, ein Projekt löschen, eine Bestellung freigeben: Wenn so etwas ohne die richtige Berechtigung geschieht, ist der Schaden real.

Gleichzeitig wird immer mehr legitime Arbeit in Ihrer App von Automatisierung erledigt. Ein Nutzer bittet einen Assistenten, seine Einstellungen zu aktualisieren. Eine Partner-Integration legt nach Zeitplan Datensätze an. Ein interner Agent erstellt Support-Tickets. Wenn Sie jeden automatisierten Client von sensiblen Routen ausschließen, bricht diese Arbeit weg und zwingt Menschen zurück zu manueller Arbeit oder zu Umgehungen, die schwerer abzusichern sind.

Die Antwort lautet nicht "Agents blockieren" oder "Agents vertrauen". Es ist ein Modell, in dem das Risiko der Aktion, die Berechtigung hinter der Anfrage und die Evidenz über den Actor jeweils eine eigene Rolle spielen. Dieser Leitfaden entwickelt dieses Modell. Für die breitere Einordnung dazu siehe App-level-Policies für Menschen und AI-Agents entwerfen.

Schritt 1: Staffeln Sie Ihre Routen nach Risiko

Beginnen Sie mit der Klassifizierung von Aktionen, nicht von Clients. Ein einfaches Drei-Stufen-Schema funktioniert für die meisten Anwendungen:

Schreiben Sie die Stufe in die Route-Konfiguration, damit sie im Code Review sichtbar ist:

type Tier = "low" | "medium" | "high";

export const routeTier: Record<string, Tier> = {
  "GET /projects": "low",
  "POST /projects": "medium",
  "POST /projects/:id/members": "medium",
  "POST /account/password": "high",
  "POST /exports": "high",
  "DELETE /projects/:id": "high",
};

Stufen ändern sich langsam und sind leicht zu begründen. Alles andere in diesem Leitfaden hängt von ihnen ab.

Schritt 2: Wie unterscheiden sich Identität, Anmeldedaten und Autorisierung?

Drei Fragen werden oft miteinander vermischt:

1. Wer oder was handelt? Das ist Actor-Evidenz: eine interaktive Person, eine Person mit AI-Unterstützung, ein Agent oder Unknown, mit einer Grundlage wie Verified oder Declared.
2. Welches Anmeldedatum wurde vorgelegt? Ein Session-Cookie, ein API-Schlüssel, ein OAuth-Zugriffstoken.
3. Ist dieses Anmeldedatum berechtigt, diese Aktion auf dieser Ressource auszuführen? Das ist Autorisierung.

Eine verifizierte Agent-Signatur (RFC 9421) beantwortet die erste Frage gut. Sie sagt nichts über die dritte aus, ein Punkt, der in was signierte Requests von AI-Agents beweisen und was nicht im Detail behandelt wird. Ein OAuth-Token mit dem richtigen Scope beantwortet die dritte Frage. Es sagt wenig über die erste aus. Ihre Entscheidung für eine Aktion der hohen Stufe braucht immer eine gute Antwort auf die dritte Frage und nutzt die erste, um zu bestimmen, wie viel zusätzliche Absicherung verlangt werden soll.

interface Context {
  actor: { actor: "human" | "human_ai" | "agent" | "unknown"; basis: "verified" | "declared" | "inferred" | "unknown" };
  credential: { type: "session" | "oauth" | "api_key"; scopes: string[]; subject: string };
}

function authorized(ctx: Context, action: string, resourceOwner: string): boolean {
  return ctx.credential.subject === resourceOwner && ctx.credential.scopes.includes(action);
}

Autorisierung wird wegen eines günstigen Actor-Ergebnisses niemals gelockert. Der Actor-Kontext fügt nur Anforderungen hinzu oder wählt zwischen gleich sicheren Pfaden.

Schritt 3: Verwenden Sie delegierte Berechtigungen für Agents, die für Menschen handeln

Wenn ein Agent im Auftrag eines Nutzers handelt, geben Sie ihm eigene Anmeldedaten mit begrenzter Befugnis, statt ihm zu erlauben, die Sitzung des Nutzers wiederzuverwenden. OAuth 2.0 ist das Standardwerkzeug: Der Nutzer genehmigt bestimmte Scopes für einen bestimmten Client, und das Token hält diesen Client fest. RFC 9700, die OAuth 2.0 Security Best Current Practice, beschreibt, wie sich das sicher einsetzen lässt. MCP server folgen demselben Muster: Die MCP authorization specification behandelt einen geschützten MCP server als OAuth 2.1 resource server. Unser Beitrag wer ruft Ihren MCP server auf? überträgt das auf Tool-Aufrufe.

Das liefert genau das, was Sie für sensible Aktionen brauchen:

• Das Token zeigt, welcher Client handelt und für wen.
• Scopes begrenzen, was er tun kann. Ein Planungs-Agent mit calendar:write kann kein Passwort ändern.
• Der Nutzer kann die Freigabe widerrufen, ohne seine eigenen Anmeldedaten zu ändern, und OAuth 2.0 Token Revocation (RFC 7009) definiert, wie ein Client dem Authorization Server mitteilt, dass ein Token nicht mehr gültig sein soll.
• Audit-Logs zeigen, dass der Agent und nicht der Nutzer die Aktion ausgeführt hat.

Falls Ihre App delegierte Anmeldedaten noch nicht unterstützt, priorisieren Sie das für die Aktionen, die Agents am häufigsten benötigen. Es ist die wirksamste einzelne Kontrolle für automatisierten Zugriff.

Schritt 4: Wann sollten Sie eine Step-up-Prüfung verlangen?

Step-up bedeutet, im Moment einer sensiblen Aktion zusätzliche Sicherheit zu verlangen. Für durch OAuth geschützte APIs definiert RFC 9470, wie ein resource server einem Client mitteilt, dass das aktuelle Token nicht stark genug oder nicht aktuell genug authentifiziert ist. Der passende Step-up hängt davon ab, wer handelt:

• Interaktive Person (Human, Human + AI): erneute Authentifizierung (siehe die Reauthentifizierungsanforderungen in NIST SP 800-63B), eine Passkey-Abfrage auf Basis von WebAuthn oder ein Einmalcode.
• Agent mit delegierter Berechtigung: ein Scope, der speziell für die Aktion der hohen Stufe gedacht ist, vom Nutzer explizit freigegeben, oder eine Bestätigung, die dem Nutzer außerhalb des Bandes gesendet wird.
• Unknown: die bestehende starke Prüfung der Route, unverändert.

type Requirement = "none" | "reauth" | "explicit_scope" | "user_confirmation" | "review";

function stepUp(tier: Tier, ctx: Context): Requirement {
  if (tier !== "high") return "none";
  const { actor } = ctx.actor;
  if (actor === "human" || actor === "human_ai") return "reauth";
  if (actor === "agent" && ctx.credential.type === "oauth") return "explicit_scope";
  if (actor === "agent") return "user_confirmation";
  return "reauth";
}

Beachten Sie, dass ein Human-Ergebnis den Step-up nicht überspringt. Es wählt den Step-up, der für eine interaktive Person passt. Inferences können falsch sein, daher sollten sie die Form der Prüfung verändern, nicht sie entfernen.

Schritt 5: Leiten Sie an die menschliche Prüfung weiter, wo Urteil nötig ist

Einige Aktionen sind selten, folgenschwer und schwer sicher zu automatisieren: Massenexporte von Kundendaten, Kontowiederherstellung nach verloren gegangenen Anmeldedaten oder das Löschen einer Organisation. Dafür ist eine Prüfungswarteschlange oft besser als jede automatisierte Regel.

Actor-Kontext macht die Prüfung schneller und fairer, indem er der prüfenden Person die Evidenz gibt: die Klasse, die Grundlage, das verwendete Anmeldedatum, die Historie ähnlicher Anfragen. Die prüfende Person entscheidet. Die Klassifizierung liefert den Kontext.

function shouldReview(route: string, ctx: Context): boolean {
  const reviewRoutes = new Set(["POST /exports", "POST /account/recover"]);
  if (!reviewRoutes.has(route)) return false;
  return !(ctx.credential.type === "oauth" && ctx.credential.scopes.includes("export:bulk"));
}

Schritt 6: Wählen Sie das Fehlerverhalten pro Stufe

Die Actor-Bewertung kann auslaufen oder keine Evidenz haben. Entscheiden Sie im Voraus, was dann passiert.

• Niedrige Stufe: fail open. Die Anfrage wird normal ausgeführt.
• Mittlere Stufe: fail open, mit normaler Autorisierung in Kraft.
• Hohe Stufe: fail closed auf die bestehende starke Prüfung. Fehlende Actor-Evidenz schwächt den Schutz niemals und blockiert auch niemals eine Anfrage, die Ihre normalen Prüfungen sonst bestanden hätte.

Die entscheidende Eigenschaft ist Symmetrie. Ein Fehler in der Actor-Bewertung sollte die Aktion genau so sicher und genau so verfügbar lassen, wie sie war, bevor Sie Actor-Kontext hinzugefügt haben.

Schritt 7: Treffen Sie keine folgenschweren Entscheidungen über Menschen auf Basis von Inferences

Eine inferred Klassifizierung ist Evidenz über eine Interaktion, keine Tatsache über eine Person. Lehnen Sie niemandem eine Bewerbung, eine Kreditentscheidung, ein Prüfungsergebnis, Wohnraum oder den Zugang zu einem essenziellen Dienst ab, nur weil eine Sitzung automatisiert oder AI-unterstützt wirkte. Nutzen Sie in solchen Abläufen Actor-Kontext, um einen Prozess zu wählen, etwa menschliche Prüfung oder einen alternativen Verifizierungspfad, und stellen Sie sicher, dass die Person ihn abschließen kann.

Das ist sowohl ein Fairnessprinzip als auch ein praktisches. Inferences haben false positives, und die Kosten eines false positive in solchen Abläufen trägt jemand, der nichts falsch gemacht hat.

Schritt 8: Führen Sie zuerst mit Beobachtung aus

Bevor irgendetwas davon reale Anfragen beeinflusst, betreiben Sie es im Beobachtungs- und Preview-Modus:

1. Zeichnen Sie Stufe, Actor-Klasse, Grundlage, Anmeldedatentyp und den Step-up auf, den Ihre Policy verlangen würde.
2. Prüfen Sie Stichproben von Anfragen der hohen Stufe nach Klasse. Verwenden legitime Agents delegierte Anmeldedaten oder verwenden sie Benutzersitzungen wieder?
3. Beheben Sie die Lücken, die Sie finden, oft durch das Angebot von Scoped Credentials, bevor Sie enforce.
4. Enforce auf einen kleinen Ausschnitt einer einzelnen Route, messen Sie die Abschlussraten und erweitern Sie dann.

Schritt 9: Führen Sie einen Audit-Trail, der "wer und im Auftrag von wem" beantwortet

Für jede Aktion der hohen Stufe protokollieren Sie genug, um später nachvollziehen zu können, was passiert ist:

• die Actor-Klasse und die Grundlage zum Zeitpunkt der Anfrage,
• den Typ des Anmeldedatums, den Client, für den es ausgestellt wurde, und das Subjekt, das es repräsentiert (OAuth 2.0 Token Exchange, RFC 8693, definiert einen act-Claim, um genau diese Art von "acting for"-Beziehung festzuhalten),
• die Scopes, die die Aktion autorisiert haben,
• die angewendete Step-up- oder Prüfungsanforderung und ihr Ergebnis.

audit.write({
  action: "project.export",
  actor: ctx.actor,
  client: ctx.credential.type === "oauth" ? clientIdFromToken(req) : undefined,
  subject: ctx.credential.subject,
  scopes: ctx.credential.scopes,
  requirement,
  outcome: "approved",
  at: new Date().toISOString(),
});

Mit diesem Trail hat eine Frage wie "hat eine Person oder ein Assistent dieses Projekt gelöscht, und wer hat es freigegeben" eine klare Antwort. Das macht die Incident Response schneller und gibt Nutzern Vertrauen, dass automatisierte Hilfe in Ihrer App nachvollziehbar ist.

Ein durchgerechnetes Beispiel

Eine Projektmanagement-App sieht, wie ein Assistent für Nutzer Fälligkeitsdaten von Aufgaben aktualisiert und gelegentlich versucht, ganze Projekte zu exportieren.

• Das Aktualisieren einer Aufgabe ist mittlere Stufe. Der Assistent verwendet ein OAuth-Token mit tasks:write. Autorisiert, kein Step-up. Erlaubt.
• Der Export eines Projekts ist hohe Stufe. Dem Token des Assistenten fehlt export:bulk. Die App sendet dem Nutzer eine Bestätigungsanfrage. Der Nutzer stimmt zu, und die App gewährt den Scope für diesen Client.
• Ein Unknown-Client versucht denselben Export mit einem wiederverwendeten Session-Cookie. Die bestehende Reauthentifizierungsaufforderung greift, genau wie zuvor.

Niemand wurde wegen eines Agents blockiert. Jede folgenschwere Aktion hatte eine ausdrückliche Berechtigung.

Wo Proof of Actor hineinpasst

Proof of Actor liefert die Actor-Seite dieses Modells: wer oder was handelt und auf welcher Grundlage. Ihre Anwendung behält Authentifizierung, Autorisierung und die endgültige Entscheidung. Detect den Actor, Understand, wie jede Klasse Ihre sensiblen Routen nutzt, und Route jede Anfrage an das passende Maß an Absicherung.

Um dies mit unserem Team für Ihre Anwendung zu entwerfen, bewerben Sie sich für frühen Zugang. Für SaaS-Szenarien im Detail siehe SaaS Apps & Websites.

Quellen

• RFC 6749: The OAuth 2.0 Authorization Framework: Scoped, delegierte Anmeldedaten für Clients
• RFC 9700: Best Current Practice for OAuth 2.0 Security: Aktuelle Sicherheitsempfehlungen für OAuth-Deployments
• RFC 7009: OAuth 2.0 Token Revocation: Eine Freigabe widerrufen, ohne die Anmeldedaten des Nutzers zu ändern
• RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol: Signalisieren, dass stärkere oder aktuellere Authentifizierung erforderlich ist
• RFC 8693: OAuth 2.0 Token Exchange: Der act-Claim (actor) für Delegation
• MCP specification 2026-07-28: Authorization: MCP servers als OAuth 2.1 resource servers
• NIST SP 800-63B: Authentication and Authenticator Management: Hinweise zur Reauthentifizierung
• W3C Web Authentication (WebAuthn) Level 3: Der Standard hinter Passkey-Abfragen
• RFC 9421: HTTP Message Signatures: Was eine verifizierte Agent-Signatur belegt