Bedingter Zugriff für Agentidentitäten

Bedingter Zugriff ist ein intelligentes Richtlinienmodul, mit dem Organisationen steuern können, wie Benutzer und Agentidentitäten auf Unternehmensressourcen zugreifen. Es vereint Echtzeitsignale wie Kontext, Gerät, Standort und Sitzungsrisikoinformationen, um zu bestimmen, wann der Zugriff zugelassen, blockiert oder eingeschränkt werden soll oder weitere Überprüfungsschritte erforderlich sind.

Eine allgemeine Übersicht über bedingten Zugriff finden Sie unter Was ist bedingter Zugriff?. Eine allgemeine Anleitung zum Verwalten von Agentidentitäten in Ihrer Organisation finden Sie unter Verwalten von Agentidentitäten in Ihrer Organisation.

Attributgesteuerter bedingter Zugriff

Wenn die Anzahl der Agentidentitäten wächst, wird das individuelle Hinzufügen jeder einzelnen Agentenidentität zu jeder Richtlinie für bedingten Zugriff betrieblich untragbar. Bevor Sie mit dem Erstellen von Richtlinien für bedingten Zugriff beginnen, ist es wichtig, die Agentidentitäten zu organisieren, sodass eine konsistente, skalierbare Zugriffssteuerungserzwingung ermöglicht wird.

Benutzerdefinierte Sicherheitsattribute in Microsoft Entra ID sind eine bequeme Möglichkeit zum Organisieren von Agentidentitäten im großen Maßstab. Benutzerdefinierte Sicherheitsattribute sind geschäftsspezifische Schlüsselwertattribute, die Sie definieren und Microsoft Entra Objekten zuweisen können, einschließlich Benutzer, Agentidentitäten und Unternehmensanwendungen (Dienstprinzipale). Mit diesen Attributen können Sie aussagekräftige Informationen zu jeder Agentidentität speichern, z. B. die Vertraulichkeitsstufe der Daten, die der Agent verarbeitet.

Das folgende Diagramm zeigt, dass Agentidentitäten mit dem Attribut "Datenempfindlichkeit", das auf "Vertraulich" festgelegt ist, blockiert werden. alle anderen Agents sind ausgeschlossen und zulässig. Diese benutzerdefinierten Sicherheitsattributewerte können während der Bewertung des bedingten Zugriffs als Filter verwendet werden, wodurch die attributbasierte Zielbestimmung aktiviert wird. Anstatt eine manuelle Auswahl von Agentidentitäten oder Zielressourcen zu verwalten, können Sie eine Regel wie "Wenn das Attribut "Datenempfindlichkeit" vertraulich ist, definieren, und dann den Zugriff blockieren. Die Richtlinie gilt dann automatisch für jede Agentidentität mit diesen Attributen, einschließlich der in Zukunft hinzugefügten.

In der folgenden Tabelle sind einige Beispiele aufgeführt, wie Sie Ihre Agentidentitäten kategorisieren können:

Benutzerdefinierte Sicherheitsattribute sind nicht nur für Agentidentitäten vorgesehen. Sie können sie auch verwenden, um die Unternehmensressourcen zu klassifizieren, auf die die Agents zugreifen, und dann beide in Ihren Richtlinien für bedingten Zugriff für ein einheitliches Bezeichnungssystem in der gesamten Zugriffskette verwenden. Um mehr zu erfahren, siehe Was sind benutzerdefinierte Sicherheitsattribute in Microsoft Entra ID.

Agentenidentitätsentwürfe

Eine weitere Möglichkeit, eine Richtlinie für bedingten Zugriff auf mehrere Agentidentitäten gleichzeitig anzuwenden, besteht darin, ihren übergeordneten Agent-Identitätsplan zu verwenden. Jede Agentidentität wird von einem Agentidentitäts-Blueprint abgeleitet, der sein Konfigurations- und Governancemodell definiert. Das Anwenden einer Richtlinie auf Blaupausenebene deckt automatisch alle daraus abgeleiteten Agents ab, einschließlich aller neuen, die in Zukunft hinzugefügt wurden.

Das folgende Diagramm zeigt, dass nur Agentidentitäten, die mit Blueprint "A" verknüpft sind, Zugriff gewährt werden; alle anderen Agents werden ausgeschlossen und blockiert.

Stellen Sie sich beispielsweise ein Projekt vor, bei dem Sie über mehrere Agenten verfügen, die jeweils ihren eigenen Zweck haben. Einige arbeiten unabhängig, während andere mit anderen Agents (A2A) zusammenarbeiten, um Aufgaben auszuführen. Wenn sie alle unter demselben Blueprint erstellt werden, erzwingt eine einzelne Richtlinie, die auf diesen Blueprint angewendet wird, einheitliche Zugriffssteuerungen in der gesamten Sammlung.

Übersicht über Datenzugriffsmuster

Um auf eine Unternehmensressource wie SharePoint Datei, MCP-Server oder Open-API-Dienste zuzugreifen, fordert ein Benutzer oder Agent zuerst ein Zugriffstoken von Microsoft Entra ID an. Zugriffstoken werden jedoch erst ausgegeben, nachdem die erforderlichen Steuerelemente für bedingten Zugriff erfüllt sind. Sobald das Zugriffstoken ausgestellt wurde, stellt der Agent dieses Token der Ressource vor, um seine Identität zu beweisen. Die Ressource überprüft das Token und verwendet seine Ansprüche zum Erzwingen der Autorisierung.

Das folgende Diagramm veranschaulicht die Datenzugriffsmuster.

Richtlinien für bedingten Zugriff sind if-then-Anweisungen: Wenn ein Benutzer oder Agent auf eine Ressource zugreifen möchte, muss zuerst etwas geschehen. Wenn ein Agent beispielsweise die E-Mail eines Benutzers in seinem Namen über das Work IQ MCP lesen muss, muss der Benutzer die mehrstufige Authentifizierung abschließen, bevor der Zugriff gewährt wird. Wenn ein Agent versucht, auf eine Ressource zuzugreifen, die nicht explizit in der Richtlinie enthalten ist, wird der Zugriff standardmäßig blockiert.

Microsoft Entra ID stellt einem Subjekt ein Zugriffstoken für eine bestimmte Zielgruppe (Ressource) aus. Jedes Token hat genau einen Betreff und eine Zielgruppe.

• Der "Betreff" gibt an, an wen das Token ausgestellt wurde:
  • Wenn eine Anwendung oder ein Agent ein Token im Namen eines Benutzers anfordert, ist der Benutzer der Betreff.
  • Wenn eine Anwendung oder ein Agent ein Token für sich selbst anfordert, ist die Anwendung oder der Agent der Betreff.
• Die "Zielgruppe" identifiziert die Zielressource, für die das Token vorgesehen ist:
  • Diese Ressource muss in Microsoft Entra ID registriert werden.
  • Wenn das Subjekt mehrere Ressourcen aufrufen muss (z. B. zwei unterschiedliche MCP-Server), benötigt es in der Regel für jede Ressource ein separates Zugriffstoken, mit eigener Ziel- und Berechtigung.

Richtlinien für bedingten Zugriff werden jedes Mal neu ausgewertet, wenn ein Zugriffstoken angefordert wird, was in der Regel beim Ablauf des Tokens oder beim Auslösen eines kritischen Ereignisses geschieht, z. B. kontinuierliche Zugriffsauswertung.

Agents können auf Unternehmensressourcen zugreifen, die durch Microsoft Entra ID mit einem der folgenden Muster geschützt sind:

• Im Auftrag eines Benutzers
• Nur Anwendung
• Konto des Agentbenutzers

Weitere Informationen zu den Arten von Agents und den identitäts- und zugriffsverwaltungsrelevanten Herausforderungen, die sie darstellen, finden Sie unter "Sicherheit für KI".

On-Behalf-Of (OBO) Ablauf

Der am häufigsten verwendete Zugriff ist der OBO-Fluss (On-behalf-of signed-in user). In diesem Fluss greift der Agent auf Ressourcen mit der Identität und den Berechtigungen des Benutzers zu, um Daten abzurufen oder Aktionen auszuführen, die der Benutzer auch ausführen kann. Wenn beispielsweise ein Agent Ihre E-Mails liest, greift der Agent in Ihrem Auftrag auf Ihr Postfach zu.

Das folgende Diagramm zeigt den OBO-Fluss, der verwendet wird, wenn ein Agent im Namen eines Benutzers auf eine Ressource zugreift, einschließlich der folgenden Komponenten:

• Benutzer: Wer fordert Aufforderungen an den Agent ein
• Agent/Client-Anwendung: Die Benutzeroberfläche, auf der Benutzer ihre Eingabeaufforderungen übermitteln
• Microsoft Entra ID: Der Identitätsanbieter, der die Agentidentität, das Benutzerkonto verwaltet und wo die Ressourcen registriert sind
• KI-Plattform: Die Laufzeitumgebung, in der das große Sprachmodell (LLM) ausgeführt wird
• Resource: Die Ressource, die der Agent aufruft, um Daten abzurufen oder eine Aktion auszuführen, z. B. Arbeits-IQ, SharePoint online oder ein benutzerdefinierter MCP-Server

In den folgenden Schritten wird der Ablauf ausführlicher beschrieben:

1. Der Benutzer greift auf die Agentanwendung zu.

   1. Die Agentanwendung wird in Microsoft Entra ID registriert, und ihr Zugriff wird durch Microsoft Entra ID geregelt.
   2. Um auf die App zuzugreifen, müssen sich Benutzer zuerst mit ihrem Konto authentifizieren. Administratoren können die Agentanwendung in der Richtlinie für bedingten Zugriff als Ziel festlegen.

2. Nachdem sich der Benutzer angemeldet hat, überprüft die App das Zugriffstoken des Benutzers und gewährt Zugriff.

   1. Der Benutzer sendet eine Aufforderung an die KI-Plattform (z. B. Copilot Studio, Microsoft Foundry oder eine Plattform ohne Microsoft).
   2. Um die Anforderung zu verarbeiten und darauf zu reagieren, ruft die LLM eine Unternehmensressource auf.

3. Die Unternehmensressource (SharePoint, E-Mail usw.) ist durch Microsoft Entra ID geschützt und erfordert ein eigenes Zugriffstoken.

   • Sie können das Token nicht aus Schritt 1 übergeben, da es für eine andere Zielgruppe und mit anderen Berechtigungen ausgestellt wurde.
   • Verwenden Sie stattdessen den OBO-Fluss, um Token mit Microsoft Entra ID auszutauschen und ein neues Token für die Ressource abzurufen.
   • Dieser Token-Umtausch wird auch von den Richtlinien für den bedingten Zugriff ausgewertet, sodass Administratoren detaillierte Kontrollen erzwingen können, welche Ressourcen von Agents im Namen des Benutzers abgerufen werden können.
   • Je nach Agentarchitektur kann der OBO-Tokenaustausch auf verschiedenen Ebenen erfolgen: die Agentanwendung selbst, eine benutzerdefinierte Middleware-API, eine KI-Plattform wie Copilot Studio oder Azure AI Foundry oder sogar der MCP-Server.

4. Nachdem das neue Zugriffstoken abgerufen wurde, ruft der Agent die Ressource auf und stellt das Token für die Authentifizierung dar.

   • Die Ressource überprüft das eingehende Token, gibt seine Antwort zurück, und der Fluss wird abgeschlossen.

Konfigurieren Sie die Richtlinie für Bedingten Zugriff für den OBO-Vorgang

Verwenden Sie die folgenden Einstellungen, um eine Richtlinie für bedingten Zugriff für Agents zu erstellen, die im Auftrag eines Benutzers ausgeführt werden:

• Zuweisungen: In einem OBO-Fluss wird das Zugriffstoken an den Benutzer (der Tokenbetreff) ausgegeben, sodass Sie die Richtlinie Benutzern oder Gruppen, aber nicht dem Benutzerkonto des Agents oder Agenten zuweisen.
• Zielressourcen: Wählen Sie aus, auf welche Elemente der Benutzer oder der Agent im Namen des Benutzers zugreifen soll:
  • Wählen Sie für jede Zielressource entweder "Alle Ressourcen", "alle Agents" aus, oder wählen Sie jede einzelne Ressource aus, auf die Sie mit dieser Richtlinie abzielen möchten.
• Netzwerkzuweisung: Administratoren können Richtlinien erstellen, die bestimmte Netzwerkstandorte als Signal zusammen mit anderen Bedingungen in ihrem Entscheidungsprozess ansprechen. In diesem Kontext bezieht sich das Netzwerk auf die Speicherorte, an denen sich der Benutzer anmeldet, nicht auf den Ort, an dem der Agent ausgeführt wird.
• Bedingungen: Konfigurieren Sie die Signale, die bedingten Zugriff auswertet, z. B. Benutzerrisiko, Anmelderisiko oder andere Faktoren.
• Zugriffssteuerung: Erzwingt, ob der Zugriff auf eine Zielressource gewährt, verweigert oder beschränkt wird, oder ob weitere Überprüfungsschritte vom Benutzer erforderlich sind.

Nur Anwendungszugriffsfluss

Agents greifen möglicherweise ohne einen angemeldeten Benutzer auf Ressourcen zu. In diesem Fall greift der Agent auf die Ressource mit eigener Identität zu. Das folgende Diagramm veranschaulicht, wie Agent mit eigener Identität auf Ressourcen zugreift.

Dieser Ablauf wird auch als Client-Credentials-Ablauf oder App-Only-Zugriff bezeichnet. Alle Arten von Agenten können diesen Ablauf verwenden.

Das folgende Diagramm zeigt den Nur-Zugriffs-Autorisierungsfluss der Anwendung.

Dieser Fluss gilt in den folgenden gängigen Szenarien:

• Autonome Agenten, die unabhängig arbeiten:
  • Diese Agents werden im Hintergrund ausgeführt, reagieren auf Ereignisse oder werden nach einem Zeitplan ausgeführt.
  • Beispielsweise ein Agent, der einen täglichen Bericht generiert und das Ergebnis an eine Gruppe von Mitarbeitern sendet. In diesem Szenario ist kein Benutzer vorhanden, und der Agent arbeitet eigenständig.
• Interaktive Agents, die ihre eigene Identität verwenden:
  • Diese Agents greifen nicht immer auf Ressourcen im Namen eines Benutzers zu; manchmal verwenden sie ihre eigene Identität.
  • Wenn beispielsweise ein Agent einen Hintergrund-SMS-Dienst aufruft, auf den Benutzer keinen Zugriff haben, gilt der OBO-Prozess nicht und der Agent authentifiziert sich direkt.
• Im Web veröffentlichte Agenten für die öffentliche Nutzung:
  • Diese Agents authentifizieren den Benutzer entweder nicht oder unterstützen das Delegieren des Benutzerkontexts an Unternehmensressourcen nicht.

In diesen Szenarien fordert der Agent ein Zugriffstoken mithilfe seiner eigenen Agent-Identität und Anmeldeinformationen an, die über den Agentidentitäts-Blueprint verwaltet werden. Das Token wird an die Agentidentität (nicht an den Benutzer) ausgegeben. Daher sind Richtlinien für bedingten Zugriff auf die Agentidentität und nicht auf den Benutzer begrenzt.

Konfigurieren Sie eine Richtlinie für bedingten Zugriff für Zugriff auf Anwendungen.

Verwenden Sie die folgenden Einstellungen, um eine Richtlinie für bedingten Zugriff für Agents zu erstellen, die mit ihrer eigenen Identität arbeiten:

• Zuweisungen: In einem Agent-Zugriffsablauf wird das Zugriffstoken an die Agentidentität (das Token-Subjekt) ausgegeben, sodass Sie die Richtlinie auf Agentidentitäten oder deren Agentidentitäts-Blueprint zuweisen.
• Zielressourcen: Wählen Sie die Ressourcen aus, auf die die Agentidentität zugreifen muss.
• Bedingungen: Konfigurieren Sie, ob die Agentidentität gefährdet ist. Weitere Informationen finden Sie unter ID Protection für Agents.
• Zugriffssteuerung: Da dieser Agent auf Ressourcen mit eigener Identität zugreift, gibt es keine Wartung, und die einzige verfügbare Option blockiert den Zugriff.

Benutzerkonto des Agenten

Manchmal reicht es nicht aus, dass ein Agent Aufgaben im Auftrag eines Benutzers ausführt oder mit seiner eigenen Identität arbeitet. In bestimmten Szenarien ist ein Agent tatsächlich ein Benutzer. Beispielsweise digitale Mitarbeiter, die als Teammitglieder mit eigenen Postfächern, Zugriff auf Chats und der Möglichkeit, als Teammitglieder an Workflows für die gemeinsame Arbeit teilzunehmen, funktionieren.

In diesem Modell erstellt ein Administrator ein Benutzerkonto im Verzeichnis und verknüpft es mit der Identität des Agents. Von dort aus ist es wie jedes andere Benutzerkonto. Lizenzen können zugewiesen werden, um auf Microsoft 365 Ressourcen wie Postfach und Kalender zuzugreifen. Das Konto kann administrativen Einheiten und Sicherheitsgruppen wie einem menschlichen Benutzerkonto hinzugefügt werden.

Agenten, die diesen Fluss verwenden, werden manchmal als "digitaler Mitarbeiter" oder "KI-Teamkollege" bezeichnet. Sie werden auch als autonome Agents betrachtet, da sie keine Benutzeroberfläche für die menschliche Interaktion einbeziehen.

In diesem Modell wird das Zugriffstoken an das Benutzerkonto des Agenten (das Token-Subjekt) ausgegeben, und die Richtlinie wird gegen das Benutzerkonto des Agenten und nicht gegen die Agentenidentität ausgewertet. Heute können Sie auf das Benutzerkonto eines Agents mit einem einzigen Bereich abzielen: "Alle Agents, die als Benutzer fungieren."

Konfigurieren der Richtlinie für bedingten Zugriff für das Benutzerkonto eines Agents

Verwenden Sie die folgenden Einstellungen, um eine Richtlinie für den bedingten Zugriff für das Benutzerkonto eines Agents zu erstellen:

• Zuordnungen: Wählen Sie im Benutzerkontoablauf eines Agents die Option "Als Benutzer aktive Agents auswählen" und dann "Alle Agent-Benutzer" aus.
• Zielressourcen: Alle Ressourcen
• Bedingungen: Konfigurieren Sie, ob die Agentidentität gefährdet ist. Weitere Informationen finden Sie unter ID Protection für Agents
• Zugriffssteuerung: Da diese Richtlinie das Benutzerkonto eines Agents abdeckt, gibt es keine Behebung von Authentifizierungsproblemen, weshalb die einzige verfügbare Option den Zugriff blockiert.

Auswählen der Zielressource

Um eine Zielressource in einer Richtlinie für bedingten Zugriff auszuwählen, muss die Ressource über eine Unternehmensanwendung (Dienstprinzipal) mit einem Berechtigungssatz in Ihrem Microsoft Entra ID Mandanten verfügen. Diese Richtlinie gilt für alle Ressourcentypen, einschließlich SharePoint Online, Exchange Online, Work IQ MCP-Servern, dem Azure MCP-Server, dem Microsoft 365 MCP-Server, Microsoft Graph, Open API, MCP-Servern, nicht-Microsoft-Tools und benutzerdefinierten Tools, die Sie entwickeln.

Die Unternehmensanwendung ist unabhängig vom Datenzugriffsmuster erforderlich, egal ob Agents im Auftrag eines Benutzers, ausschließlich per Anwendungszugang oder über das Benutzerkonto eines Agents zugreifen. Die Art der gewährten Berechtigungen unterscheidet sich zwischen benutzerdelegiertem und Anwendungszugriff, die Dienstprinzipalanforderung gilt jedoch in allen Fällen.

Einige Microsoft-Dienste erfordern einen expliziten Bereitstellungsschritt, bevor sie in Ihrem Verzeichnis angezeigt werden. Aktivieren Sie beispielsweise die erforderliche Lizenz, oder führen Sie einen PowerShell-Befehl aus. Weitere Informationen finden Sie in der entsprechenden Produktdokumentation.

Registrieren Sie das Tool für benutzerdefinierte MCP-Server, offene API-basierte Tools oder einen anderen benutzerdefinierten Tooltyp in Microsoft Entra ID als Anwendung, und machen Sie seine Berechtigungssätze verfügbar (delegierte oder App-Rollen). Weitere Informationen finden Sie unter Konfigurieren einer Anwendung zum Verfügbarmachen einer Web-API.

Bereitstellung für bedingten Zugriff planen

Die Planung Ihrer Bereitstellung für bedingten Zugriff ist wichtig, um die Zugriffsstrategie Ihrer Organisation für Agents, Benutzer und Ressourcen zu erreichen. Richtlinien für bedingten Zugriff bieten erhebliche Flexibilität bei der Konfiguration. Diese Flexibilität bedeutet jedoch, dass Sie sorgfältig planen müssen, um unerwünschte Ergebnisse zu vermeiden. Weitere Informationen finden Sie unter Planen einer Bereitstellung für bedingten Zugriff.

Um die Abdeckung für alle Agentzugriffsmuster sicherzustellen, entwerfen Sie Ihre Richtlinien so, dass sie die drei in diesem Artikel beschriebenen Zugriffsmuster abdecken: im Auftrag von angemeldeten Benutzern, Agentzugriff mithilfe der eigenen Identität des Agents und Agents, die als Benutzer (Benutzerkonten von Agents) funktionieren.

Grenzen und Beschränkungen des bedingten Zugriffs

Richtlinien für bedingten Zugriff gelten nicht, wenn:

• Ein Blueprint für Agentenidentität erwirbt ein Token für Microsoft Graph, um ein Agentenidentitäts- oder Agenten-Benutzerkonto zu erstellen.
  • Agent-Blueprints verfügen über eingeschränkte Funktionalität. Sie können nicht unabhängig auf Ressourcen zugreifen und sind nur an der Erstellung von Agentidentitäten und den Benutzerkonten der Agents beteiligt.
  • Agent-Aufgaben werden immer von der Agent-Identität ausgeführt.
• Ein Blueprint für Agentenidentität oder eine Agentenidentität führt einen Zwischen-Token-Austausch am Endpunkt AAD Token Exchange Endpoint: Public (Ressourcen-ID: fb60f99c-7a34-4190-8149-302f77469936) aus.
  • Tokens, die sich auf die AAD Token Exchange Endpoint: Public beschränken, können Microsoft Graph nicht aufrufen.
  • Agentische Flüsse sind geschützt, da der bedingte Zugriff die Token-Erfassung von der Agentenidentität oder dem Benutzerkonto des Agenten schützt.
• Sicherheitsstandardwerte sind aktiviert.
• Bedingter Zugriff schützt nur durch Microsoft Entra ID gesicherte Ressourcen. Wenn beispielsweise ein Agent mit einem API-Schlüssel auf Ressourcen zugreift, wird die Microsoft Entra ID Authentifizierungs- und Tokenausstellungspipeline vollständig umgangen, und Richtlinien für bedingten Zugriff gelten nicht für sie.

Die folgenden Konfigurationen werden derzeit nicht unterstützt:

• Festlegen des Geltungsbereichs einer Richtlinie für bedingten Zugriff, um das Benutzerkonto eines Agents basierend auf ihrer Gruppenmitgliedschaft und benutzerdefinierten Sicherheitsattributen einzuschließen oder auszuschließen.
• Eine Richtlinie für bedingten Zugriff, die auf Agentidentitäten in einem Agent-zu-Agent-Szenario mit benutzerdefinierten Sicherheitsattributen abzielt, gilt nicht für das Benutzerkonto des Agents.
• Eine Richtlinie für bedingten Zugriff, die auf Agentidentitäten in einem Agent-zu-Agent-Szenario mit Agent-Identitäts-Blueprint abzielt, deckt nur die Agentidentität und nicht das Benutzerkonto des Agents ab.

Untersuchen der Richtlinienauswertung mithilfe von Anmeldeprotokollen

Administratoren können die Anmeldeprotokolle verwenden, um zu untersuchen, warum eine Richtlinie für bedingten Zugriff nicht angewendet wurde oder nicht. Filtern Sie nach agentspezifischen Einträgen nach agentType. Einige dieser Ereignisse werden in den Benutzeranmeldungen (nicht interaktiv) angezeigt, während andere unter Serviceprinzipalanmeldungen angezeigt werden. Weitere Informationen finden Sie unter Microsoft Entra-Agent-ID Anmelde- und Überwachungsprotokolle.

• Agentidentitäten (Akteur) zugreifen auf ressourcen → Dienstprinzipalanmeldungsprotokolle → agentType: Agent-Identität
• Das Benutzerkonto des Agents, das auf alle Ressourcen zugreift, → Nicht interaktive Benutzeranmeldungen → agentType: Benutzerkonto des Agents
• Benutzerzugriff auf Agents → Benutzeranmeldungen

Nächste Schritte

Erfahren Sie, wie Sie Richtlinien für bedingten Zugriff für Agentidentitäten konfigurieren:

• Agents arbeiten im Auftrag eines angemeldeten Benutzers
• Agents arbeiten mit ihrer eigenen Identität
• Agent fungiert als Benutzer