Ein deterministisches Sicherheitsnetz für Ihren Agent: AgentCore Policy und Cedar

Hinweis: Dieser Artikel wurde mit Unterstützung von KI aus dem englischen Original übersetzt.

TL;DR: Ich habe eine Cedar Policy Engine an das Gateway aus dem letzten Artikel gebunden und zwei echte Schutzmechanismen ausgeliefert: Der eine weist get_opportunity-Aufrufe ohne opportunity_id zurück, der andere weist einen HubSpot-Write zurück, sofern confirmed_by_presenter nicht vorhanden und true ist. Beide werden außerhalb der eigenen Argumentation des Modells durchgesetzt, sodass keine Prompt-Injection sich daran vorbeireden kann. Die ehrliche Grenze ist genauso wichtig: Cedar sieht immer nur die Parameter eines einzelnen Aufrufs, nie den Gesprächsverlauf. Deshalb prüft die Write-Absicherung nur, ob das Freigabe-Flag gesetzt ist, nicht ob ein Mensch die Freigabe, die es vorgibt zu repräsentieren, tatsächlich erteilt hat.

Teil 5 der Serie „Einen Partner-Sales-Agent auf Amazon Bedrock AgentCore bauen“, aufgebaut um ein reales Projekt: einen dialogbasierten Agent, der HubSpot CRM und AWS Partner Central für das Sales-Team eines AWS-Partners verbindet. Der letzte Artikel hat das Gateway eröffnet, durch das jeder externe Aufruf läuft; dieser Artikel behandelt die an dieses Gateway gebundene Cedar Policy Engine – was sie deterministisch blockiert und, ebenso präzise, was sie nicht sehen kann.

Inhaltsverzeichnis

• Artikel 1: Zwei Systeme, ein Vertriebsprozess: Ein AWS-Partner-Agent auf Amazon AgentCore Harness
• Artikel 2: Warum ich keine eigene Agent-Loop geschrieben habe: Das Argument für AgentCore Harness
• Artikel 3: AgentCore Runtime konfigurieren: Session-Lifecycle, Container-Backing, Memory
• Artikel 4: Ein Gateway, sechs Tools: AgentCore Gateway als einziger Weg nach außen für Ihren Agent
• Artikel 5: Ein deterministisches Sicherheitsnetz für Ihren Agent: AgentCore Policy und Cedar
• Artikel 6: Einen Agent ohne Vektordatenbank grounden: AgentCore Managed Knowledge Base
• Artikel 7: Vom Firmennamen zum CRM-Datensatz: Eine AgentCore-Konversation, End-to-End (demnächst)

Eine Policy Engine ist genau die Art von Feature, die häufig zu Übertreibungen über die Sicherheit eines Systems verleitet. Wenn Begriffe wie „Cedar" und „deterministische Durchsetzung" gemeinsam auftauchen, liegt für Leser der Schluss nahe, der Agent sei umfassend gegen jede Form von Missbrauch geschützt, einschließlich Prompt-Injection und Modellfehlern. Das ist aber nicht der Fall. Zur Klarstellung der technischen Grenzen: AgentCore Policy setzt in diesem Projekt zwei konkrete Leitplanken durch, die immun gegen Prompt-Injection sind, ihr Geltungsbereich ist aber eng begrenzt. Die Engine bewertet einzelne Tool-Aufrufe isoliert und hat keinen Zugriff auf den weiteren Gesprächskontext oder -verlauf.

Was AgentCore Policy ist

AgentCore Policy ist eine Autorisierungs-Engine in der Cedar-Sprache, die an ein AgentCore Gateway angebunden wird, nicht an den Harness. Jeder Tool-Aufruf, den der Harness über das Gateway schickt, wird gegen die Policies der Engine geprüft, bevor er ein Target erreicht. Die Auswertung läuft vollständig außerhalb des eigenen Codes des Agents ab, nachdem das Modell bereits entschieden hat, den Aufruf zu tätigen. Genau diese Platzierung ist der entscheidende Punkt: Ein durch Prompt-Injection manipuliertes oder schlicht fehlgeleitetes Modell kann sich nicht um eine Prüfung herumdenken, an der es nie beteiligt ist.

Dieses Projekt liefert zwei echte Policies aus. Die eine weist get_opportunity-Aufrufe zurück, die ohne opportunity_id ankommen – eine einfache Input-Absicherung auf dem Lesepfad zu Partner Central. Die andere weist upsert_contact-Aufrufe zurück, den einzigen Schreibpfad im gesamten System, sofern confirmed_by_presenter nicht vorhanden und true ist; der ausgelieferte Feldname trägt noch den Begriff aus der Build-Zeit für den Sales-Vertreter, der die Demo präsentiert.

Dreißig Sekunden dazu, wie Cedar eine Anfrage allgemein auswertet, bevor es um die Spezifika dieses Projekts geht, denn ein Detail davon sorgte für die größte Überraschung des Builds. Eine Cedar-Anfrage wird nur erlaubt, wenn mindestens eine permit-Policy zutrifft und keine Forbid-Policy zutrifft. Ein explizites forbid schlägt immer jedes permit. Und eine Anfrage, zu der überhaupt keine Policy etwas sagt, erhält die Standardantwort der Engine, und die lautet deny [1]. Diesen letzten Halbsatz sollten Sie sich merken: Der nächste Abschnitt zeigt, was er einem laufenden terraform apply angetan hat.

In der AgentCore-Konsole hat Policy eine eigene Seite unter Build, neben Harness, Gateway und Memory. Eine Engine anzulegen braucht einen Namen und eine Beschreibung; die dieses Projekts heißt partner_growth_agent_policy. Die Policies leben innerhalb der Engine, jede besteht aus einem Namen, einer Beschreibung und einem direkt eingegebenen Cedar-Statement. Nichts an der Engine selbst verweist auf ein Gateway. Die Verknüpfung wird am Gateway konfiguriert, als Referenz auf die Policy Engine plus einem Enforcement-Modus [2], und dieses Modus-Feld hat mehr Gewicht, als seine Größe vermuten lässt; der Abschnitt „Es in Aktion beobachten" dreht sich genau darum.

Warum überhaupt eine Policy Engine in eine Demo einbauen, statt sie nur zu beschreiben? Drei Gründe haben das hier entschieden. Sie war im gepinnten Terraform-Provider (hashicorp/aws 6.54.0) bereits vollständig modelliert. Sie fügt eine Kontrolle hinzu, die in überprüfbarer Konfiguration lebt statt in Prompt-Text, was das Blast-Radius-Argument aus Artikel 1 eine Ebene tiefer weiterführt. Und schließlich hält sie an dem Tag, an dem das Urteilsvermögen des Modells versagt oder manipuliert wird – was, wie die Zahlen später in diesem Artikel zeigen, kein hypothetischer Tag ist.

Default-Deny und der Baseline-Permit, den es erzwingt

Der Plan war bescheiden: die Engine mit dem Gateway verknüpfen und eine Forbid-Regel ausliefern, die Input-Absicherung für get_opportunity. Der erste Apply kam nicht einmal bis zur Erstellung der Policy. Er scheiterte wortwörtlich mit diesem Fehler:

Overly Restrictive: Policy Engine will deny every request for the specified principal/action/resource combination if the policy is added.

Das ist eine Analyse zur Erstellungszeit, kein Laufzeitfehler, und sie feuerte für beide im Fehler genannten Principal-Typen (IamEntity und OAuthUser). Der Service hat ermittelt, was das Policy-Set der Engine mit nur einem Forbid darin entscheiden würde, kam zu dem Schluss „alles ablehnen" und weigerte sich, die Policy überhaupt zu erstellen. Die Logik folgt direkt aus Cedars Standardantwort: ohne irgendein Permit. Das Forbid war dabei nebensächlich, denn jeder Aufruf auf jedes Target lief ohnehin schon auf das Default-Deny zu. Zu diesem Zeitpunkt hatte dieses Gateway vier Targets (list-opps, get-opp, reason, managed-kb), und eine Nur-Forbid-Engine im Enforcing-Modus zu verknüpfen hätte alle vier stummgeschaltet, nicht nur die fehlerhaften Aufrufe, auf die das Forbid abzielte.

Die Lösung ist ein Baseline-Permit, das jedes Target am Gateway abdeckt. Hier das ausgelieferte Statement, verdichtet auf den Cedar-Block; es listet heute sechs Actions, weil die beiden HubSpot-Targets aus Artikel 4 dazukamen, als sie verdrahtet wurden:

permit (  principal,  action in [    AgentCore::Action::"list-opps",    AgentCore::Action::"get-opp",    AgentCore::Action::"reason",    AgentCore::Action::"managed-kb",    AgentCore::Action::"hs-search",    AgentCore::Action::"hs-write"  ],  resource == AgentCore::Gateway::"<gateway_arn>");

Die Action-Namen sind Gateway-Target-Namen, keine Tool-Namen: Eine Action auf Target-Ebene funktioniert als Action-Gruppe, die jedes unter diesem Target registrierte Tool abdeckt, und da Cedar keine Wildcard-Action kennt, ist eine Gruppe pro Target der dokumentierte Weg, die Liste kurz zu halten [3]. Und der Principal bleibt absichtlich leer. Dieses Gateway authentifiziert Aufrufer mit AWS_IAM, und die einzige Rolle, der darauf bedrock-agentcore:InvokeGateway gewährt ist, ist die Execution-Role des Harness – IAM hat also bereits entschieden, wer hier überhaupt auftauchen kann. Eine Cedar-Principal-Bedingung würde diese Entscheidung nur wiederholen, ohne irgendetwas zusätzlich einzuschränken.

Für den Automatisierungspfad ist die Reihenfolge der entscheidende Befund. Nichts in der Forbid-Ressource verweist auf die Permit-Ressource, also hat Terraforms Graph keine implizite Kante zwischen beiden, und ein paralleler Apply kann die Create-Zeit-Validierung des Forbids vor dem Permit ins Rennen schicken und im exakt oben zitierten Fehler landen. Mein ausgelieferter Demo-Code fixiert die Reihenfolge mit einem expliziten depends_on = [aws_bedrockagentcore_policy.pc_permit_existing_targets] an jedem Forbid. Wer über die Konsole arbeitet, bekommt dieselbe Regel in einfacherer Form: erst das Baseline-Permit anlegen, dann jedes Forbid, denn der Server führt dieselbe Analyse aus, egal auf welchem Weg die Policy ankommt.

Die Verknüpfung der Engine mit dem Gateway hielt eine Überraschung bereit. UpdateGateway, die Operation, auf der diese Verknüpfung reitet, scheiterte fünfmal an fünf unterschiedlichen fehlenden Berechtigungen auf der eigenen Execution-Role des Gateways, jede einzeln als live AccessDenied entdeckt: bedrock-agentcore:GetPolicyEngine auf dem ARN der Policy Engine, dann AuthorizeAction und PartiallyAuthorizeActions, beide jeweils zweimal benötigt, einmal gegen den ARN der Policy Engine und einmal gegen den eigenen ARN des Gateways. Nichts davon zeigt sich in terraform validate. Zwei weitere CREATE_FAILED-Versuche bei PartiallyAuthorizeActions erwiesen sich als IAM-Propagationsverzögerung statt als fehlende Berechtigungen; dieselbe, bereits angehängte Policy wendete sich bei einem späteren Versuch sauber an.

Default-Deny hinterlässt außerdem eine Standing-Regel. Jedes neue Target an diesem Gateway muss im selben Change zum Baseline-Permit hinzugefügt werden, sonst wird es ab dem Moment seiner Existenz abgelehnt. Als die HubSpot-Targets dazukamen, wurde zuerst das Permit erweitert und danach das neue Forbid hinzugefügt – dieselbe Permit-plus-Forbid-Paarung, derselbe depends_on.

Der Cedar-Entscheidungsfluss

Von oben nach unten gelesen: Ein Tool-Aufruf kommt am Gateway an und trägt den Principal des Harness, und im Enforcing-Modus wird nichts weitergeleitet, bevor die Engine geantwortet hat. Trifft kein Permit zu, ist die Auswertung faktisch beendet: Deny, bevor überhaupt ein Forbid befragt wird. Innerhalb des Raums, den das Permit öffnet, wird jedes Forbid gegen das eigene context.input des Aufrufs geprüft. Ein greifendes Forbid erzeugt ein explizites Deny, das die konkrete Policy benennt. Ein Aufruf, der beide übersteht, wird an seine Target-Lambda oder den Knowledge-Base-Connector weitergeleitet.

Eine Präzisierung, damit das Diagramm sich nicht überhebt: Formal wertet Cedar das gesamte Policy-Set aus und kombiniert die Ergebnisse – eine Anfrage wird nur erlaubt, wenn irgendein Permit zutrifft und kein Forbid [1]. Für ein Policy-Set aus einem Permit und zwei Forbids ist die sequenzielle Darstellung oben entscheidungsäquivalent. Sie macht die tragende Tatsache sichtbar: Ein Forbid kann nur einschränken, was ein Permit bereits erlaubt hat. Anwesenheit und Geltungsbereich des Baseline-Permits setzen die Obergrenze, bevor überhaupt ein Forbid mitreden darf. Deshalb ist das Permit kein Boilerplate. Es ist die Hälfte des Policy-Sets, die entscheidet, ob das Gateway überhaupt funktioniert.

Was Cedar sehen kann und was nicht

Eine Policy in dieser Engine erhält genau zwei Dinge zu einer Anfrage: den aufrufenden Principal und context.input, die eigenen Parameter des aktuellen Aufrufs [4]. Der Principal trägt hier keinerlei Information, und das meine ich wörtlich. Dieses Gateway authentifiziert mit AWS_IAM, jeder Aufruf ist mit derselben Execution-Role des Harness signiert, und so kommt jede Anfrage als derselbe Principal an, unabhängig davon, wer gerade chattet oder was das Gespräch gerade tut. Das lässt context.input als einziges unterscheidendes Signal übrig, auf das eine Policy reagieren kann: ein Aufruf, seine eigenen Argumente, nichts weiter.

Kein Gesprächsverlauf. Nicht, zu welchem Turn oder Flow ein Aufruf gehört. Nicht, ob ein Mensch irgendetwas freigegeben hat. Ich bin direkt gegen die Kontur dieser Grenze gelaufen: Ein erster Policy-Entwurf verwies auf ein Attribut context.request_type, gemeint als „findet dieser Aufruf während eines BANT-Qualifizierungs-Flows (Budget, Authority, Need, Timeline) statt" – und es stellte sich heraus, dass es gegen das echte Cedar-Schema schlicht nicht schreibbar ist. Ein solches Attribut existiert nicht, und keine Policy-Syntax unterstützt eines.

Das erledigt die verlockendste Nutzung der Engine. Live-Stichproben während des Builds maßen, dass das Modell reason_about während der BANT-Qualifizierung aufrief, obwohl ein System-Prompt ihm das ausdrücklich untersagte: 2 von 6 stichprobenartigen Läufen (rund 33 Prozent) unter der ursprünglichen einabsätzigen Anweisung, und 1 von 9 (rund 11 Prozent), nachdem der Prompt in kurze, isolierte, wiederholte Regeln umstrukturiert wurde. Die Umstrukturierung hat diese gesamte Verbesserung geleistet. Cedar hat nichts zur Reduktion beigetragen und kann die verbleibenden 11 Prozent auch nicht schließen, denn der Verstoß ist ein wohlgeformter, legitim aussehender reason_about-Aufruf, am Gateway nicht zu unterscheiden von einer sanktionierten Nutzung desselben Tools einen Turn später. Ein pauschales Forbid auf reason_about würde die legitime Fähigkeit zu offenem Reasoning gleich mit lahmlegen. „Dieser Aufruf ist Teil eines BANT-Flows" ist Gesprächszustand, und Gesprächszustand erreicht die Engine nie. Die 11 Prozent bleiben ein dokumentierter, akzeptierter Rest auf Prompt-Ebene, und ich schreibe diesen Satz lieber so, als eine Policy Engine eine Abdeckung suggerieren zu lassen, die sie nicht hat.

Die Write-Absicherung verdient dieselbe Sorgfalt. Hier beide ausgelieferten Forbid-Regeln zusammen:

forbid (  principal,  action == AgentCore::Action::"get-opp___get_opportunity",  resource == AgentCore::Gateway::"<gateway_arn>") unless { context.input has opportunity_id };​forbid (  principal,  action == AgentCore::Action::"hs-write___upsert_contact",  resource == AgentCore::Gateway::"<gateway_arn>") unless {  context.input has confirmed_by_presenter &&  context.input.confirmed_by_presenter == true};

Die Action-Namen folgen der target___tool-Konvention aus dem letzten Artikel. Beide Regeln begannen als forbid ... unless { context.input has <field> }-Statements. Im Code-Review wurde klar, dass diese Konstruktion nur die Anwesenheit eines Schlüssels prüft, nicht seinen Wert [1]. Dadurch hätte die ursprüngliche Write-Absicherung Aufrufe erlaubt, bei denen confirmed_by_presenter auf false stand. Zwar wies der Prompt das Modell nirgends an, false zu übermitteln, und ein solches Szenario galt im Normalbetrieb als unerreichbar – der Grund für die Änderung der Policy war aber, sie unabhängig von jeder Annahme über das Modellverhalten zu machen. Da der Zweck dieses Sicherheitsnetzes gerade darin besteht, Garantien unabhängig von den Anweisungen oder Handlungen des Modells durchzusetzen, musste die Policy so angepasst werden, dass das Feld nicht nur vorhanden sein muss, sondern konkret true sein muss.

Nun die ehrliche Grenze der korrigierten Version: Die Absicherung verifiziert das Flag, nicht die Freigabe. Cedar sieht, dass confirmed_by_presenter=true am Aufruf hängt. Sie kann nicht sehen, ob ein Sales-Vertreter zwei Turns zuvor tatsächlich eine Freigabe eingetippt hat, denn das ist Gespräch, und Gespräch liegt auf der falschen Seite der Grenze. Ein Modell, das das Flag ohne echte Freigabe dahinter anhängt, würde diese Absicherung passieren. Der Freigabe-Flow selbst liegt auf Prompt-Ebene; Cedars Beitrag ist enger und schärfer. Writes ohne das Flag können deterministisch nicht passieren, egal was das Modell erzählt. Writes mit einem fälschlich angehängten Flag liegen außerhalb ihrer Reichweite.

Es in Aktion beobachten

Eine Aussage über Enforcement sollte an der Enforcement-Grenze getestet werden, also habe ich beide Modi mit direkten MCP-Aufrufen gegen den eigenen Endpunkt des Gateways verifiziert, ganz ohne Modell in der Schleife. Das war eine bewusste Entscheidung, keine Abkürzung. Ein Modell zu einem fehlerhaften Tool-Aufruf zu überreden beweist, dass das Modell an diesem bestimmten Tag kompromittierbar ist; es beweist nichts über die Policy. Ein selbst konstruierter, signierter Aufruf isoliert genau die eine Variable, um die es beim Test geht.

Die Verknüpfung auf Gateway-Ebene unterstützt zwei Modi, LOG_ONLY und ENFORCE [2]: Der erste wertet aus und protokolliert, der zweite wertet aus und blockiert. Unter LOG_ONLY erreichte ein handgebauter get_opportunity-Aufruf ohne opportunity_id weiterhin die Lambda, während die Auswertung einen DenyDecisions-Zähler von 1 aufzeichnete. Das ist der Vertrag: Die Ablehnung existiert nur als Metrik, während der Aufruf trotzdem durchgeht, was LOG_ONLY zum sicheren ersten Gang für ein Policy-Set macht, das man noch nicht gegen echten Traffic beobachtet hat. Nach diesem Rauchtest wurde der Modus umgeschaltet. In der Konsole ist das der Enforcement-Modus auf der Policy-Engine-Verknüpfung des Gateways; im automatisierten Build ist es ein Attribut:

policy_engine_configuration {  arn  = aws_bedrockagentcore_policy_engine.pc.policy_engine_arn  mode = "ENFORCE"}

Unter ENFORCE wurde derselbe fehlerhafte Aufruf abgelehnt, bevor die Lambda überhaupt lief, null protokollierte Lambda-Invocations, mit einem expliziten MCP-Fehler, der die feuernde Policy benennt, während ein wohlgeformter Aufruf im selben Setup weiterhin die echte API von Partner Central erreichte.

Die Write-Absicherung übersprang ihre eigene LOG_ONLY-Phase, und der Grund ist ein Befund aus dem Automatisierungspfad, keine Präferenz. Ein Enforcement-Modus pro Policy existiert in der imperativen API, aber der Terraform-Provider legt ihn nicht offen (im Resource-Schema erscheint nur validation_mode), sodass der Modus auf Gateway-Ebene der einzige Staged-Rollout-Regler dieses Builds ist. Als die Write-Absicherung live ging, stand dieser Modus bereits auf ENFORCE und schützte die laufende get_opportunity-Absicherung. Die Absicherung wurde stattdessen unter ENFORCE verifiziert: ein direkter tools/call an hs-write___upsert_contact ohne confirmed_by_presenter, unter komplettem Umgehen des Modells, kam mit Ablehnung zurück, pc_hubspot_upsert_contact_requires_confirmation im Fehler benannt.

Wissen, wo man hinschaut: Das Signal sind Metriken, keine Logs. Policy-Entscheidungen tauchen im CloudWatch-Metrik-Namespace AWS/Bedrock-AgentCore als DenyDecisions und AllowDecisions auf, mit den Dimensionen Policy, Mode und TargetResource [6]. Es gibt keine nach der Policy Engine benannte Log-Gruppe zu durchsuchen; ich habe nachgesehen, eine solche Log-Gruppe wird nie befüllt. Span-genaue Details zu einzelnen Ablehnungen würden Gateway-Tracing erfordern.

Übertragbare Muster

Fünf Gewohnheiten aus diesem Subsystem lassen sich auf jeden AgentCore-Build übertragen, ob konsolengeführt oder automatisiert.

• Default-Deny erzwingt Permit-vor-Forbid, explizit geordnet. Eine Default-Deny-Engine nur mit den gewünschten Forbid-Regeln zu verknüpfen blockiert jeden Aufruf auf jedes Target, und der Service verweigert das Policy-Set bereits bei der Erstellung. Schreiben Sie zuerst ein Baseline-Permit für jedes bestehende Target. Ordnen Sie es in Terraform mit einem expliziten depends_on, denn zwischen einem Forbid und dem Permit existiert keine Attribut-Referenz, aus der der Graph das ableiten könnte.
• Benennen Sie, was eine Kontrolle nicht sehen kann, im selben Dokument, das sie einführt. Cedar hat keinen turnübergreifenden Gesprächszustand. Diese Grenze klar zu benennen kostet einen Absatz und bewahrt Leser davor anzunehmen, eine Policy Engine schließe jede Lücke, die ein System-Prompt offenlässt.
• Verifizieren Sie eine Policy, indem Sie das Modell umgehen. Ein direkter Aufruf gegen den eigenen Endpunkt des Gateways beweist eine Enforcement-Entscheidung. Ein modellgetriebener Test beweist nur das Verhalten des Modells an diesem Tag.
• Suchen Sie nach Metriken, nicht nach einer nach der Policy benannten Log-Gruppe. Das Live-Signal sind DenyDecisions/AllowDecisions im Namespace AWS/Bedrock-AgentCore.

Wenn Sie das nachbauen

Vier konkrete Hinweise, um dieses Subsystem selbst aufzubauen, alle aus der eigenen Historie dieses Builds.

Erstens: Legen Sie zuerst das Baseline-Permit an, dann jedes Forbid, unabhängig vom gewählten Weg. Die Analyse zur Erstellungszeit weist ein reines Forbid-Policy-Set serverseitig zurück, die Reihenfolge-Regel gilt also in der Konsole genauso wie in Terraform; Automatisierung fügt lediglich den zusätzlichen Schritt hinzu, die Reihenfolge mit depends_on zu fixieren, da die beiden Policy-Ressourcen keine gemeinsame Attribut-Referenz teilen.

Zweitens: Gewähren Sie der Execution-Role des Gateways von Anfang an den vollständigen Satz an Policy-Engine-Berechtigungen. Die benötigten IAM-Actions und die zugehörigen Ressourcen sind in der folgenden Tabelle zusammengefasst:

Während der Umsetzung führten die fehlenden Berechtigungen zu fünf einzelnen Live-Fehlern, die erst durch die vorab erteilten fünf Actions behoben wurden. Konstruieren Sie den Gateway-bezogenen ARN aus der Account-ID und dem statischen Gateway-Namen mit einem Wildcard-Suffix; verzichten Sie auf Referenzen auf das Ressourcen-Attribut, um Abhängigkeitszyklen zu vermeiden, und verlassen Sie sich nicht auf einen aus einem früheren Apply erfassten wörtlichen ARN, da dieser bei einer Neuerstellung der Ressource brechen kann. Schlägt PartiallyAuthorizeActions unmittelbar nach dem Erteilen der Berechtigungen fehl, geben Sie sich vor der weiteren Fehlersuche etwas Zeit, da zwei der beobachteten Fehler auf IAM-Propagationsverzögerungen zurückgingen, nicht auf fehlende Berechtigungen.

Drittens: Behandeln Sie die Action-Liste des Permits als von Hand gepflegten Vertrag. Die Strings im Cedar-Statement sind vom Name-Attribut jedes Gateway-Targets getrennt, ein Umbenennen eines Targets lässt es also stillschweigend aus dem Permit fallen, und unter Default-Deny bedeutet das: Jeder Aufruf an das umbenannte Target schlägt fehl, entdeckbar nur live, nie durch terraform plan.

Viertens: Planen Sie Ihre Verifikation um Metriken und einen direkten Aufruf, wie oben beschrieben. Wenn Sie Details je Ablehnung über die Metrik-Dimensionen hinaus brauchen, planen Sie die Aktivierung von Gateway-Tracing ein; die Policy Engine liefert das sonst nicht.

Was das für die nächsten Artikel bedeutet

Dieser Artikel hat gezeigt, was AgentCore Policy und Cedar in diesem Projekt leisten und wo ihre Grenzen liegen. Artikel 6 baut direkt darauf auf: Die Managed Knowledge Base wird an dasselbe Gateway angebunden, und ihr Retrieval unterliegt denselben policy-gesteuerten Grenzen wie die CRM-Writes hier. Der letzte Artikel zeigt die vollständige Konversation live, inklusive des Freigabe-Flows und der deterministischen Absicherungen aus diesem Artikel.

Die ehrliche Einschätzung zu AgentCore Policy ist Verkaufsargument und Warnhinweis in einem: zwei Absicherungen, die kein Prompt umgehen kann, die aber jeweils genau einen Aufruf beurteilen und blind sind für alles, was das Gespräch weiß.

Ich hoffe, dieser Artikel war hilfreich für Sie. Ich freue mich über Feedback, was Ihnen gefallen hat und was nicht, damit ich künftige Artikel verbessern kann.

Quellen

[1] Cedar-Dokumentation zur Policy-Sprache: Autorisierungssemantik (eine Anfrage wird nur erlaubt, wenn mindestens ein Permit zutrifft und kein Forbid; ein explizites Forbid hat immer Vorrang vor jedem Permit; die Standardentscheidung ist Deny) sowie die Semantik des has-Operators, der nur die Anwesenheit eines Schlüssels prüft. https://docs.cedarpolicy.com/

[2] Amazon Bedrock AgentCore Developer Guide, Policy enforcement modes: die Enforcement-Modi LOG_ONLY und ENFORCE der Policy-Engine-Verknüpfung am Gateway. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-enforcement-modes.html

[3] Amazon Bedrock AgentCore Developer Guide, example policies: durchgearbeitete Beispiele, die Input-Guard-Forbid-Regeln mit Baseline-Permits kombinieren, sowie Actions auf Target-Ebene, die die unter einem Gateway-Target registrierten Tools gruppieren. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/example-policies.html

[4] Amazon Bedrock AgentCore Developer Guide, Policy core concepts: was eine Policy auswertet (der aufrufende Principal und der Input des Tool-Aufrufs) sowie das Default-Deny-Verhalten. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-core-concepts.html

[5] AWS IAM User Guide, „The confused deputy problem", einschließlich der aws:SourceAccount-Mitigation für serviceübergreifendes Vertrauen. https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html

[6] Amazon Bedrock AgentCore Developer Guide, Policy observability data: die Invocation-Metriken AllowDecisions / DenyDecisions im CloudWatch-Namespace AWS/Bedrock-AgentCore, mit den Dimensionen Policy, Mode und TargetResource. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-policy-metrics.html