Blog • Agent Security

Warum ein KI-Agent JSON Schema allein nicht trauen kann: Prüfung, nicht vertrauenswürdige Eingaben, Rechteentscheid

Ein Tool-Aufruf, der JSON Schema besteht, zeigt nur, dass die Argumente die richtige Form haben. Mail senden, Dateien ändern oder das Gerät verlassen braucht ein zweites JSON: den Rechteentscheid. Ist decision nicht allow, stoppt der Aufruf.

Warum Ausgabe eine Form braucht, steht in warum KI JSON Schema braucht. Wer bei vielen Tool-Servern für Sicherheit zuständig ist, steht in MCP-Sicherheit und Rechte. Dieser Artikel ist nur die Entscheidung nach bestandener Form: Allowlist, Grant und allow / deny / ask.

• Schema beantwortet nur, ob die Form stimmt
• Der Tool-Name muss schon auf Ihrer Allowlist stehen
• Der Rechteentscheid ist ein separates JSON
• Fehlt die Fähigkeit im Grant, führen Sie das Tool nicht aus

Was das Schema beweist

JSON Schema prüft Typen, Enums und Pflichtfelder. Siehe JSON Schema. Es beweist nicht, dass diese Sitzung Mail senden darf, und nicht, dass Sie diesen Tool-Namen geprüft haben.

{
  "tool": "send_email",
  "arguments": {
    "to": "ops@example.com",
    "subject": "status",
    "body": "ok"
  }
}

Sind to, subject und body Zeichenketten, sieht ein Argument-Schema nur Typen. Es sieht nicht, dass der Grant dieser Sitzung read_inbox hat und send nicht.

Der Entscheid ist ein anderes JSON

Die MCP-Tool-Spezifikation verlangt eine Eingabeprüfung und eine Möglichkeit, den Aufruf abzulehnen. Siehe MCP Tools. Nach bestandenem Argument-JSON schreiben Sie einen Entscheid. toolAllowed heißt: dieser Tool-Name steht auf Ihrer Allowlist. grant ist die Fähigkeit, die diese Sitzung schon hat. decision darf nur allow, deny oder ask sein.

{
  "tool": "send_email",
  "argumentsValid": true,
  "toolAllowed": true,
  "grant": ["read_inbox"],
  "decision": "deny",
  "reason": "grant_missing"
}

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["tool", "argumentsValid", "toolAllowed", "decision", "reason"],
  "properties": {
    "tool": { "enum": ["send_email"] },
    "argumentsValid": { "type": "boolean" },
    "toolAllowed": { "type": "boolean" },
    "grant": {
      "type": "array",
      "items": { "enum": ["read_inbox", "send"] }
    },
    "decision": { "enum": ["allow", "deny", "ask"] },
    "reason": {
      "enum": ["ok", "grant_missing", "tool_not_allowlisted", "arguments_invalid"]
    }
  }
}

Dieses Schema stoppt eine decision außerhalb der drei Werte, ein argumentsValid, das kein Boolean ist, eine fehlende decision und einen Grant-Wert außerhalb der Liste. Es kann nicht sagen, dass allow zugleich toolAllowed und den nötigen Grant braucht. Diese Regeln bleiben in der App.

Bestehen und trotzdem ablehnen

Ändern Sie den Entscheid oben: decision auf allow, reason auf ok, grant bleibt read_inbox. Dieses Schema besteht. Bestehen ist keine Sendeerlaubnis. Die App-Regel: decision darf nur allow sein, wenn argumentsValid und toolAllowed beide true sind und grant send enthält. Fehlt eines, setzen Sie deny oder ask und rufen das Tool nicht auf.

Wo drei Fälle stoppen

Anmerkungen an einer Tool-Beschreibung sind Hinweise. Die Spezifikation sagt, Anmerkungen aus einer nicht vertrauenswürdigen Quelle sind keine schon durchgesetzte Sicherheitskontrolle. Siehe Tool-Anmerkungen sind kein Vertrag. Was den Aufruf wirklich stoppt, sind Ihr Schema und dieser Entscheid.

Nicht vertrauenswürdiger Text kann ein Modell einen Aufruf vorschlagen lassen, und eine nicht vertrauenswürdige Tool-Beschreibung kann eine gefährliche Fähigkeit wie ein gewöhnliches Tool aussehen lassen. Beides kann JSON mit gültiger Form ergeben. Die Abwehr besteht nicht darin, diesen Text nachzubauen. Setzen Sie das Tool zuerst auf die Allowlist, prüfen Sie den Aufruf mit dem Schema, und entscheiden Sie mit dem Grant über allow, deny oder ask. Eine Person kann den Aufruf weiter ablehnen.

Abgrenzung zu den anderen Artikeln

Ein falsches allow in JSONNote stoppen

1. 1
   Die richtige Operation wählen

   Öffnen Sie JSON Schema. Stellen Sie Betrieb auf Überprüfen Sie mit Schema. Rechteentscheid ins erste Feld, das Schema oben ins zweite. decision darf nur allow, deny oder ask sein. Jeder Grant-Eintrag nur read_inbox oder send.

2. 2
   Vier ungültige Dokumente prüfen

   Setzen Sie decision auf yes, argumentsValid auf die Zeichenkette true, löschen Sie decision, oder setzen Sie grant auf send_all. Alle vier scheitern. decision allow, reason ok und grant read_inbox besteht. Danach setzen Sie wieder deny oder ask und rufen das Tool nicht auf.

3. 3
   deny mit allow vergleichen

   Öffnen Sie JSON Vergleiche Diff. Entscheid mit deny ins erste Feld. Im zweiten nur decision auf allow und reason auf ok ändern. grant bleibt read_inbox. Beide bestehen das Schema. Die App-Regel stoppt das Senden, nicht diese Formprüfung.

Häufige Fragen

Darf das Tool laufen, wenn das Schema besteht?

Nein. Das Schema beweist nur die Argumentform. Sie prüfen noch, ob das Tool auf der Allowlist steht und ob der Grant die Fähigkeit enthält. Ist der Entscheid nicht allow, rufen Sie das Tool nicht auf.

Darf decision allow sein, wenn der Rechteentscheid das Schema besteht?

Nicht allein deshalb. decision allow, reason ok und ein Grant nur mit read_inbox ist eine gültige Form. Die App muss außerdem toolAllowed true sehen und die nötige Fähigkeit im Grant. Fehlt eines, ist es kein allow.

Was bedeuten Prompt Injection und Tool Poisoning hier?

Das sind Namen zweier Risiken, keine Schritte, die dieser Artikel nachbaut. Eines ist nicht vertrauenswürdiger Text, der ein Modell einen Aufruf vorschlagen lässt. Das andere ist eine nicht vertrauenswürdige Tool-Beschreibung, die eine gefährliche Fähigkeit gewöhnlich aussehen lässt. Beides kann JSON mit gültiger Form ergeben. Was sie stoppt, sind Allowlist, Schema und Grant, nicht das Umschreiben dieses Textes.

Ist das derselbe Artikel wie der über die Notwendigkeit von JSON Schema?

Nein. Jene Artikel erklären, warum Ausgabe eine Form braucht. Dieser beginnt, nachdem die Form bestanden hat: Allowlist und Grant können decision immer noch zu deny oder ask machen.

Was ist der Unterschied zwischen ask und deny?

deny heißt: dieses Mal nicht aufrufen. ask heißt: der Person zuerst die Argumente zeigen; lehnt sie ab, trotzdem nicht aufrufen. Beides ist nicht allow. Eine Person in der Schleife ist die Ablehnungsfähigkeit aus der MCP-Tool-Spezifikation.

Fazit

JSON Schema stoppt Tool-Argumente mit falscher Form. Der Rechteentscheid stoppt einen Aufruf, dessen Form schon stimmt, dessen Fähigkeit aber falsch ist. Behalten Sie beide JSON-Dokumente, dann hat die Ausführung ein Tor.

Die Entscheidung: Schema-Bestehen heißt nur richtige Form; das Tool zuerst auf die Allowlist; der Grant muss diese Fähigkeit enthalten; ist decision nicht allow, nicht aufrufen; ist decision allow, der Grant aber zu klein, trotzdem auf deny oder ask ändern.

Zurück zum Blog