Claude und Claude Code: Architektur, API und sicherer Agentenbetrieb

Claude bezeichnet eine Familie grosser generativer Sprachmodelle von Anthropic sowie mehrere Produkte, die diese Modelle verwenden. Die wichtigste administrative Unterscheidung lautet: Modell, API, Anwendung und Agentenlaufzeit sind nicht dasselbe System. Das Modell erzeugt aus Eingabetokens eine probabilistische Folge von Ausgabetokens. Die Messages API verpackt diesen Vorgang als HTTPS-Vertrag. Claude-Anwendungen ergänzen Konten, Gesprächsspeicher und Benutzeroberflächen. Claude Code fügt auf einem Endpoint eine lokale Laufzeit mit Datei-, Shell- und Werkzeugzugriff hinzu.

Die erste Claude-Version wurde 2023 als Chat- und API-Dienst vorgestellt (Introducing Claude). Anthropic beschreibt Claude als auf hilfreiches, ehrliches und harmloses Verhalten ausgerichteten Assistenten. Diese Ausrichtung, ein grosses Kontextfenster oder ein überzeugend formulierter Text sind aber keine Beweise für faktische Richtigkeit, Autorisierung oder sichere Ausführung. Ein Produktionssystem muss Modellantworten als nicht vertrauenswürdige, schema- und policygeprüfte Eingabe behandeln.

Die Erklärung beginnt bei einer Anfrage an das Modell und folgt der Antwort über Messages API, Content Blocks und Tool-Aufrufe. Erst wenn dieser Ablauf klar ist, werden Claude Code, MCP, Berechtigungen, Prompt Injection, Betrieb und Recovery vertieft.

Claude ist kein autonom handelndes Betriebssystem, sondern ein Inferenzdienst. Die umgebende Anwendung liefert Kontext, prüft Antworten, führt genehmigte Werkzeuge aus und trägt die Verantwortung für Identitäten, Datenzugriff und Audit.

Architekturansatz: Inferenzdienst plus kontrollierende Anwendung

Claude läuft im Normalfall als externer Inferenzdienst. Ein Client sendet Systeminstruktionen, Gesprächsnachrichten, Content Blocks, Werkzeugdefinitionen und Generierungsparameter. Der Dienst authentisiert und limitiert die Anfrage, tokenisiert den Kontext, führt Inferenz aus und liefert eine Message oder einen Ereignisstrom. Die Anwendung entscheidet danach, ob Text angezeigt, JSON validiert, ein Tool ausgeführt, ein Resultat zurückgesendet oder der Lauf abgebrochen wird.

Die direkte API ist nicht der einzige Bereitstellungspfad. Claude-Modelle werden auch über Cloudplattformen angeboten; Identität, Endpoint, Regionen, Quoten, Logging und Vertragsbedingungen unterscheiden sich dort. Die Anwendungsarchitektur hält Provideradapter und fachlichen Workflow getrennt. Ein Modellwechsel ist keine einfache DNS-Umschaltung, wenn Tooltypen, Context Limits, Stop Reasons oder Providerfeatures abweichen.

Modellschicht und probabilistische Semantik

Claude-Modelle verarbeiten Text, Code und je nach Modell weitere Modalitäten. Die Modellübersicht dokumentiert Modellfamilien, Kontextfenster und Fähigkeiten. Solche Werte gehören nicht als dauerhaft eingefrorener Fakt in einen statischen Artikel. Ein Client fragt vor Rollout über die Models API beziehungsweise zum Buildzeitpunkt die dokumentierten Fähigkeiten ab und speichert den tatsächlich verwendeten Modellbezeichner mit jedem Ergebnis.

Ein Sprachmodell ist keine Datenbank und keine Rules Engine. Gleiche Eingaben können je nach Sampling, Systemkontext, Modellrevision und Toolresultaten unterschiedliche Ausgaben erzeugen. Selbst bei niedriger Temperatur bleiben folgende Eigenschaften:

• Fakten können fehlen, veraltet oder erfunden sein.
• Instruktionen können mehrdeutig gewichtet werden.
• lange Kontexte können relevante Details überdecken.
• strukturähnlicher Text ist ohne Schemaabschluss kein gültiges Objekt.
• eine plausible Erklärung beweist nicht, dass ein Tool tatsächlich ausgeführt wurde.
• ein Modell kennt keine Berechtigung ausser den Informationen und Werkzeuggrenzen, die die Anwendung durchsetzt.

Die technische Abnahme verwendet daher Evaluationsfälle, erwartete Schemas, deterministische Nachprüfungen und fachliche Quellen. Ein erfolgreicher Modellbenchmark ersetzt keine anwendungsspezifische Messung von Genauigkeit, Latenz, Kosten und Schaden bei Fehlern.

Training, Constitution und Zuständigkeiten

Anthropic entwickelte Constitutional AI als Ergänzung zu überwachtem Lernen und Reinforcement Learning. Das Modell kritisiert und überarbeitet Antworten anhand expliziter Prinzipien; ein zweiter Trainingsschritt verwendet AI-generiertes Feedback. Anthropic erklärt diesen Ansatz und seine Grenzen in Claude’s Constitution. Die Claude-3-Modellkarte dokumentiert für eine konkrete Modellgeneration Training, Evaluation und Sicherheitsmassnahmen.

Für Admins ist diese Geschichte relevant, weil sie das Verhalten erklärt, nicht weil sie eine Laufzeitkontrolle ersetzt. Safety Training kann schädliche Antworten reduzieren, aber weder Mandantentrennung noch Toolautorisierung erzwingen. Refusals sind normale mögliche Modellausgaben. Die Anwendung muss sie als stop_reason beziehungsweise Content-Typ behandeln und darf nicht aus dem Fehlen einer Ablehnung ableiten, dass eine Aktion sicher ist.

Aus dem probabilistischen Modell wird erst durch die Messages API ein administrierbarer Dienst. Jede Anfrage übermittelt den benötigten Gesprächskontext erneut und erhält strukturierte Content Blocks als Antwort.

Messages API: zustandsloser Gesprächsvertrag

POST /v1/messages nimmt eine Liste von user- und assistant-Nachrichten entgegen und erzeugt den nächsten Assistant-Turn. Ein Systemprompt liegt im separaten Top-Level-Feld system; eine system-Rolle in messages existiert nicht. Content kann als String oder als Liste typisierter Blöcke gesendet werden (Create a Message).

Die API ist ohne zusätzlichen Threadspeicher zustandslos. Für einen Mehrturn-Dialog sendet der Client die benötigte Historie erneut. Das hat direkte Folgen:

1. Die Anwendung ist Eigentümerin von Conversation ID, Reihenfolge und Aufbewahrung.
2. Kürzen, Zusammenfassen oder Auslassen verändert den Modellkontext.
3. Systemprompt, Tooldefinitionen und Historie zählen zum Inputbudget.
4. Ein Provider-Request-ID ersetzt keine fachliche Job-ID.
5. Ein Retry derselben Anfrage kann eine neue Ausgabe und zusätzliche Kosten erzeugen.

Die fachliche Operation erhält daher eine eigene Korrelations- und Idempotenz-ID. Vor einem Retry prüft der Orchestrator, ob bereits ein Ergebnis oder eine irreversible Toolwirkung vorliegt.

Content Blocks und Stop Reasons

Eine erfolgreiche Antwort ist nicht zwingend ein einzelner Text. content ist eine geordnete Liste typisierter Blöcke, etwa Text, Tool Use, Thinking- oder Server-Tool-Blöcke. usage berichtet Tokenklassen. stop_reason beschreibt, warum die Generierung endete. Die offizielle Stop-Reason-Dokumentation unterscheidet unter anderem end_turn, max_tokens, stop_sequence, tool_use, pause_turn, refusal und model_context_window_exceeded.

Nur end_turn bedeutet einen natürlich abgeschlossenen Turn; es beweist keine fachliche Vollständigkeit. max_tokens und model_context_window_exceeded markieren potenziell abgeschnittene Daten. tool_use ist eine Aufforderung an den Orchestrator, kein ausgeführter Effekt. pause_turn verlangt eine protokollgerechte Fortsetzung. Neue Enumwerte können hinzukommen, weshalb Parser unbekannte Typen sichtbar ablehnen oder sicher ignorieren statt in einen Default-Erfolg zu fallen.

APIversion und Modellversion

Jede direkte API-Anfrage führt einen anthropic-version-Header. Diese APIversion stabilisiert Felder und Streamingsemantik, darf aber neue optionale Eingaben, Ausgabefelder oder Enumvarianten nicht verhindern (API versioning). Der Clientparser wird deshalb vorwärtskompatibel gebaut und protokolliert unbekannte Blöcke.

Davon getrennt ist die Modell-ID. Anthropic garantiert für eine gepinnte ID eine konstante Modellversion während ihrer Lebensdauer; Komfort-Aliase können andere Regeln besitzen (Model IDs and versioning). Für Audit und Reproduktion speichert ein System:

• APIversion und Betaheader,
• Modell-ID statt blossen Anzeigenamen,
• Systemprompt-/Policyversion,
• Toolset- und JSON-Schemaversion,
• Retrieval- und Dokumentversionen,
• Generierungsparameter,
• Request-, Job- und Benutzerkorrelation,
• Stop Reason, Usage und Validierungsergebnis.

$headers = @{
  'x-api-key' = $env:ANTHROPIC_API_KEY
  'anthropic-version' = '2023-06-01'
}
Invoke-RestMethod -Headers $headers -Uri 'https://api.anthropic.com/v1/models' |
  ConvertTo-Json -Depth 12

curl --fail --silent --show-error https://api.anthropic.com/v1/models \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H 'anthropic-version: 2023-06-01' | jq .

Invoke-RestMethod und ConvertTo-Json verarbeiten Windows; curl und jq Unix. Der Schlüssel stammt aus einem Secretspeicher und wird weder in die Kommandozeile geschrieben noch ausgegeben.

Tokenisierung, Kontext und Kosten

Kontextfenster werden in Tokens, nicht Zeichen oder Dateien gemessen. Toolschemas, Systemprompt, Nachrichten, Bilder, Dokumente und Toolresultate tragen zum Input bei; generierter Text und gegebenenfalls Thinking zum Output. Die Token Counting API nimmt dieselbe Eingabestruktur wie Messages an und liefert eine Vorabschätzung.

Ein grosser Kontext ist kein Archiv. Je mehr irrelevante Daten der Client mitsendet, desto höher werden Kosten, Latenz und Risiko widersprüchlicher Instruktionen. Produktionssysteme bauen deshalb eine Context Assembly Pipeline:

1. Benutzer- und Mandantenrechte vor Retrieval prüfen.
2. Dokumente anhand stabiler IDs und Versionen abrufen.
3. untrusted content als Daten, nicht als Systeminstruktion markieren.
4. Datenmenge, Dateitypen und Tokenbudget begrenzen.
5. Quellenmetadaten und Hashes mitgeben.
6. Antwort gegen dieselben Quellen und Schemas validieren.

Search-Result-Content-Blocks können RAG-Quellen mit Titel und Herkunft übermitteln, sodass Claude Zitate erzeugt (Search results). Diese Zitate sind nur so vertrauenswürdig wie Retrieval, Dokumentidentität und übergebene Metadaten.

Prompt Caching

Prompt Caching speichert wiederverwendbare Präfixe und reduziert Verarbeitungskosten und Latenz. Die Cachehierarchie folgt tools → system → messages; Änderungen an einem früheren Teil invalidieren ihn und die nachfolgenden Ebenen. Die offizielle Prompt-Caching-Dokumentation beschreibt automatische und explizite Breakpoints sowie kurze TTLs.

Ein Cache Hit beweist nur, dass ein identisches Präfix wiederverwendet wurde. Er garantiert weder aktuelle Quelldaten noch identische Ausgabe. Cachemetriken werden getrennt nach Creation und Read erfasst. Workspaces isolieren Prompt Caches auf der direkten Claude API (Workspaces). Geheimnisse gehören trotz kurzer TTL nicht in Prompts; Cache und Retention sind unterschiedliche Mechanismen.

Streaming mit Server-Sent Events

Mit stream: true liefert die API inkrementelle Server-Sent Events. Content Blocks werden begonnen, über Deltas erweitert und abgeschlossen; abschliessende Message- und Usageinformationen bleiben für korrekte Verarbeitung nötig. Die Streaming-Dokumentation beschreibt Eventtypen und SDK-Akkumulatoren.

Ein sichtbarer Textdelta ist kein Commit. Bei Verbindungsabbruch kann der Benutzer bereits Teiltext gesehen haben, während der Client keine vollständige Message besitzt. JSON- oder Toolargumente dürfen erst nach vollständigem Block und Schemavalidierung verwendet werden. Gateways und Proxies müssen lange HTTP-Verbindungen, Buffering, Timeouts und Backpressure korrekt behandeln.

$body = @{
  model = $env:CLAUDE_MODEL
  max_tokens = 256
  messages = @(@{ role = 'user'; content = 'Antworte mit einem Satz.' })
} | ConvertTo-Json -Depth 8
curl.exe --no-buffer --fail-with-body https://api.anthropic.com/v1/messages `
  -H "x-api-key: $env:ANTHROPIC_API_KEY" `
  -H 'anthropic-version: 2023-06-01' -H 'content-type: application/json' `
  --data-raw $body

jq -n --arg model "$CLAUDE_MODEL" '{
  model: $model, max_tokens: 256,
  messages: [{role: "user", content: "Antworte mit einem Satz."}]
}' | curl --no-buffer --fail-with-body https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H 'anthropic-version: 2023-06-01' -H 'content-type: application/json' \
  --data-binary @-

Der Beispielrequest verwendet absichtlich eine aus Konfiguration gelesene Modell-ID. Für SSE wird zusätzlich stream: true gesetzt und der benannte Eventstrom protokollgerecht geparst; blosses Zeilenlesen genügt für Produktionscode nicht.

Textausgabe verändert noch kein System. Erst Tool Use verbindet einen Modellvorschlag mit einer Aktion – und genau an dieser Stelle müssen Anwendung, Berechtigung und menschliche Freigabe greifen.

Tool Use: das Modell beantragt, die Anwendung handelt

Tool Use ist ein Vertrag zwischen Modell und Orchestrator. Die Anwendung beschreibt ein Tool mit Name, Zweck und JSON Schema. Claude kann daraufhin einen tool_use-Block mit Argumenten erzeugen. Der Client validiert Name und Eingabe, autorisiert den konkreten Aufruf, führt ihn aus und sendet einen tool_result-Block mit derselben Tool-Use-ID zurück. Erst ein weiterer Modellturn kann daraus eine Antwort bilden (How tool use works).

Die Toolübersicht trennt:

• Client Tools: Die eigene Anwendung führt aus.
• Anthropic-Schema-Tools: Anthropic definiert das Schema, der Client führt dennoch aus.
• Server Tools: Anthropic führt auf seiner Infrastruktur aus und liefert Resultatblöcke.
• MCP Connector: Die API verbindet sich mit einem entfernten MCP-Server.

Diese Unterscheidung bestimmt Netzwerkpfad, Geheimnisse, Logging, Datenschutz und Ausfallbereich. strict: true erzwingt Schemaübereinstimmung, nicht fachliche Richtigkeit oder Berechtigung. Ein syntaktisch gültiger Aufruf delete_user(id) kann weiterhin den falschen Benutzer löschen.

Produktionsfähige Toolschleife

Ein sicherer Orchestrator führt pro Tool Use folgende Schritte aus:

1. Toolname gegen allowlist und Workflowphase prüfen.
2. JSON Schema strikt validieren und unbekannte Felder ablehnen.
3. Benutzer-, Mandanten- und Objektberechtigung serverseitig neu prüfen.
4. Eingaben normalisieren; Pfade, URLs, IDs und Größen begrenzen.
5. Read, Write, External Message und Destructive Action klassifizieren.
6. bei hohem Risiko fachliche Freigabe oder Vieraugenprinzip verlangen.
7. mit kurzlebiger, minimaler Identität in isolierter Laufzeit ausführen.
8. Timeout, Outputlimit und Idempotenzschlüssel setzen.
9. Resultat von Secrets und untrusted instructions bereinigen.
10. Tool Use, Entscheidung, Effekt und Resultat unveränderbar auditieren.

Die Schleife begrenzt Turns, parallele Tools, kumulierte Kosten und wiederholte Fehler. Ein Toolresultat ist wiederum untrusted content. Eine Datenbankzeile oder Webseite kann Prompt Injection enthalten und darf nicht die Policy des Orchestrators überschreiben.

MCP als Protokollgrenze

Das Model Context Protocol standardisiert die Verbindung von AI-Anwendungen mit Tools, Ressourcen und Prompts. Anthropic beschreibt MCP als offenes Client-Server-Protokoll (MCP-Übersicht); die normative MCP-Spezifikation definiert Nachrichten und Fähigkeiten.

MCP macht Integrationen austauschbarer, aber nicht automatisch vertrauenswürdig. Ein Server kann Daten lesen, Aktionen auslösen, sehr grosse Resultate liefern oder Inhalte eines Drittanbieters zurückgeben. Aufnahme in eine Konfigurationsdatei ist deshalb eine Software- und Berechtigungsentscheidung. Inventarisiert werden Betreiber, Transport, Endpoint, Authentisierung, Tools, Ressourcen, Scopes, Datenklassen, Version, Timeout, Outputgrenze und Widerruf.

Der Messages-API-MCP-Connector ist ein Server-Tool auf Anthropic-Infrastruktur. Ein lokal in Claude Code gestarteter stdio-Server läuft dagegen auf dem Endpoint. Gleiches Protokoll, andere Datenwege und Ausfallbereiche.

Claude Code: lokale Agentenlaufzeit

Claude Code ist ein Agent für Terminal und Repository. Er sammelt Projektkontext, sendet ihn an einen Modellendpoint, interpretiert Modellvorschläge und verwendet lokale Tools zum Lesen, Ändern und Ausführen. Die offizielle Einrichtung dokumentiert Windows über WSL oder Git Bash sowie macOS und Linux. Die CLI-Referenz beschreibt interaktiven Betrieb, Print Mode, JSONausgabe, Sessionfortsetzung, Modellwahl und Toolregeln.

Der zentrale Vertrauensgrenze ist der lokale Prozess. Claude Code kann nur mit den Betriebssystemrechten und erreichbaren Credentials des gestarteten Benutzers handeln, aber diese Rechte können sehr weitreichend sein: Repository, SSH-Agent, Cloud-CLI, Paketregister, Kubernetes, Browser-Cookies, Umgebungsvariablen oder Production-Tunnel. «Der Agent hat gefragt» ist keine Isolation.

Die Claude-Code-Sicherheitsdokumentation beschreibt read-only Defaults, Permission Prompts, Projektgrenzen und Schutz gegen Prompt Injection. Sie hält zugleich fest, dass kein System vollständig immun ist. Nicht-interaktiver Betrieb benötigt strengere Policies, weil Repositoryinhalt, Issue-Text, Buildlogs und Toolausgaben Angreiferinstruktionen enthalten können.

Laufzeit- und Rechteprofil

Ein verwalteter Endpoint oder CI-Runner verwendet:

• ein dediziertes Benutzer- oder Workloadkonto,
• ein projektspezifisches Arbeitsverzeichnis,
• minimale Dateisystem- und Netzwerkrechte,
• kurzlebige, auf Ziel und Aktion begrenzte Credentials,
• erlaubte und verbotene Tools aus zentraler Policy,
• Container/VM/Sandbox für untrusted Builds,
• Secret Scanning vor Kontextaufnahme,
• begrenzte Turns, Zeit, Output und Kosten,
• Git-Diff, Tests und Freigabe vor Commit/Deploy,
• Session-, Tool- und Providerkorrelation im Auditlog.

Der Schalter --dangerously-skip-permissions ist keine Automatisierungsstrategie. Er entfernt eine Schutzschicht und ist nur in einer vorgelagerten Sandbox mit eigener Policy vertretbar.

Get-Command claude | Format-List Source,Version
claude doctor
Get-FileHash (Get-Command claude).Source -Algorithm SHA256
Get-ChildItem .\.claude -Force -Recurse | Select-Object FullName,Length

command -v claude
claude doctor
file "$(command -v claude)"
sha256sum "$(command -v claude)"
find ./.claude -maxdepth 3 -type f -printf '%p %s\n'

Get-Command, Get-FileHash und Get-ChildItem inventarisieren Windows. POSIX command, file, sha256sum und find übernehmen Unix. Ein Hash wird nur gegen eine vertrauenswürdige Release- oder Paketquelle bewertet.

Nicht-interaktiver und CI-Betrieb

Print Mode macht Claude Code skriptbar. --output-format json beziehungsweise stream-json liefert maschinenlesbare Ergebnisse; --max-turns begrenzt den Agentenlauf. Eingabedaten und Exitcode bleiben Teil des Jobprotokolls. Freitextausgabe wird nicht als Shellscript evaluiert.

Get-Content .\review-request.txt -Raw |
  claude -p --max-turns 3 --output-format json `
    --allowedTools 'Read' --disallowedTools 'Bash' 'Edit' |
  Tee-Object -FilePath .\claude-review.json |
  ConvertFrom-Json

cat ./review-request.txt |
  claude -p --max-turns 3 --output-format json \
    --allowedTools Read --disallowedTools Bash Edit |
  tee ./claude-review.json | jq .

Get-Content, Tee-Object und ConvertFrom-Json verarbeiten Windows. cat und tee übernehmen Unix. Ein CI-Job erhält darüber hinaus feste Working-Directory-, Netzwerk-, Secret- und Branchregeln.

Settings, Hooks und Policies

Claude Code kombiniert Benutzer-, Projekt- und verwaltete Einstellungen. Projektdateien können im Repository liegen und gehören damit zum Code Review. Hooks führen an definierten Lifecyclepunkten Befehle aus; sie sind ausführbarer Code, keine harmlose Promptkonfiguration. MCP-Server erweitern die erreichbaren Systeme. Eine Enterprisepolicy muss deshalb Settings, Hooks, Plugins, Skills, MCP und erlaubte Shellmuster gemeinsam kontrollieren.

Die CLI kann Berechtigungen einmalig oder dauerhaft erlauben. Breite Wildcards beschleunigen Arbeit, vergrössern aber den Blast Radius. Eine gute Regel erlaubt nicht «Bash», sondern eine begrenzte Lesefunktion oder ein vorgelagertes, typisiertes Tool. Für Schreiboperationen werden Zielpfad, Branch und Diff geprüft. Für Deployments oder externe Nachrichten bleibt eine separate Freigabe ausserhalb des Modells.

Identität, Organisation und Workspaces

Die Claude Platform ordnet Nutzung einer Organisation und Workspaces zu. Workspace-Schlüssel sind auf Ressourcen und Nutzung dieses Workspaces begrenzt; Mitglieder besitzen Workspace-Rollen. Separate Workspaces für Entwicklung, Test und Produktion trennen Schlüssel, Limits, Batches, Files und Prompt Caches (Workspaces).

Admin API und Inference API verwenden unterschiedliche Schlüsseltypen. Die Admin-API-Dokumentation beschreibt Mitglieder, Einladungen, Workspaces und API Keys. Ein Adminschlüssel gehört niemals in eine Anwendung, die nur Messages senden muss. Offboarding widerruft Benutzerzugriff, persönliche Claude-Code-Schlüssel und gegebenenfalls separat erstellte Servicekeys.

Claude Code kann über Console/OAuth, Claude-Pläne oder Enterpriseprovider authentisiert werden. Entscheidend ist die tatsächliche Billing- und Datenroute der Sitzung. Persönliche Accounts in einem Unternehmensrepository umgehen sonst Workspacekontrollen, Retention, Kostenstellen oder Audit.

Rate Limits, Spend und Backpressure

Anthropic unterscheidet Spend Limits und Rate Limits. Messages werden nach Requests per Minute, Input Tokens per Minute und Output Tokens per Minute begrenzt. Die Limits verwenden Token Buckets; kurze Bursts können daher trotz scheinbar passendem Minutenmittel 429 auslösen. retry-after und Responseheader liefern den Backoffrahmen (Rate limits).

Ein Gateway implementiert:

• Queue und Priorität pro Mandant/Workflow,
• Tokenzählung vor Annahme grosser Jobs,
• exponentiellen Backoff mit Jitter und retry-after,
• globale und workspacebezogene Parallelitätsgrenzen,
• Circuit Breaker bei 5xx und Netzwerkfehlern,
• Budgetwarnung und harte Kostenobergrenze,
• getrennte Metriken für Cache Read, Cache Write, Input und Output,
• kontrolliertes Fallback mit dokumentierter Qualitätsänderung.

Die API-Fehlerdokumentation unterscheidet 400, 401, 402, 403, 404, 413, 429, 500 und 529 und liefert request_id. SDKs wiederholen bestimmte transiente Fehler automatisch. Diese Retries werden bei Kapazitäts- und Kostenplanung mitgerechnet.

Batches und asynchrone Verarbeitung

Die Message Batches API verarbeitet viele unabhängige Requests asynchron. Batches sind workspacegebunden; Einzelresultate können erfolgreich oder fehlgeschlagen sein. Ergebnisverfügbarkeit und serverseitige Aufbewahrung unterscheiden sich vom synchronen Pfad. Die Batch-Dokumentation nennt Grössen-, Laufzeit- und Abrufgrenzen.

Ein Batchjob besitzt ein custom_id pro Fachobjekt, ein Eingabemanifest, einen Abholcursor und eine Resultatprüfung. «Batch completed» bedeutet nur, dass alle Einträge einen Endzustand besitzen. Der Import verarbeitet jedes Ergebnis idempotent, erkennt fehlende IDs und archiviert Modell-, Prompt- und Schemaversion. Für personenbezogene oder regulierte Daten wird geprüft, ob der Batchpfad überhaupt unter Vertrag und Datenhaltungsmodell zulässig ist.

Nach Funktion und Skalierung folgt die Datenfrage: Welche Inhalte verlassen das eigene System, wie lange werden sie gehalten und welche zusätzlichen Betreiber sind bei Cloudplattformen beteiligt?

Datenhaltung, Privacy und Drittplattformen

Datenhaltung hängt von Oberfläche und Vertrag ab. Anthropic beschreibt für kommerzielle API-Nutzung eine Standardlöschung von Inputs und Outputs innerhalb von 30 Tagen, nennt aber Ausnahmen für länger speichernde Features, abweichende Vereinbarungen, Safety Enforcement und rechtliche Pflichten (Aufbewahrung kommerzieller Daten). Claude-Anwendungen speichern Gespräche für Produktfunktionen nach eigenen Regeln.

Zero Data Retention ist keine globale Schaltfläche für jedes Produkt. Die ZDR-Dokumentation beschreibt berechtigte APIs, Organisationen und Ausnahmen. Bei Cloudproviderzugriff gelten zusätzlich dessen Datenweg, Regionen, Schlüsselverwaltung und Vertrag. MCP, Web Search oder externe Tools können Daten an weitere Verantwortliche übertragen.

Vor Produktionsfreigabe wird eine Datenflussmatrix erstellt:

Prompt Injection und untrusted content

Prompt Injection entsteht, wenn Daten versuchen, Instruktionen zu werden. Angriffsflächen sind Webseiten, E-Mails, Dokumente, Issues, Quellcodekommentare, MCP-Ressourcen, Toolresultate und Terminaloutput. Der Angriff muss das Modell nicht «überzeugen», wenn die Anwendung einem ungeprüften Tool Use ohnehin weitreichende Rechte gibt.

Verteidigung ist mehrschichtig:

1. Systempolicy und Berechtigung ausserhalb des Modelltexts erzwingen.
2. Retrieval nach Benutzer- und Mandantenrechten filtern.
3. Datenblöcke mit Herkunft, Trust Level und Zweck markieren.
4. Tools minimal, typisiert und objektbezogen autorisieren.
5. Schreib-, Versand-, Zahlungs- und Löschaktionen separat freigeben.
6. Netzwerk und Dateisystem der Ausführung sandboxen.
7. Secrets nicht in Kontext, Toolresultat oder sichtbare Logs geben.
8. Output und Toolargumente gegen Schema und Fachregeln validieren.
9. Agentenschleifen nach Zeit, Turns, Kosten und Effekten begrenzen.
10. adversariale Tests mit indirekter Injection in echten Datenpfaden durchführen.

Ein Human-in-the-Loop ist nur wirksam, wenn die Person Ziel, Effekt und relevante Daten sieht. Eine generische «Erlauben?»-Meldung führt zu Approval Fatigue. Hochriskante Aktionen zeigen normalisierte Parameter und werden durch einen unabhängigen Policy Enforcement Point geprüft.

Netzwerkpfad und Proxybetrieb

Claude API und Claude Code benötigen HTTPS-Zugriff. Ein Unternehmensproxy kann Authentisierung, TLS Inspection, Egresskontrolle und Logging übernehmen, wird damit aber Teil der Vertraulichkeits- und Verfügbarkeitskette. Die Proxy-Dokumentation für Claude Code nennt unterstützte Proxyvariablen, CA-Bundles und benötigte Ziele.

Resolve-DnsName api.anthropic.com
Test-NetConnection api.anthropic.com -Port 443
curl.exe -sS -D - -o NUL https://api.anthropic.com/v1/models
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 443

dig +short api.anthropic.com A api.anthropic.com AAAA
curl -sS -D - -o /dev/null https://api.anthropic.com/v1/models
ss -ntp state established '( dport = :443 )'
openssl s_client -connect api.anthropic.com:443 -servername api.anthropic.com -brief

Resolve-DnsName, Test-NetConnection und Get-NetTCPConnection prüfen Windows. dig, ss und openssl s_client prüfen Unix. Ein 401 ohne Key bestätigt, dass DNS, TCP, TLS und HTTP den erwarteten APIpfad erreichen; es ist kein erfolgreicher Inferenztest.

Ein sicherer Agentenbetrieb muss nicht nur Modellaufrufe zählen, sondern den vollständigen Weg von Eingabe über Toolentscheidung bis zur externen Wirkung nachvollziehbar machen.

Observability und Audit

Ein produktiver Request erzeugt fachliche, technische und Kostenmetriken. Mindestens erfasst werden:

• Zeit, Workspace, Anwendung, Workflow und pseudonyme Benutzerkorrelation,
• Modell-ID, APIversion, Prompt-/Toolset-/Schemaversion,
• Latenz bis Header, erstes Token und vollständige Message,
• Input-, Cache-Creation-, Cache-Read- und Outputtokens,
• Stop Reason, Content-Block-Typen und Validierungsstatus,
• Fehlerklasse, Retryanzahl, request_id und retry-after,
• Toolname, Autorisierungsentscheidung, Dauer, Effekt und Resultatklasse,
• geschätzte und abgerechnete Kosten,
• Redaction- und Aufbewahrungsklasse.

Prompts und Modellantworten werden nicht reflexartig vollständig geloggt. Sie können personenbezogene Daten, Secrets, Quellcode oder Angreiferpayloads enthalten. Auditmetadaten und Debuginhalt erhalten getrennte Speicher, Rollen und Löschfristen. Die Usage Report API stellt aggregierbare API- und Claude-Code-Nutzungsdaten bereit; lokale Toolwirkungen müssen dennoch im eigenen System auditiert werden.

Fehlerbehandlung und Wiederanlauf

Ein Modellrequest ist nicht automatisch idempotent. Bei Timeout kann der Provider die Generierung abgeschlossen haben, obwohl der Client keine Antwort erhielt. Bei Tool Use kann der externe Effekt bereits eingetreten sein. Der Orchestrator speichert deshalb Zustandsübergänge:

accepted → context_built → request_sent → response_received → validated → tool_authorized → tool_executed → result_returned → completed

Für jeden Übergang existieren Korrelations-ID, Zeit, Versionen und Checkpoint. Ein Retry vor tool_executed kann den Modellturn wiederholen; ein Retry danach fragt zuerst den fachlichen Effekt ab. Externe Tools unterstützen Idempotency Keys oder einen Read-after-Write-Nachweis. Bei unbekanntem Zustand wird eskaliert, nicht blind erneut ausgeführt.

Fallbackmodelle verändern Qualität, Kosten, Context Limit und Toolverhalten. Sie sind ein getesteter eigener Pfad. Die Anwendung verbirgt einen Fallback nicht, wenn er die Aussagekraft oder Compliance verändert.

Backup und Recovery

Das Modell selbst wird als externer Dienst nicht vom Kunden gesichert. Wiederherstellbar sein müssen die eigenen Kontroll- und gespeicherte Daten und Konfigurationen:

• Systemprompts, Policies und Evaluationssätze,
• Toolschemas, Implementierungen und Berechtigungsregeln,
• MCP-Inventar und freigegebene Serverversionen,
• Workspace- und Schlüsselprovisionierung als Code oder Runbook,
• Retrievalquellen, Embeddings/Indizes und Dokumentversionen,
• Conversation-/Jobstatus und Idempotenzdaten,
• Redaction-, Audit- und Kostenmetadaten,
• Claude-Code-Projektsettings, Hooks und geprüfte Skills,
• Provideradapter und getestete Modellmigrationen.

API Keys werden nicht aus Backups «wiederhergestellt», sondern widerrufen und neu provisioniert. Ein Disaster-Recovery-Test baut eine neue Laufzeit auf, weist minimale Identitäten zu, sendet einen bekannten Testfall, validiert Schema und Quellen, führt ein harmloses Testtool aus und korreliert Provider-, Gateway- und Toollogs. Grundlagen stehen unter Backup und Disaster Recovery, APIs, Härtung und Troubleshooting.

Technische Geschichte

Anthropic entstand 2021 als Forschungs- und Produktunternehmen für sichere AI-Systeme. Claude wurde im März 2023 nach einer geschlossenen Partnerphase als Chat- und API-Assistent vorgestellt (Introducing Claude). Claude 2 erweiterte im Juli 2023 Kontext und öffentliche Verfügbarkeit (Claude 2).

2024 etablierte die Claude-3-Familie die Bezeichnungen Haiku, Sonnet und Opus als Abstufungen von Geschwindigkeit, Kosten und Leistungsfähigkeit (Claude 3). Diese Produktnamen sind keine stabile Capabilityprüfung; Anwendungen binden gepinnte IDs und fragen Limits separat ab.

Im Februar 2025 erschien Claude Code als Research Preview zusammen mit einem Hybrid-Reasoning-Modell (Claude 3.7 und Claude Code). Im Mai 2025 wurde Claude Code allgemein verfügbar; zugleich ergänzte Anthropic die API um agentenorientierte Bausteine wie Code Execution, MCP Connector und längeres Prompt Caching (Claude 4). Damit verschob sich die Betriebsfrage von «Wie konsumiere ich Text?» zu «Welche Daten und Wirkungen darf eine probabilistische Planungsschicht erreichen?»

Die Plattform entwickelte danach stärkere Modellversionierung, Workspaces, Usage-/Cost-APIs, Toolschemas, Caching, Batches und Agenten-SDKs. Der dauerhafte Architekturpunkt bleibt: Das Modell schlägt vor; APIs und Agentenrahmen transportieren; die kontrollierende Anwendung autorisiert, führt aus, validiert und auditiert.

Admin-Checkliste

Die vielen Oberflächen von Claude werden beherrschbar, wenn Modell, API, Werkzeug und lokaler Prozess getrennt erfasst werden. Die Checkliste fasst die Kontrollen zusammen, die vor einem produktiven Einsatz belegt sein sollten.

• Schichten: Modell, API, Claude-Anwendung, Gateway, Tool und Claude-Code-Endpoint getrennt inventarisieren.
• Verträge: APIversion, gepinnte Modell-ID, Content Blocks, Stop Reasons und unbekannte Typen behandeln.
• Kontext: Daten minimieren, Retrieval autorisieren, Tokens zählen und Quellen versionieren.
• Tools: Schema, Fachberechtigung, Idempotenz, Timeout, Outputlimit und Audit erzwingen.
• MCP: Serverherkunft, Transport, Scopes, Datenklassen und Prompt-Injection-Risiko prüfen.
• Claude Code: Benutzerrechte, Secrets, Netzwerk, Sandbox, Settings, Hooks und Toolpolicy begrenzen.
• Identität: Organisation, Workspace, Benutzer-, API- und Adminschlüssel sauber trennen.
• Kapazität: RPM, ITPM, OTPM, Spend, Cache und Retrykosten beobachten.
• Privacy: Produktoberfläche, Provider, Retention, ZDR, Dritttools und Logs einzeln bewerten.
• Qualität: Evals, Schema- und Quellenprüfung sowie fachliche Freigabe vor Wirkung einsetzen.
• Recovery: Prompts, Policies, Tools, Retrieval, Jobs und Provisionierung reproduzierbar halten.
• Nachweis: einen vollständigen Test von Authentisierung über Message und Tool bis Audit und Kostenbericht ausführen.