Zum Hauptinhalt springen

Sicherheit, Verweigerungen & Fallbacks

Fortgeschritten

In der Produktion muss dein Code den Fall abdecken, in dem Claude nicht wie erwartet antworten will (oder kann). Gut gemacht bleibt das für Nutzer unsichtbar; schlecht gemacht ist es ein Crash oder eine verwirrende Antwort.

What you'll learn
  • Eine Modell-Verweigerung von einem Classifier-/Safety-Block unterscheiden — und warum das zählt
  • Eine Verweigerung als normales Ergebnis behandeln, statt zu crashen oder eine leere Antwort zu zeigen
  • Ungewollte Verweigerungen reduzieren, ohne die berechtigten jailbreaken zu wollen
  • Einen Fallback wählen: klärende Rückfrage, sichere Alternative oder Übergabe an einen Menschen

Zwei verschiedene Dinge​

  • Eine Modell-Verweigerung — Claude lehnt eine Anfrage ab (z. B. weil er sie als schädlich einstuft). Die Antwort signalisiert das (typischerweise über einen Refusal-stop_reason/-Content). Behandle sie als normales Ergebnis, nicht als Fehler.
  • Ein Classifier-/Safety-Block — eine separate Sicherheitsschicht kann Inhalte blockieren. Das kann anders aussehen als eine Modell-Verweigerung.

Zu wissen, was du bekommen hast, lässt dich passend reagieren, statt blind zu wiederholen.

Souverän behandeln​

resp = client.messages.create(...)
if getattr(resp, "stop_reason", None) == "refusal":
    # Don't show a raw/empty result. Offer a safe fallback or a clarifying ask.
    show_user("I can't help with that as asked. Here's what I can do instead…")
else:
    render(resp)

Ungewollte Verweigerungen reduzieren​

  • Legitimen Kontext hinzufügen. Eine Anfrage kann etwas Sensibles matchen, obwohl die Absicht harmlos ist; den echten, legitimen Zweck zu nennen hilft.
  • Präzise sein. Vage oder verwegene Formulierungen laden zu Vorsicht ein.
  • Nicht dagegen anrennen. Wenn eine Anfrage tatsächlich unzulässig ist, ist die Verweigerung korrekt — gestalte einen sauberen Ausweg, statt zu jailbreaken.

Den legitimen Kontext gleich vorne nennen

I am a security engineer at [company] reviewing our own authentication code
before a release. Below is a function we wrote and own.

Identify weaknesses in it and explain how an attacker would exploit each one,
so we can fix them before we ship.

[code]

Fallback-Muster​

  • Eine klärende Rückfrage statt einer Sackgasse.
  • Eine sichere Alternative („Ich kann stattdessen die öffentlichen Infos zusammenfassen").
  • In Pipelines: an einen Menschen routen, wenn Vertrauen/Berechtigung niedrig sind.
Guided walkthrough1 of 4
  1. Prüfe die Antwort auf ein Refusal-Signal, bevor du sie renderst. Leite niemals eine ungeprüfte Antwort direkt in dein UI — so bekommen Nutzer eine leere Box oder ein rohes Objekt.

Prüfe dich selbst

0/3
  1. Dein Code bekommt eine Verweigerung von Claude zurück. Wie behandelst du sie richtig?
  2. Eine harmlose Anfrage wird immer wieder verweigert. Was probierst du zuerst?
  3. Warum ist es wichtig, ob du eine Modell-Verweigerung oder einen Classifier-/Safety-Block bekommen hast?
Key takeaways
  • Eine Verweigerung ist ein Ergebnis, kein Fehler — erkenne sie immer vor dem Rendern.
  • Modell-Verweigerung und Classifier-Block sind verschiedene Dinge; erkenne, was du bekommen hast.
  • Ungewollte Verweigerungen schrumpfen meist, wenn du legitimen Kontext ergänzt und präzise wirst.
  • Wenn eine Anfrage tatsächlich unzulässig ist, ist die Verweigerung korrekt — baue einen sauberen Ausweg, jailbreake nicht.
  • Fallbacks in Reihenfolge: klärende Rückfrage, sichere Alternative, Übergabe an einen Menschen.

Weiter​