Amazon Bedrock AgentCore: Mit welcher Identität Agenten auf Firmendaten zugreifen

Ein Vertriebsagent soll offene Angebote aus dem CRM und Lieferstände aus dem ERP zusammenfassen. Mit wessen Rechten liest er: mit denen der Person, die fragt, oder mit einem eigenen Dienstkonto, das alles sieht? Der Beitrag richtet sich an Plattform- und Sicherheitsteams, die Agenten auf AWS betreiben wollen und diese Frage für ERP, CRM oder Ticketsysteme beantworten müssen. Sinnvoll beginnt man nicht bei der Laufzeit, sondern bei der Identität: Erst wenn feststeht, mit wessen Rechten ein Agent handelt, lässt sich beurteilen, welche Daten er sehen und welche Aktionen er auslösen kann.

Was AgentCore ist und wo es im AWS-Angebot steht

Laut AWS-Dokumentation ist Amazon Bedrock AgentCore eine Plattform, um Agenten zu bauen, zu betreiben und zu überwachen, mit beliebigen Frameworks wie Strands Agents, LangGraph oder CrewAI und mit Modellen innerhalb und außerhalb von Bedrock. Die Dienste lassen sich einzeln nutzen: Runtime als Laufzeit mit isolierter microVM je Sitzung, Gateway, das APIs und Lambda-Funktionen zu MCP-Werkzeugen macht, Memory, Identity, Policy, Browser, Code Interpreter, Observability und Evaluations.

Im Angebot von AWS liegt AgentCore damit eine Ebene unter den fertigen Agenten. Amazon Bedrock liefert die Modelle, deren EU-Verarbeitung wir im Bedrock-EU-Check eingeordnet haben. Bedrock Managed Agents mit OpenAI setzt als verwalteter Agent auf AgentCore auf. Kiro und Strands sind Werkzeuge für Entwicklung und Agentenbau. Nicht abgedeckt sind hier die Modellwahl und die Qualität der Agenten. Den Überblick gibt die Seite Amazon AWS für Unternehmen.

Drei Identitätsfragen für jeden Agenten

AgentCore trennt drei Stellen, an denen Identität eine Rolle spielt. Die eingehende Autorisierung regelt, wer ein Gateway aufrufen darf: über IAM, über ein JWT eines Identitätsanbieters wie Entra ID oder Okta oder ausgelagert an ein nachgelagertes System. Die Ausführungsrolle legt fest, was der Agent in der Runtime selbst in AWS darf. Die ausgehende Autorisierung bestimmt, mit welchen Rechten das Gateway auf Zielsysteme zugreift.

Redaktionelle, schematische Darstellung auf Basis der AgentCore-Dokumentation, kein Produkt-Screenshot. Policy greift nur bei Aufrufen über das Gateway.

Welches Muster für welchen Zugriff passt

Für die ausgehende Seite bietet AWS mehrere Muster an, nicht jedes für jedes Ziel. Lambda-Funktionen etwa lassen nur die Dienstrolle zu, MCP-Server und OpenAPI-Ziele auch OAuth-Varianten. Die Wahl ist eine fachliche Entscheidung, keine technische Feinheit:

Eigene Zusammenfassung der AWS-Dokumentation zur ausgehenden Autorisierung, Stand 8. November 2026. Welche Muster je Zieltyp möglich sind, zeigt dort eine Tabelle.

„Im Namen der Person“ heißt dabei nicht, dass der Agent die Person ist. Beim Token-Austausch tauscht das Gateway laut AWS das Token der angemeldeten Person gegen ein neues, auf ein Zielsystem eingeschränktes Token, das sowohl die Person als auch den Agenten ausweist. Das Zielsystem kann so bei jedem Schritt prüfen, wer fragt und über welchen Agenten. AgentCore vergibt selbst keine Rechte: Was erlaubt ist, entscheiden weiter das Zielsystem und der Identitätsanbieter.

Die Zugangsdaten verwaltet AgentCore Identity laut Funktionsbeschreibung in einem Token-Tresor, verschlüsselt mit AWS- oder eigenen KMS-Schlüsseln. Jeder Agent erhält eine eigene Workload-Identität mit ARN, über die sich Richtlinien für Gruppen von Agenten setzen lassen. Für Google, GitHub, Slack, Salesforce und Jira gibt es vorkonfigurierte Anbieter.

Regeln außerhalb des Agentencodes: Policy

Policy in AgentCore prüft jeden Werkzeugaufruf, der über ein Gateway läuft, gegen Regeln in der Sprache Cedar, bevor das Werkzeug erreicht wird. Regeln können sich auf Person, Werkzeug und Eingabeparameter beziehen und auf den bisherigen Verlauf einer Sitzung, etwa eine erforderliche Freigabe vor einer Überweisung oder eine Obergrenze für die Zahl der Aufrufe. Jede Entscheidung wird in CloudWatch protokolliert. Regeln lassen sich auch in natürlicher Sprache formulieren; AWS prüft die erzeugten Regeln dann automatisch auf zu weite oder unerfüllbare Bedingungen.

Das ist genau die Trennung, die für agentische Systeme nötig ist: Technische Grenzen gelten unabhängig davon, was das Modell plant, und eine menschliche Freigabe bewertet nur noch den Einzelfall innerhalb dieser Grenzen. Die Grenze von Policy ist aber ebenso klar: Sie greift nur für Verkehr über das Gateway. Ruft ein Agent ein System an der Gateway-Schicht vorbei auf, etwa direkt mit seiner Ausführungsrolle, prüft Policy nichts. Policy ersetzt deshalb weder eng geschnittene Ausführungsrollen noch Netzwerkgrenzen, die Verwaltung von Zugangsdaten oder einen Ablauf für Sicherheitsvorfälle. Wie sich Agenten zusätzlich in einer Sandbox begrenzen lassen, zeigt der Beitrag zu Strands Box.

Ein hypothetisches Beispiel: Ein Großhändler baut einen Agenten, der Vertriebsmitarbeitern offene Angebote und Lieferstände aus Salesforce und dem ERP zusammenfasst. Mit einer Dienstrolle sähe jede Person die Angebote aller Kollegen, weil das ERP nur den Agenten kennt. Mit Token-Austausch im Namen der Person gelten die Berechtigungen aus dem ERP weiter. Eine Policy-Regel erlaubt zusätzlich nur lesende Werkzeuge, und ein Rabatt über einer festgelegten Grenze braucht eine Freigabe in der Sitzung.

Region und Kosten

Laut Regionstabelle stehen Runtime, Gateway, Identity, Policy, Memory, Observability und Evaluations in Frankfurt und Irland zur Verfügung. Die eingebaute Websuche gibt es in Europa nur in Irland, das Agentenregister nur in Frankfurt, Irland und London. Welche Modelle mit welchem Profil in der EU laufen, ist eine eigene Frage und gehört in den Bedrock-Teil des Pilots.

Abgerechnet wird nach Verbrauch. Die Preisseite nennt für Runtime-microVMs der ersten Generation 0,0895 US-Dollar je vCPU-Stunde und 0,00945 US-Dollar je GB-Stunde Arbeitsspeicher, für Gateway-Aufrufe 0,005 US-Dollar je 1.000 und für Policy 0,000025 US-Dollar je Prüfung (Stand 8. November 2026). Identity kostet nichts zusätzlich, wenn es über Runtime oder Gateway genutzt wird. Modellaufrufe, CloudWatch und Speicher kommen hinzu. Laut AWS fällt bei der Runtime während des Wartens auf Modellantworten und Werkzeuge keine CPU-Gebühr an, Arbeitsspeicher wird aber weiter berechnet. Gerade lang laufende Agenten mit vielen Werkzeugaufrufen brauchen deshalb ein Budget mit Alarm, bevor sie produktiv gehen.

Eine eigene Beispielrechnung mit angenommenen Werten: Eine Sitzung läuft 10 Minuten mit 1 vCPU und 2 GB Arbeitsspeicher, davon 1 Minute aktive Rechenzeit, und ruft 10 Werkzeuge über das Gateway auf, jeweils mit Policy-Prüfung. Nach den Listenpreisen der ersten Generation kostet das rund 0,005 US-Dollar je Sitzung, für 1.000 Sitzungen also rund 5 US-Dollar. Modellaufrufe, CloudWatch und Memory sind darin nicht enthalten und separat zu rechnen.

Daten, Protokolle und Löschung

AgentCore Memory speichert Gesprächsereignisse und leitet daraus Langzeiteinträge ab, etwa Vorlieben, wichtige Fakten oder Zusammenfassungen. Für die Ereignisse verlangt die API-Referenz beim Anlegen eine Ablaufzeit zwischen 3 und 365 Tagen. Für die abgeleiteten Langzeiteinträge haben wir eine solche Frist nicht gefunden; ihre Löschung gehört deshalb ausdrücklich ins Löschkonzept, ebenso die Aufbewahrung von CloudWatch- und CloudTrail-Protokollen.

Vertraglich gilt für AWS-Dienste der AWS-Auftragsverarbeitungsvertrag mit den Standardvertragsklauseln, wie AWS in seinem DSGVO-Center beschreibt. Zweck, Rechtsgrundlage und Datenminimierung bleiben eigene Prüfungen: Ein Agent sollte nur die Werkzeuge und Daten erhalten, die sein Zweck verlangt.

Pilotfragen vor dem Einsatz

1. Mit welcher Identität greift jeder Agent auf welches Zielsystem zu, und wer hat dieses Muster freigegeben?
2. Ist GetWorkloadAccessTokenForUserId in Produktion verboten, und enthalten unsere JWT keine Klarnamen oder E-Mail-Adressen?
3. Laufen alle Werkzeugaufrufe über das Gateway, sodass Policy sie prüfen kann, oder gibt es Zugriffe an ihm vorbei?
4. Welche schreibenden Aktionen erlauben wir, und welche brauchen eine Freigabe innerhalb der Sitzung?
5. Welches Budget gilt je Agent, wer erhält den Alarm, und was passiert bei Überschreitung?

Kleine Teams starten mit einem lesenden Agenten, einem Zielsystem, Token-Austausch im Namen der Person und wenigen Policy-Regeln. Wer mehrere produktive Agenten betreibt, ergänzt ein Register der Agentenidentitäten, regelmäßige Rechteprüfung und Tests mit Prompt-Injection gegen die Werkzeugkette. Der Betriebsrat ist zu beteiligen, sobald Protokolle Rückschlüsse auf das Verhalten einzelner Beschäftigter zulassen.

Fazit: Erst die Identität entscheiden, dann den Agenten bauen

Quellen

Weiterführende Artikel auf AI-Fabrik