Warum Cedar-Richtlinien für Ihr Amazon Bedrock AgentCore Gateway wichtig sind

Sie bauen eine agentenbasierte Lösung auf. Ihr Agent hat Zugriff auf MCP-Tools, und diese Tools führen echte Aktionen durch: Ausgaben genehmigen, Erstattungen ausstellen, Datensätze aktualisieren. Sie schreiben sorgfältige Prompt-Anweisungen, damit das große Sprachmodell das richtige Werkzeug für die richtige Situation auswählt. Alles funktioniert auf Anhieb. Aber was passiert, wenn es nicht funktioniert?

Wer nur an den glücklichen Weg denkt, kommt schnell zu Ergebnissen, aber er lässt viel Raum für Überraschungen. Prompt Engineering kann ein Modell lenken, aber lenken ist nicht dasselbe wie erzwingen. Eine gut formulierte Prompt-Injektion könnte das Modell davon überzeugen, eine Ausgabe in Höhe von 2.000 $ über ein Tool zu genehmigen, das eigentlich nur Beträge bis zu 50 $ verarbeiten sollte. Das Modell hat eine Anweisung befolgt; es war nur nicht die Ihre.

In diesem Beitrag sehen wir uns an, wie Cedar-Richtlinien in Amazon Bedrock AgentCore Gateway Ihnen deterministische, überprüfbare Leitplanken um Ihre MCP-Tools herum geben, so dass Sie sich nicht mehr nur auf Wahrscheinlichkeiten verlassen können.

Warum prompte Technik nicht ausreicht

Wenn Sie Ihre Werkzeuge für das Modell beschreiben, nehmen Sie Einschränkungen in die Werkzeugbeschreibungen auf. "Dieses Tool bearbeitet Ausgaben bis zu 50 $." Das Modell liest diese Beschreibung und leitet die Anfragen in den meisten Fällen entsprechend weiter. Aber große Sprachmodelle sind probabilistisch. Sie setzen keine Regeln durch, sondern sagen das wahrscheinlichste nächste Token voraus. Diese Unterscheidung ist wichtig, wenn viel auf dem Spiel steht.

Es gibt keinen Vertrag zwischen der Eingabeaufforderung und dem Verhalten des Modells. Das Modell befolgt vielleicht in 99% der Fälle Ihre Anweisungen, aber in den verbleibenden 1% läuft etwas schief. Und in agentenbasierten Anwendungen bedeutet "schief gehen", dass ein Tool eine Aktion ausführt, die es nicht hätte ausführen sollen. Im Gegensatz zu einer herkömmlichen API, bei der die Validierung der Eingaben deterministisch ist, wird die Entscheidung, ein bestimmtes Tool aufzurufen, vom Modell auf der Grundlage von Mustervergleichen und Token-Vorhersagen getroffen.

Betrachten Sie einen Prompt-Injection-Angriff. Ein Angreifer macht Eingaben, die die Anweisungen des Modells außer Kraft setzen oder verwirren. Plötzlich ruft das Modell das Tool für niedrige Ausgaben mit einem Betrag von $2.000 auf. Das Tool wird ausgeführt, das Geld wird bewilligt und Ihre Prompt-basierte "Leitplanke" hat nichts getan, um dies zu verhindern. Das Modell hat nicht versagt. Es hat einfach die überzeugendste Anweisung befolgt, die es erhalten hat, und diese Anweisung kam von dem Angreifer, nicht von Ihnen.

Dies ist kein hypothetisches Risiko. In dem Maße, in dem agentenbasierte Anwendungen in die Produktion übergehen und Finanztransaktionen, Kundendaten und betriebliche Abläufe verarbeiten, wird die Lücke zwischen "das Modell tut normalerweise das Richtige" und "das Modell tut garantiert das Richtige" zu einem echten Geschäftsrisiko. Wenn Sie sich allein auf Prompt-Engineering verlassen, müssen Sie diese Lücke als inhärenten Bestandteil Ihres Systems akzeptieren. Sie brauchen eine Schicht, die Anfragen deterministisch auswertet, bevor das Tool überhaupt ausgeführt wird. An dieser Stelle kommt Amazon Bedrock AgentCore Policy ins Spiel.

Wie Cedar-Richtlinien in Amazon Bedrock AgentCore Gateway funktionieren

Amazon Bedrock AgentCore Gateway fungiert als Einstiegspunkt für alle Tool-Aufrufe, die Ihr Agent tätigt. Wenn Sie eine Policy Engine mit dem Gateway verbinden, wird jeder Tool-Aufruf abgefangen und ausgewertet, bevor er das Tool selbst erreicht. Amazon Bedrock AgentCore Policy verwendet Cedar, eine von AWS entwickelte Open-Source-Richtliniensprache, um diese Bewertungsregeln auszudrücken.

Eine Cedar-Richtlinie ist eine deklarative Anweisung, die den Zugriff auf ein bestimmtes Tool unter bestimmten Bedingungen entweder erlaubt oder verbietet. Jede Richtlinie definiert einen Geltungsbereich (wer die Anfrage stellt, welche Aktion durchgeführt werden soll und auf welche Gateway-Ressource sie abzielt) und optionale Bedingungen, die den Kontext der Anfrage untersuchen, wie z. B. Eingabeparameter oder Benutzerattribute aus einem OAuth-Token.

Cedar folgt einem Standard- und Ablehnungsmodell. Wenn keine Richtlinie eine Anfrage ausdrücklich zulässt, wird sie verweigert. Und wenn eine forbid Richtlinie übereinstimmt, wird die Anfrage unabhängig von den übereinstimmenden permit Richtlinien verweigert. Dieser forbid-overrides-permit-Ansatz bedeutet, dass Ihre Sicherheitseinschränkungen immer gewinnen. Sie müssen nicht jeden möglichen Angriffsvektor vorhersehen; Sie müssen nur festlegen, was erlaubt ist, und alles andere wird standardmäßig blockiert.

Ein Beispiel für die Genehmigung von Ausgaben

Lassen Sie uns das konkretisieren. Stellen Sie sich vor, Sie haben einen Spesenbewilliger mit drei Werkzeugen:

Ihre Toolbeschreibungen teilen dem Modell diese Bereiche mit, und die meiste Zeit respektiert das Modell sie. Aber um sie deterministisch durchzusetzen, schreiben Sie Cedar-Richtlinien:

// Only allow the small expense tool for amounts under 50
permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ExpenseTools__approve_small",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:eu-west-1:123456789012:gateway/expense-gateway"
)
when {
  context.input.amount < 50
};
// Block the small expense tool for amounts of 50 or more
forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ExpenseTools__approve_small",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:eu-west-1:123456789012:gateway/expense-gateway"
)
when {
  context.input.amount >= 50
};

Die erste Richtlinie erlaubt das Tool approve_small nur, wenn der Betrag unter 50 liegt. Die zweite Richtlinie verbietet es ausdrücklich, wenn der Betrag 50 oder mehr beträgt. Da Cedar die Semantik forbid-overrides-permit verwendet, würde die Richtlinie forbid die Anfrage selbst dann blockieren, wenn eine andere Richtlinie sie versehentlich zulassen würde.

Selbst wenn eine Prompt-Injektion das Modell dazu verleitet, approve_small mit einem Betrag von $2.000 aufzurufen, wertet das Gateway die Cedar-Richtlinie aus, stellt fest, dass der Betrag den Schwellenwert überschreitet, und lehnt die Anfrage ab. Das Tool wird nie ausgeführt. Es wird keine Rechenleistung verbraucht, es treten keine Nebenwirkungen auf und der Agent erhält eine Ablehnung, mit der er gut umgehen kann.

Sie würden ähnliche Richtlinien für approve_medium und approve_large schreiben, die sich jeweils auf die entsprechenden Betragsbereiche beziehen. Das Ergebnis ist ein vollständiger Satz von Begrenzungen, die Ihre Geschäftsregeln widerspiegeln, aber unabhängig vom Verhalten des Modells durchgesetzt werden.

Warum dies über Schutzklauseln hinaus von Bedeutung ist

Sie denken jetzt vielleicht: "Ich kann einfach eine Schutzklausel in meinen Toolcode einfügen, die eine Ausnahme auslöst, wenn der Betrag außerhalb des Bereichs liegt". Und das sollten Sie unbedingt tun. Verteidigung in der Tiefe ist immer eine gute Idee. Aber sich ausschließlich auf Schutzklauseln zu verlassen, hat Nachteile, die Cedar-Richtlinien berücksichtigen.

Erstens wird das Tool trotzdem aufgerufen. Dieser Aufruf verbraucht Rechenressourcen und verursacht Kosten, selbst wenn das Tool die Anfrage letztendlich ablehnt. Wenn Ihr Agent Tausende von Anfragen pro Tag verarbeitet, summieren sich diese verschwendeten Aufrufe. Die Cedar Richtlinien stoppen die Anfrage am Gateway, bevor irgendein Toolcode ausgeführt wird. Keine Lambda-Ausführung, kein Spin-up von Containern, keine umsonst geöffnete Datenbankverbindung.

Zweitens: Schutzklauseln sind über Ihre Codebasis verstreut. Sie befinden sich in verschiedenen Funktionen, die in verschiedenen Programmiersprachen geschrieben sind und von verschiedenen Teams gepflegt werden. Wenn jemand bei einem Refactor versehentlich eine Schutzklausel entfernt oder abschwächt, sind Sie dem ausgesetzt und merken es vielleicht erst, wenn in der Produktion etwas schief läuft. Die Richtlinien von Cedar sind zentralisiert und deklarativ. Sie befinden sich an einem Ort, lassen sich leicht überprüfen und sind unabhängig von Ihren Tool-Implementierungen. Eine Änderung an Ihrem Tool-Code kann Ihre Cedar-Richtlinien nicht aufweichen.

Drittens ist es aus Sicht der Governance viel einfacher, eine Reihe von Cedar-Richtlinien zu überprüfen und zu validieren, als Schutzklauseln in Dutzenden von Funktionen und Repositories zu inspizieren. Auditoren können die Cedar-Richtlinien direkt lesen; sie müssen weder Python noch TypeScript oder eine andere Sprache verstehen, in der Ihre Tools geschrieben sind. Diese Trennung der Interessen bedeutet, dass Ihr Sicherheitsteam für die Richtlinien zuständig ist, während Ihr Entwicklungsteam für die Tool-Implementierungen zuständig ist, wobei beide unabhängig voneinander arbeiten können, ohne sich gegenseitig auf die Füße zu treten.

Schließlich bieten Ihnen Cedar-Richtlinien einen konsistenten Durchsetzungsmechanismus, unabhängig davon, wie Ihre Tools aufgebaut sind. Egal, ob ein Tool eine AWS Lambda-Funktion, ein Container hinter einer API oder ein Service eines Drittanbieters ist, auf der Gateway-Ebene gilt dieselbe Cedar-Richtlinie. Sie definieren Ihre Regeln einmal, und sie schützen jedes Tool einheitlich. Diese Konsistenz ist mit Schutzklauseln allein nur schwer zu erreichen, vor allem, wenn das Toolset Ihres Agenten mit der Zeit wächst und sich weiterentwickelt.

Fazit

Prompt-Engineering ist ein leistungsstarkes Werkzeug zur Steuerung des Modellverhaltens, aber es ist keine Sicherheitsgrenze. Wenn die Tools Ihres Agenten reale Aktionen durchführen, brauchen Sie eine deterministische Durchsetzung, die keine Prompt-Injektion umgehen kann. Die Cedar-Richtlinien in Amazon Bedrock AgentCore Gateway bieten genau das: eine zentralisierte, überprüfbare, standardmäßig verweigerte Richtlinienebene, die jeden Tool-Aufruf bewertet, bevor er ausgeführt wird.

Kombinieren Sie Cedar-Richtlinien mit Schutzklauseln in Ihrem Toolcode, und Sie erhalten eine Verteidigung in der Tiefe, die sowohl kosteneffizient als auch einfach zu steuern ist. Wenn Sie agentenbasierte Anwendungen auf AWS erstellen, sollten Sie zunächst die Grenzen definieren, die Ihre Tools niemals überschreiten dürfen, und diese dann als Cedar-Richtlinien formulieren.

Um loszulegen, lesen Sie die Dokumentation zu den Amazon Bedrock AgentCore-Richtlinien, prüfen Sie die gängigen Cedar-Richtlinienmuster und lesen Sie den AWS-Blogbeitrag zur Sicherung von KI-Agenten mit Richtlinien in Amazon Bedrock AgentCore.

Foto von Engin Akyurt