AWS Bedrock AgentCore: Zu weit gefasste Rollen geben Prompts zu viel Macht über die Cloud
Wer Agents auf AWS Bedrock AgentCore betreibt, sollte prüfen, was die Execution Role tatsächlich darf. Ist die Rolle die AgentCore-Standardrolle, kann im schlimmsten Fall ein einzelner Prompt weitreichende Cloud-Rechte ausnutzen.
Veröffentlicht am 15. Okt. • Zuerst erschienen auf dekita-ai.pages.dev
Beginnen Sie hier: finden Sie heraus, was die Execution-Rolle Ihres Agenten tatsächlich leisten darf. Wenn Sie Agenten auf AWS Bedrock AgentCore betreiben, führen Sie diese beiden Befehle aus und lesen Sie die Berechtigungen, die sie zurückgeben:
aws iam list-attached-role-policies --role-name <your-agentcore-exec-role> aws iam list-role-policies --role-name <your-agentcore-exec-role> Enter fullscreen mode Exit fullscreen mode Wenn diese Rolle die Standard-Execution-Rolle von AgentCore ist, kann die Ausgabe Berechtigungen enthalten, die weit über den einen von Ihnen bereitgestellten Agenten hinausreichen. Diese Lücke ist nicht theoretisch. Im Oktober 2026 zeigte ein Sicherheitsteam, dass ein einzelner Chat-Prompt an einen offengelegten Agenten ausreichte, um jeden Bedrock AgentCore Agenten im selben AWS-Konto und in derselben Region zu übernehmen.
Dieser Beitrag erklärt den Befund in einfachen Worten und liefert Ihnen eine Checkliste, die Sie heute auf Ihre eigene Rolle anwenden können. Keine neuen Tools, keine Plattformmigration.
Die Untersuchung (Zenity Labs, veröffentlicht am 8. Oktober 2026 und präsentiert auf der SecTor 2026) richtete sich gegen AWS Bedrock AgentCore, Amazons verwaltete Plattform für den Betrieb von Produktionsagenten. Das Team fand zwei Probleme, die sich gegenseitig verstärken.
Erstens konnte ein Agent, der innerhalb von AgentCore lief, auf den Instance-Metadata-Service (IMDS) unter der Link-Local-Adresse 169.254.169.254 zugreifen. AgentCore betreibt jeden Agenten in einer leichten microVM, die den Netzwerkverkehr nicht so isolierte, wie es eine normale Compute-Instanz tut. Dadurch wurde jedes Agent-Tool, das HTTP-Anfragen stellen kann, zu einer Primitive für Server-Side Request Forgery: Eine von ihm ausgehende Anfrage stammt aus dem Inneren der Instanz, sodass IMDS sie mit den temporären IAM-Credentials der eigenen Rolle des Agenten beantwortet. Ein sorgfältig formulierter Prompt genügte, um den Agenten dazu zu bringen, diese Credentials abzurufen und zurückzugeben.
Zweitens war die standardmäßig an AgentCore-Workloads angehängte IAM-Rolle überprivilegiert. Sie war nicht auf einen einzelnen Agenten beschränkt. Sie trug weitreichende Berechtigungen über alle AgentCore-Ressourcen in der Region des Kontos hinweg: das Aufrufen anderer Agenten, das Lesen von Sessions, das Erstellen von Memories und das Lesen von Secrets aus dem AWS Secrets Manager.
Setzt man beides zusammen, ist der betroffene Bereich die gesamte Region. Ein offengelegter Agent plus ein Prompt bedeutet die Fähigkeit zu:
Der Offenlegungsverlauf ist für das Vertrauen relevant. Der IMDS-Zugriff wurde am 25. Dezember 2025 an AWS gemeldet; AWS schloss ihn im April 2026 als "informative" ab, nachdem neu bereitgestellte Agenten auf IMDSv2 umgestellt worden waren. Der Bericht über die überprivilegierte Rolle wurde am 12. Januar 2026 eingereicht; AWS bestätigte am 29. September 2026 eine substanzielle Härtung der Standard-Execution-Rolle. AWS' öffentliche Position ist, dass das Verhalten "dokumentiert und erwartet" sei: Ein Agent kann nur dann auf Ressourcen in einem anderen Konto zugreifen, wenn der Entwickler explizit auf beiden Seiten Berechtigungen erteilt. Ihre Empfehlung ist unverändert und korrekt: Gewähren Sie Execution-Rollen nur die Berechtigungen, die der Agent benötigt.
Ein Hinweis für Teams mit bestehenden Deployments: AWS' Härtung im September 2026 änderte die Standardeinstellung für neu erstellte Rollen. Vor diesem Datum bereitgestellte Agenten tragen möglicherweise weiterhin die alte breite Rolle, da AWS eine bereits angehängte Rolle nicht rückwirkend umschreibt. Wenn Ihr Agent vor Ende September 2026 eingerichtet wurde, gehen Sie davon aus, dass die Rolle weiterhin zu weit gefasst ist, bis Sie sie selbst mit den oben genannten Befehlen prüfen.
Sie haben die Standardrolle von AgentCore nicht geschrieben. Aber Sie haben sie an Ihren Agenten angehängt oder akzeptiert. Die Lehre lautet nicht "AWS ist unsicher". Die Lehre ist, dass der Credential-Scope eines Agenten eine Produktsentscheidung ist, die in Ihrer Verantwortung liegt, und die meisten Teams legen sie einmal fest und überdenken sie nie wieder.
Agenten sind keine Webserver. Ein Webserver verarbeitet jeweils eine Anfrage und hat keine Session, die man steuern kann. Ein Agent hält eine Session, ruft Tools auf und kann durch Inhalte umgeleitet werden, die er aus dem Web, aus einem Dokument oder von einem anderen Agenten bezieht. Dieselbe Prompt-Injection, die früher bedeutete "das Modell hat etwas Falsches gesagt", bedeutet jetzt "das Modell hat Ihre Credentials verwendet." Wenn die Rolle weit gefasst ist, wird eine einzige schlechte Eingabe zu einem Ereignis auf Kontoebene und nicht zu einem containeden Fehler.
Betrachten Sie einen realistischen Fall. Ihr Support-Agent hat ein Tool, das eine interne API abfragt. Diese API liegt im selben Konto wie ein zweiter Agent, der Kundendaten lesen kann, und ein dritter, der in soziale Kanäle posten kann. Wenn alle drei eine einzige breite Rolle teilen, endet eine manipulierte Anweisung an den Support-Agenten nicht bei der Support-API. Sie kann zum Kundendaten-Agenten und dann zum Posting-Agenten weiterspringen, weil die geteilte Rolle all dies erlaubt. Die Lösung sind keine intelligenteren Prompts. Die Lösung ist eine enger gefasste Rolle.
Sie müssen nicht auf eine Plattformkorrektur warten. Vier Maßnahmen verringern den betroffenen Bereich sofort.
1. Geben Sie jedem Agenten seine eigene Rolle. Teilen Sie keine Execution-Rolle über mehrere Agenten. Erstellen Sie eine dedizierte Rolle pro Agent und hängen Sie nur die Berechtigungen an, die die Tools dieses Agenten benötigen. Wenn Agent A keinen Grund hat, das Memory von Agent B zu lesen, darf seine Rolle bedrock-agentcore:CreateEvent auf gemeinsam genutztem Memory nicht erlauben.
2. Wenden Sie Least Privilege buchstabengetreu an. Beginnen Sie mit einer leeren Policy und fügen Sie je eine Berechtigung für jeden Tool-Aufruf hinzu, den Sie benennen können. Wenn Sie den Aufruf nicht benennen können, sollte der Agent die Berechtigung nicht halten. Prüfen Sie zuerst DescribeLogGroups und secretsmanager:GetSecretValue; das sind die beiden, die ein lokales Leck in ein regionales verwandeln.
3. Halten Sie Secrets aus der eigenen Rolle des Agenten heraus. Speichern Sie Anmeldeinformationen von Drittanbietern im AWS Secrets Manager und lassen Sie das AgentCore Gateway sie pro Tool vermitteln. Die Execution-Rolle des Agenten sollte secretsmanager:GetSecretValue nicht für Secrets halten, auf die er nur über ein Gateway zugreift.
4. Erzwingen Sie IMDSv2 und blockieren Sie den Metadata-Pfad. Starten Sie Agenten ausschließlich mit IMDSv2, was ein Token anstelle eines offenen PUT erfordert. Wo Ihre Laufzeitumgebung es erlaubt, verweigern Sie den ausgehenden Zugriff auf 169.254.169.254 aus der Execution-Umgebung des Agenten, damit ein Tool die Metadaten nicht erreichen kann, selbst wenn es dazu aufgefordert wird.
Eine minimale Least-Privilege-Rolle für einen einzelnen nur lesenden Agenten sieht so aus:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock-agentcore:InvokeAgentRuntime" ], "Resource": "arn:aws:bedrock-agentcore:<region>:<account>:agent/<this-agent-id>" } ] } Enter fullscreen mode Exit fullscreen mode Kein DescribeLogGroups. Kein secretsmanager:*. Nirgends *:*. Fügen Sie eine Anweisung pro Tool hinzu, begrenzt auf die exakte Ressource dieses Tools.
Nachdem Sie die Rolle verschärft haben, beweisen Sie es. Führen Sie die beiden aws-iam-Befehle von oben erneut aus und durchsuchen Sie die Ausgabe nach *:* und nach jeder bedrock-agentcore:*-Berechtigung, die weiter gefasst ist als dieser eine Agent. Führen Sie dann einen bewussten Negativtest durch: Versuchen Sie vom Agenten aus, eine Aktion aufzurufen, die die neue Rolle verweigern sollte, und bestätigen Sie, dass sie fehlschlägt. Wenn der Agent weiterhin andere Agenten auflisten oder Secrets lesen kann, ist die Rolle noch immer zu weit gefasst.
Machen Sie daraus eine wiederkehrende Prüfung, kein einmaliges Aufräumen. Fügen Sie die beiden aws-iam-Befehle einem geplanten Job oder einem CI-Schritt hinzu, der fehlschlägt, wenn eine Rolle breiter wird als ihre deklarierten Tools. Der Credential-Scope verschiebt sich, wenn Agenten neue Funktionen erhalten, daher muss die Prüfung so oft laufen wie die Agenten sich ändern.
Behandeln Sie die IAM-Rolle des Agenten als Teil seiner Spezifikation, nicht als Plattform-Boilerplate. Benennen Sie die Tools, benennen Sie die Berechtigungen, die jedes Tool benötigt, und prüfen Sie sie im selben Rhythmus wie die Prompts des Agenten. Ein einzelner Prompt sollte nie Ihre Cloud besitzen; die Rolle, die Sie anhängen, entscheidet, ob er es kann.
Dieser Beitrag wurde mit KI-Unterstützung verfasst. Der Autor ist für dessen Inhalt verantwortlich.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 15 • Originally published at dekita-ai.pages.dev
Start here: find out what your agent's execution role can actually do. If you run agents on AWS Bedrock AgentCore, run these two commands and read the permissions they return:
aws iam list-attached-role-policies --role-name <your-agentcore-exec-role> aws iam list-role-policies --role-name <your-agentcore-exec-role> Enter fullscreen mode Exit fullscreen mode If that role is the default AgentCore execution role, the output may list permissions that reach far beyond the one agent you deployed. That gap is not theoretical. In October 2026, a security research team showed that a single chat prompt to one exposed agent was enough to take over every Bedrock AgentCore agent in the same AWS account and region.
This post explains the finding in plain terms and gives you a checklist you can apply to your own role today. No new tools, no platform migration.
The research (Zenity Labs, published October 8, 2026, and presented at the SecTor 2026 conference) targeted AWS Bedrock AgentCore, Amazon's managed platform for running production agents. The team found two problems that stack on top of each other.
First, an agent running inside AgentCore could reach the instance metadata service (IMDS) at the link-local address 169.254.169.254. AgentCore runs each agent in a lightweight microVM that did not isolate network traffic the way a normal compute instance does. As a result, any agent tool that can make an HTTP request becomes a server-side request forgery primitive: a request it makes originates from inside the instance, so IMDS answers it with the temporary IAM credentials for the agent's own role. A carefully written prompt was all it took to make the agent fetch those credentials and hand them back.
Second, the default IAM role attached to AgentCore workloads was overprivileged. It was not scoped to a single agent. It carried broad permissions across every AgentCore resource in the account's region: invoking other agents, reading sessions, creating memories, and reading secrets from AWS Secrets Manager.
Put the two together and the blast radius is the whole region. One exposed agent plus one prompt equals the ability to:
The disclosure timeline matters for trust. The IMDS access was reported to AWS on December 25, 2025; AWS closed it as "informative" in April 2026 after moving newly deployed agents to IMDSv2. The overprivileged-role report was filed January 12, 2026; AWS confirmed substantial hardening of the default execution role on September 29, 2026. AWS's public position is that the behavior is "documented and expected": an agent can reach resources in another account only if the developer explicitly grants permissions on both sides. Their recommendation is unchanged and correct: grant execution roles only the permissions the agent needs.
One caveat for teams on existing deployments: AWS's September 2026 hardening changed the default for newly created roles. Agents deployed before that date may still carry the old broad role, because AWS does not retroactively rewrite a role you already attached. If your agent predates late September 2026, assume the role is still wide until you check it yourself with the commands above.
You did not write AgentCore's default role. But you attached it, or accepted it, to your agent. The lesson is not "AWS is unsafe." The lesson is that an agent's credential scope is a product decision you own, and most teams set it once and never revisit it.
Agents are not web servers. A web server handles one request at a time and has no session to steer. An agent holds a session, calls tools, and can be redirected by content it fetches from the web, from a document, or from another agent. The same prompt injection that used to mean "the model said something wrong" now means "the model used your credentials." When the role is broad, one bad input becomes an account-wide event, not a contained mistake.
Consider a realistic case. Your support agent has a tool that queries an internal API. That API lives in the same account as a second agent that can read customer records and a third that can post to social channels. If all three share one broad role, a poisoned instruction to the support agent does not stop at the support API. It can pivot to the customer-records agent and then to the posting agent, because the shared role permits all of it. The fix is not smarter prompts. The fix is a narrower role.
You do not need to wait for a platform fix. Four moves cut the blast radius now.
1. Give each agent its own role. Do not share one execution role across agents. Create a dedicated role per agent and attach only the permissions that agent's tools need. If agent A has no business reading agent B's memory, its role must not allow bedrock-agentcore:CreateEvent on shared memory.
2. Apply least privilege to the letter. Start from an empty policy and add one permission per tool call you can name. If you cannot name the call, the agent should not hold the permission. Review DescribeLogGroups and secretsmanager:GetSecretValue first; those are the two that turn a local leak into a regional one.
3. Keep secrets out of the agent's own role. Store third-party credentials in AWS Secrets Manager and let AgentCore Gateway broker them per tool. The agent's execution role should not hold secretsmanager:GetSecretValue for secrets it only reaches through a gateway.
4. Force IMDSv2 and block the metadata path. Launch agents with IMDSv2 only, which requires a token instead of an open PUT. Where your runtime allows it, deny outbound access to 169.254.169.254 from the agent's execution environment, so a tool cannot reach metadata even if it is prompted to.
A minimal least-privilege role for a single read-only agent looks like this:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock-agentcore:InvokeAgentRuntime" ], "Resource": "arn:aws:bedrock-agentcore:<region>:<account>:agent/<this-agent-id>" } ] } Enter fullscreen mode Exit fullscreen mode No DescribeLogGroups. No secretsmanager:*. No *:* anywhere. Add one statement per tool, scoped to that tool's exact resource.
After you tighten the role, prove it. Re-run the two aws iam commands from the top and grep the output for *:* and for any bedrock-agentcore:* permission scoped wider than this one agent. Then run a deliberate negative test: from inside the agent, try to call an action the new role should deny, and confirm it fails. If the agent can still list other agents or read secrets, the role is still too wide.
Make this a recurring check, not a one-time cleanup. Add the two aws iam commands to a scheduled job or a CI step that fails when a role grows wider than its declared tools. Credential scope drifts as agents gain features, so the check has to run as often as the agents change.
Treat the agent's IAM role as part of the agent's spec, not as platform boilerplate. Name the tools, name the permissions each tool needs, and review them on the same cadence as you review the agent's prompts. One prompt should never own your cloud; the role you attach decides whether it can.
This post was written with AI assistance. The author is responsible for its content.