Deine Managed-Agents-Bereitstellung absichern

Dieser Leitfaden listet die Einstellungen auf, die begrenzen, was ein Agent auf Claude Managed Agents erreichen und tun kann, die wichtigsten zuerst. Jeder Abschnitt verlinkt auf die Seite, die die jeweilige Einstellung vollständig behandelt.

Sicherheitsrisiken und Sandbox-Grenzen erklärt, warum diese Einstellungen wichtig sind und wovor sie nicht schützen. Informationen zum Prüfen und Überwachen von Sessions findest du unter Agent-Sessions überprüfen und überwachen.

Wählen, wo der Agent läuft

Wo die Tools des Agenten laufen, entscheidet darüber, wer die „sandbox“ (isolierte Ausführungsumgebung) absichert: Anthropic bei einer Cloud-Umgebung oder du bei einer selbst gehosteten Sandbox. Wie du zwischen beiden wählst und was jeweils an Anthropic gelangt, erfährst du unter Eine Agent-Umgebung auswählen.

Wenn du eine selbst gehostete Sandbox verwendest, beachte diese vier Punkte:

• Netzwerk: Das Netzwerk begrenzen gilt für Cloud-Umgebungen. Lege für eine selbst gehostete Sandbox die entsprechenden Limits für ihren Datenverkehr in deiner eigenen Firewall fest. Deine Firewall begrenzt nicht die MCP-Server, die ein Agent deklariert, also prüfe diese sowie alle, die deine Anwendung für eine Session festlegt.
• Web-Tools: Die Web-Tools laufen auf den Servern von Anthropic, daher begrenzt deine Firewall sie nicht. Begrenze sie mit ihren Domainlisten. Siehe Websuche und Web-Fetch einschränken.
• Anmeldedaten: Umgebungsvariablen-Credentials werden bei selbst gehosteten Sandboxes noch nicht unterstützt.
• Isolation und Härtung: Du bist für beides verantwortlich. Siehe das Sicherheitsmodell.

Keine der beiden Optionen ändert die Compliance-Abdeckung von Managed Agents oder wie lange der Session-Verlauf aufbewahrt wird. Siehe Sessions überwachen und Aufbewahrung überprüfen.

Das Netzwerk begrenzen

Setze networking.type auf limited und liste in allowed_hosts nur die Hosts auf, die der Agent benötigt. Eine Anfrage zum Erstellen einer Umgebung, die networking weglässt, erhält möglicherweise unrestricted, also setze networking in jeder Erstellungsanfrage. Siehe Risiken von uneingeschränktem Networking.

Dateien, Memory Stores und GitHub-Repositories, die du anhängst, bleiben für den Agenten unabhängig von allowed_hosts verfügbar.

Die Beispiele auf dieser Seite verwenden einen Support-Agenten. Er liest das Ticket eines Kunden, schlägt die Bestellung nach, liest dein Hilfe-Center und entwirft eine Antwort. Deine Anwendung führt die Bestellabfrage aus, die keinen Host benötigt, daher erlaubt diese Umgebung einen Host, das Hilfe-Center, für web_fetch:

ant apply environment.yaml

# yaml-language-server: $schema=https://platform.claude.com/schemas/ant/beta/environment.json
name: support-agent
config:
  type: cloud
  networking:
    type: limited
    allowed_hosts:
      - help.example.com

Eine limited-Umgebung hat drei Networking-Einstellungen:

Die Einstellungen allow_package_managers und allow_mcp_servers fügen keine Hosts für Websuche und Web-Fetch hinzu.

Lass allow_mcp_servers deaktiviert, was der Standard ist, und liste den Host jedes MCP-Servers, den du betreibst oder dem du vertraust, in allowed_hosts auf. Jeder Host, den du auflistest, ist auch für Code in der Sandbox offen. Bei deaktiviertem allow_mcp_servers lehnt eine Prüfung bei der Session-Erstellung die Anfrage ab, wenn der Host eines MCP-Servers nicht aufgelistet ist. Siehe Authentifizierung bei der Session-Erstellung bereitstellen. Dieselbe Prüfung läuft, wenn ein Session-Update mcp_servers ändert.

Wenn du Hosts für allowed_hosts auswählst, befolge diese zwei Regeln:

• Liste nur Hosts auf, die du betreibst oder denen du vertraust.
• Vermeide *.-Wildcards und Shared-Hosting-Domains, auf denen jeder Inhalte veröffentlichen kann.

Wenn der Agent bash behält, lege die Berechtigungsrichtlinie des bash-Tools so fest, wie es Riskante Aktionen genehmigen beschreibt.

Alle Networking-Einstellungen findest du unter Einrichtung der Cloud-Umgebung.

Anmeldedaten in Vaults aufbewahren

Speichere jedes Secret in einem „vault“ (Tresor). Lege für jedes Umgebungsvariablen-Credential den Injektionsort auf ausschließlich Request-Header fest und liste nur die Hosts auf, für die das Secret bestimmt ist. Code in der Sandbox sieht einen Platzhalter statt des Secrets. Managed Agents setzt das echte Secret nur in ausgehende HTTPS-Anfragen an die Hosts ein, die das Credential erlaubt. So bleibt das Secret außerhalb der direkten Reichweite des Modells, es sei denn, ein Dienst sendet es zurück, etwa ein Endpunkt, der Request-Header zurückgibt. Wenn das networking des Credentials unrestricted ist, setzt Managed Agents das echte Secret in Anfragen an jeden Host ein, den die Umgebung die Sandbox erreichen lässt. Um einen Vault zu verwenden, übergib seine ID in vault_ids, wenn du die Session oder das Deployment erstellst.

Der Support-Agent benötigt kein Vault-Credential, da deine Anwendung den API-Key für deine Bestell-API hält. Wenn dein Agent ein Vault-Credential hält, findest du die Anfrage in jeder Sprache unter Ein Credential hinzufügen.

Halte Schlüssel aus System-Prompts, Agentendefinitionen und Nachrichten heraus. Gib dem Agenten keinen Claude-API-Key. Selbst wenn sich ein Claude-API-Key in einem Vault befindet, kann Code in der Sandbox ihn verwenden, um die Claude API direkt aufzurufen. Er kann alles tun, was dieser Schlüssel erlaubt, etwa Sessions starten oder löschen oder Websuche und Web-Fetch verwenden. Die Tool-Einstellungen, Genehmigungen und das Budget des Agenten gelten für diese Aufrufe nicht. In einer limited-Umgebung kann Code diese Aufrufe nur tätigen, wenn allowed_hosts die Sandbox api.anthropic.com erreichen lässt.

Rufe Tokens selbst ab und speichere sie im Vault, denn ein Token, das Code in der Sandbox mit einem gespeicherten Secret abruft, kommt ungeschwärzt zurück.

Bewahre Vaults für Workloads mit unterschiedlichen Vertrauensstufen in separaten Workspaces auf, da jeder API-Key mit Zugriff auf einen Workspace dessen Vaults referenzieren kann. Verwende API-Keys, die auf einen Workspace beschränkt sind.

Informationen zu MCP-Credentials und Rotation findest du unter Mit Vaults authentifizieren.

Websuche und Web-Fetch einschränken

Setze allowed_domains bei web_fetch auf die Websites, die der Agent benötigt. Jede URL, die der Agent abruft, kann Daten an die Website übertragen, auf die sie verweist, daher ist diese Liste eine Sicherheitskontrolle. Setze bei web_search allowed_domains auf die Websites, von denen du Ergebnisse möchtest, sodass Ergebnisse nur von Websites stammen, deren Genauigkeit du vertraust. Die Liste verhindert nicht, dass die Suchanfrage den Suchanbieter erreicht. Suchergebnisse enthalten Text von Seiten, daher begrenzt die Liste auch, von welchen Websites Text den Agenten erreicht. Setze allowed_domains bei beiden Tools für jeden Umgebungstyp.

Eine blocked_domains-Liste blockiert die Hosts, die du auflistest, und deren Subdomains, und keinen anderen Host. Derselbe Inhalt kann den Agenten weiterhin über Webarchive, Caches, Mirrors oder verwandte Domains erreichen, die du nicht aufgelistet hast. Verlasse dich für die Sicherheit nicht auf blocked_domains. Verwende allowed_domains und benenne die Hosts, denen du vertraust.

In einer limited-Umgebung begrenzt die allowed_hosts-Liste aus Das Netzwerk begrenzen auch die Web-Tools. Eine unrestricted-Umgebung oder eine selbst gehostete Sandbox begrenzt die Web-Tools nicht.

Die beiden Listen gleichen Hosts unterschiedlich ab:

Wenn der Agent eine Website und alle ihre Subdomains benötigt, liste sowohl example.com als auch *.example.com in allowed_hosts auf, und liste andernfalls exakte Hosts auf. Wenn ein Tool example.com auflistet und allowed_hosts nur *.example.com auflistet, wird die Session erstellt. Die Prüfung bei der Session-Erstellung zählt example.com als innerhalb von *.example.com, aber das Tool gibt nichts von example.com selbst zurück. Wie die beiden Listen abgleichen, erfährst du unter Domainlisten für einen Agenten festlegen.

Das web_fetch-Tool öffnet außerdem nur URLs, die bereits in der Session aufgetaucht sind:

In einer Multiagenten-Session öffnet web_fetch eine URL von einem anderen Agenten nur, wenn sie diesen Agenten über eine mit Ja markierte Quelle erreicht hat. Das Ergebnis eines benutzerdefinierten Tools aus einem direkten Aufruf zählt als mit Ja markierte Quelle. Das gilt auch, wenn Claude dessen Text geschrieben hat, zum Beispiel wenn das Tool seine Eingabe wiederholt. Eine URL kann auch dann zählen, wenn sie ohne https:// geschrieben ist, etwa example.com/docs. Das web_fetch-Tool kann einen Link, der Wörter statt seiner URL anzeigt, wie „Support kontaktieren“, nicht immer öffnen. Wenn der Agent eine URL abrufen muss, die nicht in der Session aufgetaucht ist, sende sie in einer Benutzernachricht.

Diese Regel verringert die Wahrscheinlichkeit, dass eingeschleuster Text eine URL erstellt, die private Daten überträgt. Endbenutzertext, Suchergebnisse, abgerufene Seiten und Ergebnisse benutzerdefinierter Tools können weiterhin URLs hinzufügen, also lass allowed_domains gesetzt. Die Messages API wendet eine ähnliche Regel mit einer anderen Liste von Quellen an. Siehe URL-Validierung.

Eine Domainliste bei web_fetch begrenzt das bash-Tool nicht. Das Netzwerk begrenzen ebenfalls. Siehe Regeln für Domainlisten.

Riskante Aktionen genehmigen

Setze auto bei bash, write, edit und web_fetch sowie bei MCP-Tools, die nur Daten lesen. Verwende stattdessen always_ask bei einem Tool, wenn du seine Änderungen außerhalb der Sandbox nicht rückgängig machen kannst. Verwende es auch bei einem Tool, das nicht allein deshalb ausgeführt werden soll, weil von dir weitergeleiteter Endbenutzertext danach verlangt. Eine Berechtigungsrichtlinie bestimmt, ob ein Tool-Aufruf ausgeführt wird, auf deine Genehmigung wartet oder vom Server bewertet wird.

Das Toolset in Dem Agenten den kleinsten Tool-Satz geben wendet diese Richtlinien an.

Die auto-Richtlinie lässt den Server einen Aufruf ausführen, ablehnen oder für eine Genehmigung pausieren. Eine Person kann nicht jeden Aufruf in einer langen Ausführung genehmigen, daher prüft stattdessen der Server jeden einzelnen. Kombiniere auto mit eingeschränktem Networking, einem Schlüssel mit eng gefassten Berechtigungen, einem Budget und einer Benachrichtigung bei Sessions im Leerlauf. auto ist kein menschlicher Kontrollpunkt. Wenn also eine Person die Aufrufe eines Tools prüfen muss, bevor sie ausgeführt werden, konfiguriere always_ask bei diesem Tool.

auto behandelt Text in user.message-Events und die Beschreibung in einem user.define_outcome-Event als deine Anweisung, einschließlich Endbenutzertext, den du weiterleitest.

Eine pausierte Session wartet unbegrenzt, daher benötigt eine unbeaufsichtigte Session einen Client, der pausierte Aufrufe beantwortet oder die Session unterbricht.

Prüfe jeden pausierten Aufruf, bevor du ihn erlaubst. Ein Client, der jeden Aufruf erlaubt, ohne ihn einer Person zu zeigen, ist dasselbe wie always_allow. Siehe Auf Bestätigungsanfragen antworten und Sehen, wie jeder Aufruf bewertet wurde.

Dem Agenten den kleinsten Tool-Satz geben

Setze default_config.enabled auf false und aktiviere nur die Tools, die der Agent benötigt. Das Agent-Toolset aktiviert standardmäßig alle acht integrierten Tools.

Der Support-Agent benötigt drei integrierte Tools: read und write für seinen Entwurf und web_fetch für das Hilfe-Center. Er schlägt Bestellungen über ein benutzerdefiniertes Tool, lookup_order, nach, das deine Anwendung ausführt. Deine Anwendung hält den API-Key für deine Bestell-API, daher benötigt der Agent weder bash noch Anmeldedaten.

Das folgende Beispiel begrenzt web_fetch mit allowed_domains auf help.example.com. Es setzt auto bei write und web_fetch, wie es Riskante Aktionen genehmigen empfiehlt. Wenn das Ticket eines Kunden den Agenten dazu bringt, diese Tools zu verwenden, kann der Agent nur Dateien in der Sandbox ändern oder Seiten des Hilfe-Centers öffnen. Deshalb benötigt keines der beiden Tools always_ask. Das Beispiel setzt außerdem always_ask in default_config, sodass ein Tool, das du später ohne eigene Richtlinie aktivierst, always_ask verwendet:

ant apply agent.md

---
name: Support Agent
model: claude-opus-5-5
tools:
  - type: agent_toolset_20260401
    default_config:
      enabled: false
      permission_policy:
        type: always_ask
    configs:
      - name: read
        enabled: true
        permission_policy:
          type: always_allow
      - name: write
        enabled: true
        permission_policy:
          type: auto
      - name: web_fetch
        enabled: true
        allowed_domains: [help.example.com]
        permission_policy:
          type: auto
  - type: custom
    name: lookup_order
    description: Look up one order by its ID. Returns the status, the items, and the delivery date.
    input_schema:
      type: object
      properties:
        order_id:
          type: string
          description: The order ID from the ticket
      required:
        - order_id
---

Ein Agent-Update ersetzt das gesamte tools-Array, also sende jeden Eintrag, den du behalten möchtest.

Ein Agent-Update erreicht nur neue Sessions, also prüfe auch Deployments, Agenten, die diesen Agenten auflisten, und bestehende Sessions:

• Ein Deployment fixiert eine Agentenversion, also richte jedes Deployment auf die neue aus.
• Ein Agent, der diesen in subagents.predefined_agents oder workflows.predefined_agents auflistet, behält die Version, die er fixiert hat, also aktualisiere auch diesen Agenten.
• Um eine bereits bestehende Session stärker einzuschränken, aktualisiere die Tools dieser Session. Die Session muss idle sein, und das Update ersetzt das gesamte tools-Array. In einer Multiagenten-Session gelten neue allowed_domains- und blocked_domains-Listen bei den Web-Tools des Agenten, den die Session ausführt, auch für jeden anderen Agenten. Sie gelten ab dem nächsten Turn jedes Agenten. Die aktivierten Tools und Berechtigungsrichtlinien dieser Agenten ändern sich nicht. Um diese zu ändern, aktualisiere jeden Agenten und starte dann eine neue Session.

Begrenze auch MCP-Server und benutzerdefinierte Tools auf das, was der Agent benötigt:

• MCP-Server: Ein MCP-Toolset aktiviert standardmäßig jedes Tool, das der Server bereitstellt. Setze default_config.enabled auf false und aktiviere benannte Tools, sodass Tools, die ein Server später hinzufügt, deaktiviert bleiben. Entferne Server, die der Agent nicht verwendet. Siehe MCP-Connector.
• Benutzerdefinierte Tools: Deine Anwendung führt sie aus, und Berechtigungsrichtlinien gelten nicht. Validiere die Eingabe jedes Aufrufs in deiner Anwendung und begrenze, worauf das Tool zugreifen kann.

Nicht vertrauenswürdige Eingaben von mächtigen Tools fernhalten

Prüfe, welche Tools und Anmeldedaten ein Agent besitzt, wann immer er nicht vertrauenswürdige Eingaben liest, also Text, den jemand außerhalb deines Teams schreiben kann. Dieser Abschnitt verwendet zwei Begriffe:

• Nicht vertrauenswürdige Eingaben: Webseiten, Suchergebnisse, Support-Tickets, E-Mails, Repository-Dateien, Uploads, MCP-Server-Ergebnisse und Endbenutzernachrichten, die du weiterleitest.
• Mächtige Tools: bash, write, edit, web_fetch, web_search, MCP-Tools und benutzerdefinierte Tools, die Daten schreiben oder senden, sowie jedes Tool, das Anmeldedaten verwendet.

Text in nicht vertrauenswürdigen Eingaben kann den Agenten anweisen, ein mächtiges Tool zu verwenden, das er besitzt. Der Support-Agent liest Tickets, daher erreicht er deine Bestell-API nur über das benutzerdefinierte Tool lookup_order. Deine Anwendung prüft, dass die Bestellung zum Absender des Tickets gehört.

In einer Cloud-Umgebung kann das Lesen einer Datei mit read auch CLAUDE.md- und AGENTS.md-Dateien als Anweisungen laden. Sie werden aus dem Verzeichnis der Datei und ihren übergeordneten Verzeichnissen geladen, bis hinauf zum Arbeitsverzeichnis der Sandbox. Dateien, die sie mit @ und einem Pfad referenzieren, etwa @docs/setup.md, werden ebenfalls geladen, bis zu fünf Referenzebenen tief. Eine Referenz kann auf eine beliebige Stelle in der Sandbox verweisen, zum Beispiel @/etc/hosts. Keine Einstellung schaltet dies ab, außer das Deaktivieren von read, also behandle ein Repository, Paket oder Archiv, das jemand außerhalb deines Teams schreiben kann, als nicht vertrauenswürdige Eingabe.

Wenn ein Agent nicht vertrauenswürdige Eingaben lesen und zugleich handeln muss, empfiehlt dieser Leitfaden eines von drei Designs:

• Trenne Lesen vom Handeln. In einer Multiagenten-Session gibt ein Lead-Agent Aufgaben an einen Fetcher, der das Web liest, und einen Writer, der Dateien oder Datensätze ändert.
• Gib dem Agenten ein eng gefasstes benutzerdefiniertes Tool. Deine Anwendung führt das Tool aus, prüft seine Eingabe und hält die Anmeldedaten. Der Support-Agent verwendet dieses Design, nicht die Trennung. Siehe Tool-Aufrufe beantworten, die die Session pausieren.
• Beziehe eine Person ein. Verwende always_ask beim mächtigen Tool, sodass eine Person jeden Aufruf genehmigt.

Die Trennung verwendet drei Agenten:

Die Ergebnisse des Fetchers werden aus nicht vertrauenswürdigen Seiten erstellt, und der Lead kann ihren Text an den Writer weitergeben. Belasse auto oder always_ask bei den Tools des Writers. Der Fetcher kann weiterhin einen Teil dessen, was er liest, an die Websites auf seiner web_fetch-Liste und in seinen Anfragen an den Suchanbieter senden.

Agenten in einer Multiagenten-Session teilen sich die Sandbox, ihre Dateien und die Vault-Credentials, daher trennt diese Aufteilung nur ihre Tools und Konversationen. Für eine stärkere Trennung verwende zwei Sessions mit separaten Umgebungen und Vaults. Lass deine Anwendung nur feste Felder, etwa eine Bestell-ID, zwischen den beiden Sessions weitergeben.

Limits und eine Möglichkeit zum Stoppen festlegen

Lege beim Erstellen jeder Session ein Budget fest und entscheide im Voraus, wie du einen Agenten stoppst.

Um einen laufenden Agenten zu stoppen, befolge diese Schritte:

1. Sende user.interrupt für sich allein.
2. Pausiere bei einem geplanten Agenten zusätzlich das Deployment, damit keine neue geplante Ausführung startet. Um den Zeitplan dauerhaft zu beenden, archiviere das Deployment.
3. Wenn ein Schlüssel möglicherweise offengelegt wurde, rotiere ihn bei dem Dienst, der ihn ausgestellt hat.
4. Wenn der Agent offene Workflow-Runs hat, sende zusätzlich eine user.message, die ihn auffordert, diese zu stoppen, da ein Interrupt keinen Run beendet. Welche Tool-Aufrufe du zuerst abbrechen musst, erfährst du unter Eine Session mit offenen Runs unterbrechen.
5. Warte, bis die Session zu idle wechselt. Eine laufende Session kann nicht archiviert oder gelöscht werden.
6. Archiviere die Session, um ihren Verlauf zu behalten. Lösche sie, wenn du den Verlauf nicht mehr benötigst.

Ein Interrupt macht nicht rückgängig, was der Agent bereits getan oder gesendet hat. Das Archivieren eines Agenten stoppt seine laufenden Sessions nicht.

Das max_list_cost.amount eines Budgets ist eine ganze Zahl von US-Cent, geschrieben als String, sodass "125" 1,25 $ bedeutet. Siehe Ein Budget bei der Session-Erstellung festlegen.

Du kannst einer Session, die ohne Budget erstellt wurde, kein Budget hinzufügen. Um eine Obergrenze zu ändern oder zu entfernen, siehe Eine Session an ihrem Budget fortsetzen. Nachdem du die Obergrenze einer Session entfernt hast, kannst du keine neue festlegen.

Ein Budget begrenzt die Ausgaben, aber es begrenzt nicht, was der Agent vor Erreichen der Obergrenze tut. Um Workloads mit unterschiedlichen Vertrauensstufen voneinander zu trennen, verwende separate Workspaces. Gib jedem Workload einen API-Key, der auf einen Workspace beschränkt ist, denn ein Schlüssel, der mehrere Workspaces erreichen kann, kann in jedem von ihnen handeln.

Siehe Session-Budgets, Session-Operationen und Geplante Deployments.

Nächste Schritte