Blog • AI / Agent

Claude Managed Agents 2026: Wie entscheidet ein AI Agent, ob ein Tool Call erlaubt ist? JSON permission policy und MCP Security

Am 10. September 2026 hat Anthropic der permission policy von Claude Managed Agents einen neuen Typ gegeben: auto. Am selben Tag bekamen agent.tool_use und agent.mcp_tool_use ein evaluation-Feld neben dem bisherigen evaluated_permission.

Ein vom Modell vorgeschlagener Tool Call ist nicht derselbe wie ein ausgeführter. Die Entscheidung liegt in der serverseitigen Richtlinienbewertung: Sie liest die JSON-Policy auf dem Agent und gibt allow, deny oder ask für Toolname, Input und Sitzung dieses Aufrufs.

Dieser Artikel behandelt:

• Auf welcher Schicht jede der drei permission policies sitzt
• auto — was die Bewertung pro Aufruf prüft und welches JSON die drei Ergebnisse hinterlassen
• Warum das MCP-Toolset standardmäßig always_ask ist und wie das mit auto gestapelt wird
• Nachdem eine Sitzung bei requires_action stoppt, wie user.tool_confirmation geschrieben wird
• Wie Sie Richtlinie, Ereignisse und Bestätigungsanfrage in JSONNote auseinanderziehen

Die drei Richtlinien: always_allow, always_ask, auto

Permission policy gilt nur für Tools, die der Server für Sie ausführt: eingebautes agent_toolset_20260401 plus jedes MCP-Toolset, das Sie anhängen. Custom Tools laufen in Ihrer App und umgehen diese Richtlinie. Anfragen brauchen den Beta-Header managed-agents-2026-04-01. Offizielle Doku:

Claude Managed Agents Permission policies.

Die Richtlinie entscheidet, wann dieser Aufruf läuft, nicht ob das Tool im Katalog steht. Um ein Tool vom Agent zu nehmen, nutzen Sie disable. Erwarten Sie nicht, dass die Richtlinie es versteckt.

Die Defaults unterscheiden sich. Das Agent-Toolset ist standardmäßig always_allow. Das MCP-Toolset ist standardmäßig always_ask. Kein Toolset schaltet auto von allein ein; Sie schreiben es ins JSON.

Eine laufende Session behält die Toolset-Konfiguration vom Erzeugen. Nach einer Agent-Änderung greifen nur neue Sessions die neue Richtlinie. Release Notes:

Claude Platform release notes (2026-09-10).

Worauf auto wirklich schaut

Früher war ein Tool immer erlaubt oder immer gefragt. auto verlegt die Entscheidung vom Tool auf den Aufruf.

Die offizielle Beschreibung ist konkret: Die Bewertung sieht das Tool selbst, den Input dieses Aufrufs und die Sitzung bis hierhin. Derselbe bash mit zwei verschiedenen command-Werten kann also allow und deny ergeben.

1. 1
   Der Aufruf wird erlaubt

   Der Server hält diesen Aufruf für sicher. Das Tool läuft wie unter always_allow. Keine Pause, kein menschliches Fenster.

2. 2
   Der Aufruf wird abgelehnt

   Der Server stuft ihn als hohes Risiko ein. Das Tool läuft nicht. Der Agent bekommt ein Fehler-tool result: Permission to use {tool_name} has been denied., mit is_error: true. Die Sitzung läuft weiter. Ihr Client kann dieses deny nicht ändern.

3. 3
   Der Aufruf hält an und wartet auf Sie

   Der Server kommt zu keinem festen Schluss. Die Sitzung pausiert wie unter always_ask. Sie erlauben oder lehnen dann mit einem Bestätigungsereignis ab.

Absicht wird nur aus den user.message gelesen, die Sie senden. Tool-Ergebnisse, geholte Seiten, MCP-Server-Antworten und Nachrichten zwischen Threads gelten als Inhalt, nicht als Anweisung. Manche Aufrufe gelten unabhängig vom Fragenden als hohes Risiko.

Wenn Sie unvertrauten Endnutzertext unverändert in user.message kleben, liest der Server das als Ihre Absicht und kann deshalb einen Aufruf erlauben. Tools auf diesem Eingangspfad bekommen eigenes always_ask.

Wo die Richtlinie im JSON sitzt

Die Richtlinie steht an zwei Stellen: default_config.permission_policy des Toolsets und eine Override-Zeile in configs. Die Konfiguration unten setzt Agent-Toolset und GitHub-MCP auf auto und pinnt bash auf always_ask.

{
  "name": "Ops Agent",
  "model": "claude-opus-5",
  "mcp_servers": [
    {
      "type": "url",
      "name": "github",
      "url": "https://mcp.example.com/github"
    }
  ],
  "tools": [
    {
      "type": "agent_toolset_20260401",
      "default_config": {
        "permission_policy": { "type": "auto" }
      },
      "configs": [
        {
          "name": "bash",
          "permission_policy": { "type": "always_ask" }
        }
      ]
    },
    {
      "type": "mcp_toolset",
      "mcp_server_name": "github",
      "default_config": {
        "permission_policy": { "type": "auto" }
      }
    }
  ]
}

mcp_server_name muss zum mcp_servers-Eintrag name passen. Beim Override nach Toolnamen auf der MCP-Seite ist name der vom Server gemeldete Toolname, kein Alias von Ihnen.

Lassen Sie default_config weg, startet das Agent-Toolset als always_allow. Das ist ein Bequemlichkeitsdefault, kein Sicherheitsdefault.

Die evaluation auf jedem Aufruf

Egal welche Richtlinie: agent.tool_use und agent.mcp_tool_use tragen oben evaluated_permission mit dem Wert allow, ask oder deny. Die meisten Ereignisse tragen außerdem ein evaluation-Objekt; type nennt die Richtlinie, die den Schluss gezogen hat.

Unter auto speichert das Objekt auch das Serverurteil. Bei ask oder deny kommt reason_code dazu. Offizielles Beispiel: bash unter auto; ein Hochrisiko-Aufruf wird abgelehnt.

{
  "type": "agent.tool_use",
  "id": "sevt_01pqr...",
  "name": "bash",
  "input": {
    "command": "rm -rf /workspace/reports"
  },
  "evaluated_permission": "deny",
  "evaluation": {
    "type": "auto",
    "evaluated_permission": {
      "type": "deny",
      "reason_code": "high_risk"
    }
  },
  "processed_at": "2026-03-25T14:05:12Z"
}

reason_code ist für Verzweigung und Audit-Logs Ihres Clients, kein Text für Menschen. Die Doku nennt derzeit indeterminate und high_risk. Der Client muss spätere zusätzliche type- oder reason_code-Werte tolerieren.

Zwei Fälle haben kein evaluation. Der Agent wählte ein Tool, das in der Sitzung nicht aktiv ist: Das Ereignis hat nur evaluated_permission: "deny". Ältere Ereignisse vor dem Feld haben es auch nicht: allow las man als always_allow, ask als always_ask.

Das ist dieselbe Schicht wie „JSON ist eine Sicherheitsgrenze“, aber der Schnitt ist anders. Dort geht es um die Prüfung der arguments, die das Modell sendet. Hier schreibt die Plattform eine eigene Bewertung, die Sie nicht aufheben. Voriger Artikel:

AI Agents und die JSON-Sicherheitsgrenze.

MCP Tool Calls und das Standard-always_ask

MCP legt den Toolkatalog aus Ihrem Repo auf einen Server draußen. Der Server stellt Tools per JSON-RPC bereit; jedes Tool trägt ein inputSchema. Der Host füttert den Katalog ins Modell und macht aus dem Aufruf ein tools/call. Spezifikation:

MCP Tools.

Managed Agents bleiben hier konservativ: Das MCP-Toolset ist standardmäßig always_ask. Kommt auf einem schon verbundenen Server ein neues Tool hinzu, läuft es nicht still in Ihrer App. Das ist das erste MCP-Security-Tor, das die Plattform durchsetzen kann – zuverlässiger als der description-Text des Servers.

Ändern können Sie es trotzdem. Vertrauen Sie einem GitHub-MCP und wollen weniger Unterbrechungen, setzen Sie dessen default_config.permission_policy auf always_allow oder auto. Sie ändern, wann es läuft, nicht ob Schema noch geprüft wird.

Gestapelt wirken sie wie eine Tür. Nur auto an, Schema weiter {"sql":{"type":"string"}}, und die Bewertungsfläche ist zu weit zum Urteilen. Mehr Aufrufe fallen in indeterminate, also ask. Ein engeres Schema hilft auto, einen logbaren Schluss zu schreiben. Wer welche Schicht trägt:

MCP-Sicherheit: Warum Schema, Tool Calling und Rechte einander nicht ersetzen.

Der JSON-Freigabefluss nach ask

Ein Aufruf mit ask kommt nur von always_ask oder von auto mit indeterminate. Die Ereignisreihenfolge danach ist fest.

1. 1
   Zuerst ein tool_use-Ereignis

   Die Sitzung sendet agent.tool_use oder agent.mcp_tool_use, schon mit evaluated_permission: "ask".

2. 2
   Dann idle

   Die Sitzung pausiert. session.status_idle hat stop_reason.type auf requires_action. Die blockierten Ereignis-IDs stehen in stop_reason.event_ids. Sie wartet weiter.

3. 3
   Sie senden ein Bestätigungsereignis

   Für jede blockierte ID senden Sie user.tool_confirmation. tool_use_id ist die Ereignis-ID, result ist allow oder deny. Bei Ablehnung können Sie mit deny_message erklären. Eine Anfrage kann mehrere Bestätigungen tragen.

4. 4
   Die Sitzung geht zurück auf running

   Sind alle Blöcke gelöst, laufen erlaubte Tools. Abgelehnte laufen nicht, und der Agent bekommt ein tool result mit Ihrer deny_message.

{
  "events": [
    {
      "type": "user.tool_confirmation",
      "tool_use_id": "sevt_01ask...",
      "result": "allow"
    },
    {
      "type": "user.tool_confirmation",
      "tool_use_id": "sevt_01mcp...",
      "result": "deny",
      "deny_message": "Do not push to main from this session."
    }
  ]
}

Ist das evaluated_permission des Ereignisses nicht ask, antwortet die API auf eine Bestätigung mit 400. Das gilt auch für Aufrufe, die auto schon abgelehnt hat: Der Client hat keinen Einspruch. Interaktiv geht ant beta:sessions connect, im Terminal erlauben oder ablehnen.

Eigene Freigabewarteschlange, deny zurück an den Agent und eine wiederholbare Richtlinie im Host bleiben einem späteren Implementierungsstück. Dieser Artikel macht nur das JSON klar, das die Plattform schon für Sie bewertet hat.

auto ist kein Checkpoint

Die offizielle Doku hat einen Satz, den Sie nicht überspringen sollten: auto ist kein menschlicher Checkpoint. Hält der Server den Aufruf für sicher, läuft er, bevor jemand ihn sieht; die Wirkung kann irreversibel sein. Tools, die ein Mensch sehen muss, bekommen always_ask.

Custom Tools stehen auch außerhalb dieser Tür. agent.custom_tool_use hat weder evaluated_permission noch evaluation. Ihre App empfängt das Ereignis, entscheidet über Lauf oder Ablehnung und antwortet mit user.custom_tool_result. Die Plattform bewertet diesen Hop nicht für Sie.

„Wie ein AI Agent entscheidet, ob ein Tool Call erlaubt ist“ ist also eine enge Aussage: nur Agent- und MCP-Tools, die der Server für Sie ausführt, und nur nachdem Sie die Richtlinie ausdrücklich auf auto gesetzt haben. Alles andere ist immer erlaubt, immer gefragt oder gar nicht Sache der Plattform.

Richtlinie und Ereignisse in JSONNote prüfen

Richtlinien-JSON, tool_use-Ereignisse und Bestätigungsanfragen sehen ähnlich aus. Ihre Felder liegen nicht auf derselben Schicht. Debuggen Sie nicht mit dem Auge.

1. 1
   Zuerst die Richtlinie formatieren

   Legen Sie die tools-Konfiguration des Agent in den JSON-Formatierer. Prüfen Sie, dass default_config und die configs-Einträge für permission_policy.type nicht vertippt oder von einem Override gefressen sind.

2. 2
   Dann die Ereignisform prüfen

   Mit JSON Schema schreiben Sie ein Minimaleschema für evaluation. type enumeriert always_allow / always_ask / auto; unter auto verlangen Sie ein verschachteltes evaluated_permission. Unbekannte reason_code-Werte tolerieren Sie über additionalProperties; lehnen Sie sie nicht pauschal ab.

3. 3
   Zwei Aufrufe vergleichen

   Ist dasselbe Tool einmal erlaubt und einmal abgelehnt, richten Sie mit JSON Diff die beiden input und die beiden evaluation aus. Der Unterschied sitzt fast immer in command, path oder dem Schritt, der gerade in der Sitzung passiert ist — nicht im Toolnamen.

4. 4
   Eine teilbare Nachbereitung behalten

   Richtlinie und geschwärzte Ereignisse können Sie einem Kollegen über Hash teilen geben. Die Daten treffen keinen Server. Keine Schlüssel und keine Produktionstoken hinein.

FAQ

Lässt auto jeden Tool Call durch?

Nein. auto gilt pro Aufruf: zwei Calls desselben Tools können sich unterscheiden, wenn Input oder Sitzung anders sind. high_risk ist deny, und der Client kann das nicht mit user.tool_confirmation aufheben.

Heißt gültiges JSON Schema, der Aufruf darf laufen?

Nein. Schema prüft nur, ob die Argumente richtig aussehen. permission policy entscheidet, ob dieser Aufruf laufen darf. Ein formgültiger bash-Befehl kann unter auto trotzdem deny werden.

Welche Richtlinie gilt für MCP Tool Calls standardmäßig?

Das MCP-Toolset ist standardmäßig always_ask. Ein neues Tool auf einem Server läuft nicht von allein in Ihrer App. Vertrauen Sie dem Server erst, dann setzen Sie default_config.permission_policy auf always_allow oder auto.

Gelten Custom Tools unter der permission policy?

Nein. Custom Tools laufen in Ihrer App. Das Ereignis ist agent.custom_tool_use, ohne evaluated_permission und ohne evaluation. Sie entscheiden, ob es läuft, und antworten mit user.custom_tool_result.

Kann auto die menschliche Freigabe ersetzen?

Nein. Die Doku sagt: auto ist kein menschlicher Checkpoint. Hält der Server den Aufruf für sicher, läuft er, bevor jemand ihn sieht; Nebenwirkungen können irreversibel sein. Tools, die ein Mensch sehen muss, bekommen eigenes always_ask.

Zusammenfassung

Das am 10. September ergänzte auto macht aus „darf dieses Tool genutzt werden“ „darf dieser Aufruf laufen“. Die Bewertung nutzt die JSON-Policy auf dem Agent plus Tool, Input und Sitzung dieses Aufrufs. Das Ergebnis steht auf dem Ereignis als evaluated_permission und evaluation.

Das Modell schlägt den Aufruf vor. Die Richtlinien-Engine erlaubt, lehnt ab oder hält an und fragt einen Menschen. MCP fragt standardmäßig zuerst. Custom Tools gehören Ihnen. Der Client hebt ein deny nicht auf.

Lesen Sie Richtlinien-JSON und Ereignis-JSON als zwei Verträge. Schema-gültig ist nicht autorisiert. Tools, die ein Mensch sehen muss, bleiben auf always_ask. Tools, die weniger unterbrechen und trotzdem Auditfelder hinterlassen sollen, können auto einschalten.

← Zurück zum Blog