Ein Agent, der auf AWS oder gegen AWS läuft, sollte niemals ein langlebiges Credential halten. Kein IAM-User, kein Access Key in einem Secrets Manager, kein geteilter "agents"-Service-Account. Jeder ernstzunehmende Authentifizierungspfad, den AWS anbietet, Instance Profiles, IRSA, EKS Pod Identity, OIDC-Föderation, IAM Roles Anywhere, AgentCore Identity, existiert für genau dasselbe Ziel: einen verifizierbaren Identitätsnachweis gegen temporäre Credentials zu tauschen, die von selbst ablaufen. Wenn deine Agent-Plattform mit dieser Regel startet, beantworten sich die meisten schweren Fragen von allein.

Gestern habe ich auf der Schwesterseite über die Protokollebene dieses Problems geschrieben: SEP-1046 gibt MCP-Agents endlich eine echte Client-Credentials-Geschichte, mit signierten JWT-Assertions statt geteilter Secrets. Dieser Post ist die Ebene darunter: Wenn das Ziel des Agents AWS selbst ist, oder der Agent auf AWS läuft und alles andere erreichen muss, wie sieht seine Identität dann konkret aus? Die Antwort hat in fast jedem Fall dieselbe Form, die auch SEP-1046 gewählt hat: ein kurzlebiges signiertes Token rein, kurzlebige Credentials raus. AWS betreibt dieses Muster seit Jahren im großen Maßstab. Man muss nur aufhören, es mit statischen Keys zu bekämpfen.

Ein Muster unter allem: OIDC-Föderation

Zieht man die Produktnamen ab, ist Agent-Auth auf AWS ein einziger Mechanismus. Ein Identity Provider signiert ein JWT über einen Workload. Du registrierst die Issuer-URL dieses Providers in IAM als OIDC Identity Provider; IAM holt die öffentlichen Schlüssel über die jwks_uri des Providers aus dem Discovery-Dokument unter /.well-known/openid-configuration. Der Workload legt sein Token bei sts:AssumeRoleWithWebIdentity vor und bekommt Rollen-Credentials, die innerhalb einer Stunde ablaufen. Die Trust Policy der Rolle legt mit Bedingungen auf den aud- und sub-Claims des Tokens fest, wer hineinkommt.

Die Variante, die jedes Platform-Team schon kennt, ist GitHub Actions: Der Runner bekommt ein OIDC-Token, dessen sub-Claim Repo und Branch kodiert, die Trust Policy der Rolle matcht repo:my-org/my-repo:ref:refs/heads/main, und kein Access Key liegt jemals in den Repository Secrets. Das ist kein CI-Trick. Es ist die Vorlage für jeden unbeaufsichtigten Workload, Agents eingeschlossen. Eine signierte, audience-gebundene, minutenlang gültige Assertion statt eines gespeicherten Secrets ist exakt das, was private_key_jwt auf der MCP-Ebene tut; die Branche ist aus zwei Richtungen bei einer Antwort gelandet, und das ist meistens das Zeichen, dass die Antwort stimmt.

Wo der Agent läuft, entscheidet über den Mechanismus

Die Föderation baust du selten selbst. Du wählst die Verpackung, die zur Laufzeitumgebung passt:

  • Auf EC2 oder ECS: Instance Profile oder Task Role. Die Credential Chain des SDK greift sie automatisch ab, im Agent ist nichts zu konfigurieren. Wenn dein Agent-Framework hier nach einem Access Key fragt, ist das ein Geruch im Framework, keine AWS-Anforderung.
  • Auf EKS: zwei Optionen. IRSA (IAM Roles for Service Accounts) ist die ältere: Der Cluster stellt einen OIDC-Issuer bereit, du registrierst ihn in IAM und annotierst einen ServiceAccount mit einer Rollen-ARN. EKS Pod Identity ist die neuere: keine OIDC-Provider-Registrierung pro Cluster, ein Agent-Add-on auf dem Node tauscht die Credentials, und die Trust Policy der Rolle zielt einmalig auf pods.eks.amazonaws.com statt auf Issuer-URLs pro Cluster. Für eine Flotte von Clustern beseitigt Pod Identity echten Aufwand; für einen einzelnen Cluster geht beides. Beide enden am selben Punkt: eine IAM-Rolle pro Agent-Workload, keine Keys im Pod.
  • Außerhalb von AWS, mit IdP: schlichte OIDC-Föderation wie oben. Dein Datacenter-Workload, deine andere Cloud, dein SaaS-Runner authentifiziert sich beim eigenen Identity Provider und föderiert hinein. Das ist das GitHub-Actions-Muster, verallgemeinert.
  • Außerhalb von AWS, ohne IdP: IAM Roles Anywhere. Dein Workload legt ein X.509-Zertifikat einer CA vor, die du als Trust Anchor registriert hast (AWS Private CA oder deine eigene PKI), und tauscht es über ein Profil gegen temporäre Rollen-Credentials. Der ehrliche Vorbehalt: Du erbst das Zertifikats-Lifecycle-Management, Ausstellung, Rotation, Widerruf. Wer nicht ohnehin PKI betreibt, fährt mit dem Aufsetzen eines Identity Providers meist mit weniger Betriebslast als mit der Einführung einer PKI.

AgentCore Identity: die agentenförmige Schicht darüber

IAM beantwortet "wie ruft dieser Workload AWS auf". Agents haben zwei Probleme mehr: wer den Agent aufrufen darf, und wie der Agent Nicht-AWS-Dienste, Slack, GitHub, Google, im Auftrag eines Users erreicht. Genau diesen Ausschnitt deckt Amazon Bedrock AgentCore Identity ab, und er lohnt das Verständnis auch dann, wenn du AgentCore nie betreibst, denn hier schreibt AWS auf, was Agent-Identität jenseits einer Rolle braucht.

  • Workload-Identitäten für Agents. Jeder Agent bekommt einen eigenen Verzeichniseintrag, keinen geteilten Principal. Dieselbe Regel wie bei IAM-Rollen, eine Identität pro Workload, eine Ebene höher angewendet.
  • Eingehende Auth. Aufrufer erreichen den Agent entweder mit schlichtem SigV4 (IAM wie üblich) oder über einen JWT-Authorizer: Du konfigurierst eine Discovery-URL und erlaubte Audiences, und Tokens von Cognito, Okta oder Entra ID sichern den Agent ab. AgentCore Gateway bietet denselben CUSTOM_JWT-Authorizer für Tool-Endpoints an, und so validiert ein MCP-artiges Gateway auf AWS die Tokens, um deren Ausstellung es im vorigen Post ging.
  • Ausgehende Auth. Ein Token Vault hält OAuth-Grants für Drittanbieterdienste, zweibeinig für Service-zu-Service, dreibeinig dort, wo ein User einmal zugestimmt hat und der Agent später auf Basis dieser Zustimmung handelt. Das ist das Acting-on-behalf-of-Muster mit serverseitig gespeicherter Zustimmung statt eines in eine Umgebungsvariable kopierten Refresh Tokens.
  • Fußnote zum Preis. Über AgentCore Runtime oder Gateway kostet es nichts extra; standalone wird pro erfolgreichem OAuth-Token- oder API-Key-Request abgerechnet. So oder so billig; teuer war schon immer der Incident, den man damit vermeidet.

Auch die Protokollschicht darüber bewegt sich weiter. Die auth-Queue des MCP-Spec-Repos enthält Vorschläge, denen dein Gateway innerhalb eines Jahres begegnen wird: securitySchemes in den Tool-Metadaten für Mixed-Auth-Server (SEP-1488), standardisierte Tool-Fehler, die mitten in der Session einen OAuth-Flow auslösen (SEP-1489), und vorab deklarierte Authentifizierungsmethoden für Remote-Server (SEP-2742). Wer ein MCP-Gateway auf AWS betreibt, sollte dieses Label so verfolgen wie die EKS-Release-Notes.

Attribution ist der Teil, nach dem Audits wirklich fragen

Temporäre Credentials lösen den Diebstahl; sie lösen nicht von selbst die Frage "welcher Agent war das". Drei Gewohnheiten schließen die Lücke. Eine Rolle pro Agent, damit die Role Session in CloudTrail den Workload bereits benennt. sts:SourceIdentity beim Annehmen der Rolle gesetzt, damit der Mensch oder das System, das den Agent ausgelöst hat, auch über Role Chaining hinweg in jeder nachgelagerten Logzeile überlebt. Und Session Policies, die eine breite Rolle auf die aktuelle Aufgabe eingrenzen, damit der Schadensradius eines prompt-injizierten oder schlicht fehlerhaften Agents die Rechte der Aufgabe ist, nicht die der Rolle. Halte die stehenden Berechtigungen read-only und sichere jede verändernde Aktion ab; dieses Argument habe ich oft genug gemacht, dass Stammleser es mitsprechen können.

Was am Montag zu tun ist

  • Führe aws iam list-users aus und behandle jeden IAM-User mit aktiven Access Keys, der zu einer Automatisierung gehört, als Finding. Agents sind Automatisierungen.
  • Ordne jeden Agent seiner Laufzeitumgebung zu und übernimm den passenden Mechanismus: Instance/Task Roles, IRSA oder Pod Identity, OIDC-Föderation, Roles Anywhere. In dieser Reihenfolge der Präferenz.
  • Pinne jede OIDC Trust Policy auf aud und das engste sub-Muster, das du formulieren kannst. Eine Trust Policy ohne sub-Bedingung ist eine offene Tür mit hübschem Schild.
  • Setze sts:SourceIdentity in jedem Assume-Role-Aufruf deiner Agents und lass deine CloudTrail-Queries darauf aufsetzen. Attribution nach einem Incident nachzurüsten funktioniert nicht.
  • Wenn du auf AgentCore bist, stelle den JWT-Authorizer vor die Agents und verschiebe Drittanbieter-OAuth-Grants in den Token Vault. Wenn nicht, kopiere die Form: Identität pro Agent, validierte eingehende Tokens, serverseitig gespeicherte Zustimmung.

Der rote Faden zum MCP-Stück ist kaum zu übersehen. Protokoll für Protokoll, Plattform für Plattform konvergiert Agent-Identität auf signierte kurzlebige Assertions, Audience-Bindung und Principals pro Workload, und die Bausteine existieren jetzt auf beiden Ebenen. Die Teams, die weiterhin Access Keys in Agent-Configs kopieren, sind keine Early Adopter von irgendetwas. Sie fahren die Security-Haltung von 2015 gegen Workloads von 2026.

Lies das als Nächstes

Agent Toolkit for AWS: The Docs Have a New Reader zeigt, was diese authentifizierten Agents mit ihrem AWS-Zugriff tatsächlich anfangen. Auf der Schwesterseite ist Enterprise MCP Auth: Agents Finally Get Service Accounts die Protokollhälfte dieses Posts, und ercanermis.com kartiert alles andere, was ich schreibe.

Referenzen