Google Cloud startet IAM Helper: KI-Agenten übernehmen das Zugriffsmanagement

Was IAM Helper ist

Google Cloud beschreibt IAM Helper als agentennative Orchestrierungs- und Schnittstellenschicht für Google Cloud IAM. Sie ergänzt die zentralen IAM-Engines des Unternehmens, darunter Policy Intelligence und Privileged Access Manager (PAM), und macht IAM-Skills direkt für autonome Code-Assistenten, Deployment-Pipelines und individuelle Agenten abrufbar.

Das Problem, das IAM Helper adressieren soll, beschreibt das Unternehmen so: Entwickler, die Agenten Cloud-Ressourcen bereitstellen, Terraform schreiben und Microservices in Maschinengeschwindigkeit ausrollen lassen, sehen ihre CI/CD-Pipelines umso schneller blockiert, je stärker die Sicherheitsreibung skaliert. Die manuelle Fehlersuche bei Berechtigungsproblemen bremst Entwickler und Administratoren aus, während Abkürzungen zu einer zu weitreichenden Rechtevergabe an Agenten führen können, die das Least-Privilege-Prinzip gefährdet.

IAM Helper verlagert die Last der Richtlinienauswertung von menschlichen Administratoren und LLMs weg, so Google Cloud. Die komplexe Orchestrierung wird an das Google-Cloud-Backend ausgelagert, was nach Angaben des Unternehmens die Token-Effizienz maximiert.

Agent Skills und integrierte Schutzmechanismen

Die Workflows sind als IAM Helper Agent Skills nach dem offenen Agent-Skills-Standard verpackt. Sie kombinieren durchgängige Workflows, Hilfsskripte und Schutzmechanismen und können mehrere zugrunde liegende Funktionen und APIs orchestrieren. Laut Google Cloud funktionieren sie mit gängigen Agenten: Gemini CLI, Gemini Cloud Assist, ADK, Claude Code und Cursor.

Jeder Skill trennt lesende Erkundung von Richtlinienänderungen. Diagnosen und Simulationen laufen automatisch, während jede Änderung an Zugriffsrichtlinien auf eine Bestätigung durch einen Menschen (Human-in-the-Loop, HITL) wartet, die sich nach anpassbaren Risikostufen richtet.

Google Cloud nennt vier Skills:

• iam-helper-for-policy-management erzeugt und validiert IAM-v1-Allow-Bindings und IAM-v2-Deny-Regeln und blockiert riskante Konfigurationen wie öffentlichen Zugriff (allUsers) und weitreichende Basisrollen (roles/owner, roles/editor), bevor sie angewendet werden.
• iam-helper-for-troubleshooting ermittelt bei einem 403-Fehler (PERMISSION_DENIED) die genau fehlende Berechtigung oder die blockierende Regel. Entwickler können prüfen, ob sie sich selbst weiterhelfen können, oder ein strukturiertes Ticket für einen Administrator erzeugen (Requester-Flow). Sicherheitsadministratoren können geerbte Allow- und v2-Deny-Regeln über Organisations-, Ordner- und Projekthierarchien hinweg nachverfolgen (Resolver-Flow).
• iam-helper-for-policy-simulator führt einen Agenten durch den Ablauf aus Planen, Simulieren, Analysieren und Anwenden. Vorgeschlagene Änderungen werden dabei gegen 90 Tage historischer Zugriffsprotokolle getestet, um sicherzustellen, dass bestehender Datenverkehr nicht gestört wird.
• iam-helper-for-privileged-access-management verwaltet Zugangsdaten auf Abruf über PAM, mit Workflows für Anfragende, Administratoren und Genehmigende. Erhöhte Zugriffsrechte werden protokolliert, sind zeitlich befristet und werden nach Abschluss der Aufgabe automatisch entzogen.

Zwei Beispielszenarien

Google Cloud skizziert zwei Szenarien. Im ersten stößt der Coding-Agent eines Entwicklers beim Deployment einer neuen Anwendung auf einen 403-Fehler. Statt auf ein Support-Ticket zu warten, ermittelt der Agent mit dem Troubleshooting-Skill binnen Sekunden die fehlende Pub/Sub-Berechtigung und fordert anschließend mit dem Skill für privilegierten Zugriff eine einstündige JIT-Freigabe an.

Im zweiten Szenario trifft ein Infrastruktur-Agent bei einer routinemäßigen Deployment-Pipeline auf eine Berechtigungssperre. Statt den Build scheitern zu lassen, erzeugt die Pipeline eine überarbeitete Richtlinie nach dem Least-Privilege-Prinzip und prüft mit dem Policy-Simulator-Skill anhand von 90 Tagen Protokollen, dass aktive Dienste nicht beeinträchtigt werden. Die Änderung geht dann zur schnellen Freigabe an einen Administrator.

MCP-Tools als Grundlage

Alle Skills basieren auf einem gemeinsamen Satz grundlegender MCP-Tools. Dabei handelt es sich um atomare, rein lesende Funktionen, die über von Google verwaltete MCP-Server an zentralen IAM-Endpunkten bereitgestellt werden: Policy Troubleshooter, Policy Analyzer, Policy Simulator sowie die IAM-v1- und -v2-APIs.

Laut Google Cloud müssen Teams keine eigenen API-Wrapper mehr schreiben. Agenten können das Backend abfragen und exakte Antworten erhalten, ohne umfangreiche Richtliniendokumente im Prompt auswerten zu müssen. Hierarchie-Traversierung, Gruppenauflösung und Richtlinienauswertung laufen auf dedizierten IAM-Endpunkten, wodurch die Skills nach Angaben des Unternehmens schnell und präzise bleiben und nur wenige Token verbrauchen.

Was das für Teams bedeutet

Teams können die MCP-Tools auch direkt nutzen, wenn sie eigene Agent Skills schreiben, etwa um die IAM-Funktionen von Google Cloud mit internen Ticketsystemen, individuellen Compliance-Prüfungen und bestehenden Deployment-Pipelines zu verbinden.

Für Organisationen, die Agenten einsetzen, lautet das Versprechen: Routinemäßige Berechtigungsprobleme kann der Agent selbst lösen, während Richtlinienänderungen weiterhin eine menschliche Freigabe durchlaufen. Zum Einstieg verweist Google Cloud Entwickler auf den Agent Skills Catalog und die offizielle IAM-Dokumentation.