Identität mit Absicht: der Schlüssel zur Kontrolle der bereits in der Produktion tätigen IA-Agenturen

Vor ein paar Jahren, die Bereitstellung künstlicher Intelligenz in der Firma verwendet, um Assistenten, die E-Mails oder zusammenfassende Dokumente geschrieben. Heute sind dieselben Systeme aufgehört, nur Copilots zu sein: sie bieten Infrastruktur, lösen Support-Tickets, priorisieren Warnungen, billigen Transaktionen und sogar schreiben Code, der zur Produktion kommt. Kurz gesagt, IA-Agenten sind nicht mehr passive Assistenten: Sie fungieren als Betreiber innerhalb der Organisation.

Dies zwingt die Verantwortlichen für die Sicherheit - der GUS -, ein bekanntes, aber jetzt viel komplexeres Problem neu zu fokussieren: Zugangskontrolle. Jeder Agent wird mit Schlüsseln, Tokens OAuth, Cloud-Rollen oder Servicekonten gegen APIs, Cloud-Dienste und Drittanbieter-Tools authentifiziert. Lesen Sie Daten, schreiben Sie Einstellungen und Kettenanrufe an andere Systeme. In der technischen Welt verhält sich ein IA-Agent genauso wie eine Identität, und doch in vielen Umgebungen wird er nicht als solche geregelt.

Die operative Realität ist einfach und gefährlich: viele Agenten erben Privilegien von ihrem Schöpfer, laufen mit Konten zu breit, um "alle Arbeit zu machen" und entwickeln sich schneller als die Kontrollen um sie herum. Diese Kombination ergibt, was bereits als blinder Bereich in der Sicherheit von IA angesehen werden kann. Die erste offensichtliche Antwort ist, einen Identitätsansatz für die Agenten anzuwenden: behandeln jeden Agenten als erstklassige Identität mit Lebenszyklus, Eigentum, Rollen und Rückverfolgbarkeit. Es gibt jedoch eine zweite Wahrheit, die das Bild erschwert: Identität allein reicht nicht mehr aus.

Die traditionellen Identity- und Access-Management-Modelle (IAM) beantworten eine bestimmte Frage: Wer verlangt Zugriff? In Umgebungen konzentrierten sich auf statische Personen oder Dienstleistungen, die ausreichen könnten, weil die Rollen und Funktionen vorhersehbar waren. Aber IA-Agenten sind dynamisch im Design: sie interpretieren Ziele, Planschritte und Kettenwerkzeuge nach Kontext. Ein Agent, der mit der Aufgabe beginnt, einen vierteljährlichen Bericht zu erstellen, könnte, wenn er gerichtet oder manipuliert wird, versuchen, auf Systeme außerhalb des Berichts zuzugreifen. Ein Abhilfemittel kann Konfigurationen abweichen und ändern, die seinen ursprünglichen Zweck überschreiten.

Dieses Verhalten bricht die Annahme des Determinismus, auf dem der statische Zugriff basiert: Wenn die Rolle erlaubt, wird die Aktion ausgeführt, auch wenn sie nicht mehr mit dem ursprünglichen Grund der Existenz des Agenten übereinstimmt. Hier kommt die Notwendigkeit für einen Schritt über den klassischen IAM: beabsichtigte Genehmigungen Wenn Identität auf "Wer" reagiert, reagiert die Absicht auf "Warum".

Erlauben Sie einem Agenten, Privilegien nur zu aktivieren, wenn sein erklärtes Missions- und Umsetzungskontext eine solche Aktivierung die Zugriffskontrolle transformiert. Anstelle einer statischen Karte zwischen Identität und Berechtigungen beurteilt das System, ob der Zweck und die Bedingungen im Zeitpunkt der Umsetzung einen solchen Zugriff ermöglichen würden. Beispielsweise könnte ein Deployment Agent die Fähigkeit haben, die Infrastruktur zu ändern, aber diese Privilegien werden nur aktiviert, wenn die Aktion aus einer genehmigten Kanalisierung und in Reaktion auf eine autorisierte Änderung durchgeführt wird. Wenn dasselbe Mittel versucht, die Produktion außerhalb dieses Flusses zu berühren, erlauben die Anmeldeinformationen den Betrieb nicht.

Dieser zusammengesetzte Ansatz reduziert zwei wiederkehrende Fehler. Auf der einen Seite die Erbschaft der Privilegien: Es ist üblich, dass Entwickler Agenten mit hohen eigenen Anmeldeinformationen testen und diese Anmeldeinformationen bleiben in der Produktion. Wenn jeder Agent seine eigene und verwaltete Identität hat, verschwindet das "Bluten". Auf der anderen Seite, die Drift der Mission: die Agenten können für Aufforderungen, Integrationen oder Angriffe schwenken; die Politiken auf der Grundlage der Absicht verhindern, dass dieser Pivot unberechtigten Zugriff wird.

Aber über die Schließung spezifischer Risiken hinaus gibt es ein starkes organisatorisches Argument: Governance im Maßstab. In Ökosystemen, in denen ein Agent Tausende von APIs und Ressourcen in mehreren Wolken und SaaS aufrufen kann, führt die Verwaltung jeder Genehmigung in einer separaten Regel schnell zu einer schwierigen politischen Explosion. Ein Vorsatzmodell vereinfacht die Überwachung: Anstatt jeden möglichen Aufruf zu überprüfen, genehmigten die zuständigen Audits Identitätsprofile und Absichtsgrenzen. Politik-Bewertungen konzentrieren sich auf die Frage, ob die autorisierte Mission Sinn macht, nicht auf die Erfinder jeden Endpunkt, den ein Agent spielen könnte.

Auch die Rückverfolgbarkeit verbessert sich. In einem Vorfall ist es nicht nur wichtig zu wissen, welche Identität eine Handlung durchgeführt hat, sondern welches Absichtsprofil aktiv war und ob die Operation mit der autorisierten Mission vereinbar war. Diese Kontext-Granulat ist zunehmend relevant für die Rechenschaftspflicht gegenüber Führungskräften und Verzeichnissen. Für technische Geräte erleichtert sie auch die Forschung und schnelle Reaktion.

Diese Ideen sind nicht nur Theorie: Sie verbinden sich mit Rahmenbedingungen und Praktiken, die seit Jahren in der Sicherheit konsolidiert wurden, wie z.B. Zero Trust Prinzipien oder attributbasierte Modelle. Ressourcen wie der NIST IA Risikomanagement-Rahmen (RMF NIST), Zugriffskontrolle Empfehlungen basierend auf Attributen (NIST SP 800-162) und die Zero Trust Strategie (NIST SP 800-207) bieten Prinzipien, die diese Identität + Intention Ansatz passen. Darüber hinaus werden Organisationen wie Cloud Security Alliance Gemeinschaftsprojekte wie OWASP beginnen, Risiken und spezifische Kontrollen für IA-Systeme zu dokumentieren.

Und welche praktischen Maßnahmen können die Sicherheitsteams heute umsetzen? Die Straße beginnt mit einer klaren Bestandsaufnahme von Agenten und deren Fähigkeiten, ihnen einzigartige Identitäten mit Lebenszyklusmanagement und verantwortlichen Eigentümern zuzuordnen. Es ist daher angezeigt, die zugelassene Mission jedes Agenten und die operativen Grenzen, auf die er handeln kann, schriftlich festzulegen. Diese Dokumentation sollte mit technischen Mechanismen integriert werden, die die Aktivierung von Privilegien auf die Übereinstimmung zwischen Identität, erklärter Absicht und Kontext im Zeitpunkt der Ausführung konditionieren.

Parallel muss die Überwachung durchgeführt werden: bereicherte Aufzeichnungen, die nicht nur das, was getan wurde und von denen, sondern was die damit verbundene Absicht war und welche Kontextzeichen (Pipeline, Ursprung der Anfrage, Multifaktor-Authentifizierung, etc.) die Aktion erlaubten. Schließlich reduziert die Automatisierung der Rotation von Anmeldeinformationen, der End-of-life-Revokation und regelmäßige Missionsableitungskontrollen die Exposition und verdeutlicht die Governance.

Die Alternative ist gefährlich: Die Autonomie ohne Governance multipliziert das Risiko; eine unbeabsichtigte Identität lässt Lücken. Im mittleren Alter, Verständnis, wer Handlungen notwendig ist, aber sicherstellen, dass es aus dem richtigen Grund handelt, was IA sicher macht. Für CISUS ist die Anpassung von Prozessen, Werkzeugen und politischen Überprüfungen an diese Realität keine Option, es ist eine Verpflichtung, Kontrolle, Compliance und Widerstand zu erhalten.

Wenn Sie in praktische Rahmen und Empfehlungen gehen wollen, starten Sie mit den NIST-Ressourcen auf IA und Zugriffskontrolle, die ich erwähnt habe, und mit den Dokumentationen und bewährten Praktiken, die von Initiativen wie der Cloud Security Alliance veröffentlicht werden. Die Konversation darüber, wie Identitätskontrollen und -berechtigung durch die Absicht eingeführt werden sollen, beginnt gerade, und es ist wichtig, dass es von Sicherheits-, Engineering- und Compliance-Teams koordiniert konfrontiert wird.