Einleitung: Der nächste Benutzer in Ihrem System ist möglicherweise kein Mensch
Das nächste Konto, das auf Ihre Systeme zugreift, gehört möglicherweise keinem Mitarbeiter. Es kann einem KI-Agenten gehören – oder sollte gehören.
Ein Betriebsleiter bittet einen Agenten, einen wöchentlichen Bericht zu erstellen. Es öffnet ein Dashboard, lädt eine CSV-Datei herunter, liest eine Excel-Arbeitsmappe, vergleicht die Ergebnisse der letzten Woche, erstellt einen Bericht und gibt den Entwurf zurück.
Der Workflow ist erfolgreich, aber jedes Protokoll zeichnet alex@company.com auf. Die Organisation kann nicht sagen, was Alex getan hat, ob der Agent seine Aufgabe überschritten hat oder ob der Zugriff fortgesetzt wurde.
Wenn ein KI-Agent wie ein Benutzer mit Systemen interagieren kann, sollte er sich dann weiterhin die Identität eines Benutzers leihen?
Hier ist Nichtmenschliche Identität wird für die KI-Governance von zentraler Bedeutung. Organisationen müssen die Entität, die die Arbeit ausführt, von den von ihr verwendeten Anmeldeinformationen und den Berechtigungen, die sie erhält, trennen.
Was ist eine nichtmenschliche Identität?
A Nichtmenschliche Identität ist eine digitale Identität, die von Software, Diensten, automatisierten Prozessen, Geräten, Workloads oder KI-Agenten verwendet wird, um Systeme zu authentifizieren und darauf zuzugreifen, ohne als menschlicher Benutzer zu agieren.
Beispiele hierfür sind Dienstkonten, Dienstprinzipale, verwaltete Identitäten, Arbeitslasten, Geräte, Bots, Skripts, CI/CD-Pipelines, API-Integrationen und KI-Agenten.
Eine nichtmenschliche Identität ist nicht automatisch ein API-Schlüssel, ein Passwort, ein Token, ein Zertifikat, eine Maschine, ein Bot oder ein Modell. Dies können Anmeldeinformationen, Authentifizierungsmechanismen, Ausführungseinheiten oder verbundene Ressourcen sein.
Das Modell hat drei Fragen:
- Identität: Wer oder was handelt?
- Anmeldeinformationen: Wie wird diese Identität bewiesen?
- Erlaubnis: Auf was kann es zugreifen oder es verändern?
Identität, Anmeldeinformationen und Erlaubnis
| Konzept | Frage beantwortet | Beispiel |
|---|---|---|
| Identität | Wer oder was handelt? | Wöchentlicher Reporting-Agent |
| Ausweis | Wie beweist es seine Identität? | Kurzlebiges Zugriffstoken |
| Erlaubnis | Auf was kann es zugreifen oder es verändern? | Lesen Sie Dashboard-Daten und schreiben Sie Berichtsdateien |
| Menschlicher Sponsor | Wer ist für die Identität verantwortlich? | Betriebsleiter |
| Lebenszyklus | Wann soll der Zugriff beginnen und enden? | Aktiv für den Workflow und vierteljährlich überprüft |
Ein Ausweis ist nicht die Identität selbst. Es handelt sich um einen Beweis, der von einer Identität zur Authentifizierung verwendet wird.
Die Haupttypen nichtmenschlicher Identität
Dienstkonten
Diese Konten unterstützen Anwendungen, Skripte, Zeitpläne und Integrationen. Zu den Risiken gehören gemeinsames Eigentum, statische Passwörter, übermäßiger Zugriff und kein Ruhestandsdatum.
Anwendungs- und Dienstprinzipalidentitäten
Dabei handelt es sich um Anwendungen, die auf APIs, Cloud-Dienste oder Ressourcen zugreifen, einschließlich SaaS und interner Automatisierung.
Verwaltete Identitäten und Workload-Identitäten
Dabei handelt es sich um Software-Workloads wie virtuelle Maschinen, Container, serverlose Funktionen, CI/CD-Jobs und Cloud-Anwendungen. Unterstützte Plattformen können sie nutzen, ohne permanente Geheimnisse direkt im Code zu speichern.
Maschinen- und Geräteidentitäten
Diese verifizieren Server, Laptops, Netzwerkgeräte, Industriesysteme und IoT-Geräte anhand von Zertifikaten, Schlüsseln oder Gerätedatensätzen.
KI-Agentenidentitäten
Dabei handelt es sich um Agenten, die Ziele interpretieren, Tools auswählen, auf Ressourcen zugreifen und Maßnahmen ergreifen. KI-Agenten passen in die nichtmenschliche Identität, sind aber aufgrund ihres adaptiven Verhaltens schwieriger zu verwalten als feste Dienstkonten.
Nicht-menschliche Identität vs. Maschinenidentität vs. Workload-Identität
Nichtmenschliche Identität ist der breite Schirm. Maschinenidentität, Arbeitslastidentität, Dienstkonten und Agentenidentität sind engere Kategorien oder Implementierungsmuster.
Nichtmenschliche Identität im Vergleich zu verwandten Identitätstypen
| Identitätstyp | Was es darstellt | Typische Beispiele |
|---|---|---|
| Menschliche Identität | Eine echte Person | Mitarbeiter, Auftragnehmer, Partner, Kunde |
| Nichtmenschliche Identität | Eine softwarebasierte oder maschinenbasierte Entität, die auf Ressourcen zugreift | Dienstkonto, Anwendung, Bot, Arbeitslast, KI-Agent |
| Maschinenidentität | Eine Maschine, ein Gerät, ein Server oder eine technische Komponente | Gerätezertifikat, Serverschlüssel, IoT-Identität |
| Workload-Identität | Ausführen von Software in der Cloud oder Infrastruktur | Container, virtuelle Maschine, serverlose Funktion |
| Dienstkonto | Ein Konto, das von einer Anwendung oder einer automatisierten Aufgabe verwendet wird | Geplantes Berichtskonto, Datenbankintegration |
| Agentenidentität | Eine Identität, die einen KI-Agenten darstellt | Rechercheagent, Berichtsagent, Desktop-Agent |
Die Terminologie unterscheidet sich je nach Plattform. Die Governance sollte sich darauf konzentrieren, was die Identität darstellt, wo sie ausgeführt wird, worauf sie zugreifen kann und wem sie gehört. Nicht jede nichtmenschliche Identität stellt eine physische Maschine dar.
Warum KI-Agenten das Problem der nichtmenschlichen Identität verändern
Agenten befolgen Ziele, nicht nur feste Anweisungen
Herkömmliche Automatisierung kopiert möglicherweise um Mitternacht ein Backup. Ein Agent, der mit der Untersuchung der ungewöhnlichen Leistung und der Erstellung eines Berichts beauftragt wird, kann je nach dem, was er findet, unterschiedliche Maßnahmen ergreifen.
Agenten verwenden mehrere Tools
Ein Agent kann sich über APIs, Dateien, Browser, Tabellenkalkulationen, Datenbanken, Kommunikationstools und Unteragenten bewegen. Jede Verbindung erweitert die Berechtigungskette.
Die Berechtigungen variieren je nach Aufgabe
Forschungs-, Berichts- und Kundensupport-Workflows sollten nicht denselben ständigen Zugriff erhalten, nur weil sie dieselbe Plattform verwenden.
Agenten können delegieren
Ein primärer Agent kann ein Spezialwerkzeug oder einen anderen Agenten anrufen. Der Zugriff sollte nachvollziehbar sein und entweder nach klaren Regeln vererbt oder gesondert autorisiert werden.
Agenten handeln im Namen von Menschen
Systeme sollten menschliche Aktionen, vom Menschen angeforderte Agentenaktionen, vom Agenten ausgewählte Schritte innerhalb einer genehmigten Aufgabe und delegierte Aktionen unterscheiden. Die Agentenidentität muss die Verbindung zwischen Anforderer, Ausführendem, Berechtigungsnachweis und Ergebnis aufrechterhalten.
Warum sich KI-Agenten nicht hinter menschlichen Konten verstecken sollten
Ein Agent kann die Browsersitzung, das API-Token, das E-Mail-Konto oder die Anwendungsanmeldung eines Mitarbeiters verwenden. Der Workflow mag funktionieren, aber die Zuordnung wird schwach.
Protokolle zeigen nur das Mitarbeiterkonto, während der Agent alles erbt, was der Mitarbeiter erreichen kann. Sicherheitsteams können menschliches Verhalten nicht zuverlässig von Automatisierung trennen, und der Zugriff kann über die beabsichtigte Aufgabe hinaus bestehen bleiben.
Ein besseres Attributionsmodell ist:
- Initiiert von: Alex
- Ausgeführt von: Wöchentlicher Reporting-Agent
- Umfeld: Zugelassener Unternehmens-Desktop
- Genehmigt von: Finanzmanager
Der Sponsor bleibt für den Zweck verantwortlich, während die Agentenidentität zeigt, wer die Arbeit ausgeführt hat. Ein Agent sollte für einen Menschen handeln, ohne von diesem Menschen nicht mehr zu unterscheiden zu sein.
Die Hauptrisiken nicht verwalteter nichtmenschlicher Identitäten
Verwaiste Identitäten
Der Zugriff bleibt aktiv, nachdem ein Mitarbeiter das Unternehmen verlässt, ein Projekt endet, eine Integration ersetzt oder ein Agent verlassen wird.
Übermäßige Berechtigungen
Ein umfassender Zugriff wird gewährt, weil enge Richtlinien zu Fehlern führen und vorübergehende Bequemlichkeit zu dauerhaften Privilegien wird.
Langlebige Referenzen
Statische Passwörter, API-Schlüssel, Zertifikate und Token bleiben möglicherweise noch lange nach Wegfall des ursprünglichen Bedarfs verwendbar.
Geteilte Identitäten
Mehrere Anwendungen, Agenten oder Mitarbeiter verwenden ein Konto, wodurch Zuordnung und Eigentum geschwächt werden.
Identitätsausbreitung
Dienstkonten, Bots, OAuth-Apps, Token, Skripte und untergeordnete Agenten sammeln sich ohne zuverlässige Bestandsaufnahme an.
Schwache Rechenschaftspflicht
Nach einem Vorfall kann die Verantwortung zwischen dem Anforderer, dem Workflow-Eigentümer, dem Anwendungseigentümer, dem Genehmiger und den Technologieanbietern umstritten sein.
Das größte Risiko besteht oft nicht darin, dass eine Identität existiert, sondern darin, dass niemand weiß, warum sie existiert, was sie kann oder wann sie verschwinden sollte.
Ein achtstufiger nichtmenschlicher Identitätslebenszyklus
Schritt 1: Entdecken
Inventardienstkonten, Anwendungsidentitäten, OAuth-Apps, Cloud- und lokale Agenten, Bots, Skripte, Zertifikate, Zeitpläne, API-Integrationen und verbundene Tools.
Schritt 2: Registrieren
Erfassen Sie einen eindeutigen Namen, Typ, Zweck, Ersteller, Sponsor, Abteilung, Laufzeit, verbundene Tools, zugängliche Daten, Anmeldeinformationstyp und Ablauf.
Schritt 3: Weisen Sie einen menschlichen Sponsor zu
Eine benannte Person sollte den Zweck genehmigen, den Zugriff überprüfen, auf Vorfälle reagieren, das Eigentum übertragen und die Außerbetriebnahme genehmigen.
Schritt 4: Definieren Sie die Identitätsgrenze
Dokumentieren Sie erlaubte Systeme, Ordner, Datensätze, Tools, Aktionen und explizite Verbote.
Schritt 5: Geringste Privilegien anwenden
Gewähren Sie nur das, was der aktuelle Workflow erfordert. Vermeiden Sie den ständigen Zugriff auf Administratorrechte, nur um Fehler zu vermeiden.
Schritt 6: Bevorzugen Sie kurzlebige Anmeldeinformationen
Sofern unterstützt, verwenden Sie temporäre Token, verwaltete Identitäten, Workload-Föderation, aufgabenbezogene Anmeldeinformationen, Ablauf und Widerruf.
Schritt 7: Verhalten überwachen
Erfassen Sie Authentifizierungsereignisse, aufgerufene Ressourcen, aufgerufene Tools, geöffnete Dateien, Änderungen, Übertragungen, Fehler, Wiederholungsversuche und Delegierungen.
Schritt 8: Drehen, übertragen und zurückziehen
Wenn sich der Workflow ändert oder endet, können Sie Anmeldeinformationen rotieren, den Besitz übertragen, Zeitpläne entfernen, Berechtigungen widerrufen, Tools trennen, untergeordnete Identitäten zurückziehen und Überwachungsdatensätze aufbewahren.
Checkliste für den Lebenszyklus nichtmenschlicher Identitäten
| Frage zum Lebenszyklus | Erforderliche Antwort |
|---|---|
| Was ist die Identität? | Eindeutiger Name und Identitätstyp |
| Warum existiert es? | Dokumentierter Geschäftszweck |
| Wem gehört es? | Benannter menschlicher Sponsor |
| Wo läuft es? | Bekannte Anwendung, Gerät oder Arbeitslast |
| Auf was kann es zugreifen? | Definierte Systeme, Dateien, Daten und Tools |
| Wie erfolgt die Authentifizierung? | Genehmigte und verwaltete Anmeldeinformationen |
| Wann wird der Zugriff überprüft? | Geplanter Überprüfungstermin |
| Wann läuft es ab? | Definierte Ablauf- oder Ruhestandsbedingung |
| Wie wird die Aktivität überwacht? | Protokolle, Warnungen und Prüfprozess |
So gewähren Sie KI-Agenten Zugriff mit den geringsten Privilegien
Dem Arbeitsablauf sollten die geringsten Privilegien folgen, nicht die maximale Leistungsfähigkeit des Agenten.
Ein wöchentlicher Berichterstatter benötigt möglicherweise einen Berichtsordner, zwei Dashboards, CSV-Downloads, ein Ausgabeverzeichnis und die Erlaubnis, einen Entwurf vorzubereiten. Möglicherweise sind nicht die gesamte Festplatte, alle Browserprofile, persönlichen E-Mail-Adressen, Abrechnungskontrollen, Berechtigungsverwaltung, Löschung von Quelldateien oder die Berechtigung zum externen Versenden des Berichts erforderlich.
Definieren Sie vier Ebenen:
- Ressourcenumfang: Welche Systeme, Ordner, Anwendungen und Datensätze?
- Handlungsumfang: Lesen, schreiben, ändern, löschen, veröffentlichen oder senden?
- Zeitlicher Umfang: Permanent, geplant, temporär oder aufgabenbasiert?
- Zulassungsumfang: Welche Aktionen bedürfen einer expliziten Bestätigung?
Die geringste Berechtigung begrenzt, was ein Agent sehen kann, was er tun kann, wie lange er es tun kann und unter wessen Genehmigung.
Warum Desktop-KI-Agenten klare Identitätsgrenzen benötigen
Desktop-Agenten können mit lokalen Dateien, installierten Anwendungen, Browsersitzungen, gespeicherten Anmeldeinformationen, Downloads, Screenshots, Inhalten der Zwischenablage, Betriebssystemsteuerelementen und Kommunikations-Apps interagieren. Ihre Identitätsgrenze kann daher viel mehr als eine API umfassen.
Ein Desktop-Workflow kann Folgendes umfassen:
Menschlicher Anforderer -> Kommunikationskanal -> Desktop-Agent -> Unternehmensgerät -> Browseridentität -> Geschäftsanwendung -> Ausgabeordner
Die Organisation sollte wissen, wer die Aufgabe übermittelt hat, welcher Agent sie erhalten hat, welches Gerät und Konto verwendet wurde, welche Aktionen durchgeführt wurden, welche Ausgabe erstellt wurde und wer sie überprüft hat.
Die lokale Ausführung kann je nach Konfiguration einen Teil der Datenübertragung reduzieren. Es beseitigt weder das Identitätsrisiko noch beantwortet es, wen der Agent vertritt und welche Berechtigungen er verwendet.
EasyClaw veranschaulicht, warum Desktop-Agenten explizite Grenzen zwischen Dateien, Browsern, Anwendungen und Ausgaben benötigen.
Wie EasyClaw in eine Governance-Agent-Identitätsstrategie passt
EasyClaw ist ein Desktop-nativer KI-Workflow-Agent für Arbeiten mit lokalen Dateien, Anwendungen, Browseroberflächen, Berichten, Überprüfungen und Projektordnern. Es handelt sich nicht um eine Identitätsverwaltungsplattform oder einen Ersatz für IAM, privilegierten Zugriff, Anmeldeinformationsrotation oder Bedrohungskontrollen.
Seine praktische Aufgabe besteht darin, zu veranschaulichen, warum ein Desktop-Agent innerhalb einer benannten, begrenzten, sichtbaren und überprüfbaren Identitätsgrenze arbeiten sollte.
Identifizieren Sie den menschlichen Antragsteller
Legen Sie fest, wer EasyClaw-Aufgaben erteilen darf, welche Kanäle genehmigt werden, wie sich Anforderer authentifizieren und wer vertrauliche Arbeitsabläufe starten darf. Jede Anfrage sollte auf eine bestimmte Person zurückführen.
Identifizieren Sie die ausführende EasyClaw-Umgebung
Erfassen Sie die EasyClaw-Bereitstellung, das Unternehmensgerät, das Betriebssystemkonto, das Browserprofil, die genehmigten Anwendungen und den Workflow-Eigentümer. Der Anforderer und die Ausführungsumgebung sind miteinander verbunden, aber sie sind nicht derselbe Akteur.
Beschränken Sie den Datei- und Anwendungsumfang
Für einen Berichtsworkflow sind möglicherweise ein Ordner, eine Excel-Arbeitsmappe, ausgewählte Dashboards, eine PDF-Vorlage und ein Ausgabeverzeichnis erforderlich. Es sollte nicht automatisch auf jede lokale Datei, jedes Browserkonto, jedes Cloud-Laufwerk, jede Verwaltungseinstellung oder jedes unabhängige System zugreifen. Clear Scope reduziert auch die Auswahl falscher Dateien und versehentliches Überschreiben.
Halten Sie Folgemaßnahmen hinter der Genehmigung zurück
Für externe Nachrichten, öffentliche Veröffentlichungen, das Löschen oder Überschreiben von Dateien, das Übermitteln von Finanzinformationen, das Ändern von Kundendatensätzen, das Ändern von Berechtigungen, das Abschließen von Zahlungen und das Ändern von Verträgen ist eine menschliche Genehmigung erforderlich.
EasyClaw kann Zwischenarbeiten organisieren, Überprüfungspakete vorbereiten und brauchbare Ergebnisse zurücksenden. Unumkehrbare, nach außen sichtbare, finanziell wesentliche oder rechtlich bedeutsame Entscheidungen sollten beim verantwortlichen Menschen verbleiben.
Dokumentieren Sie den Workflow-Lebenszyklus
Jeder Workflow sollte einen Namen, einen Zweck, einen Sponsor, genehmigte Eingaben, Aktionen, ein Ausgabeziel, ein Überprüfungsdatum, eine Stoppbedingung und ein Außerbetriebnahmeverfahren haben. Neue Konten, Kanäle oder Ziele sollten eine Überprüfung auslösen.
EasyClaw sollte als sichtbarer Desktop-Agent mit begrenztem Umfang innerhalb eines genehmigten Arbeitsablaufs fungieren – und nicht als unsichtbare Software, die sich unbegrenzten Zugriff von einem menschlichen Konto leiht.
Beispiel: Einem EasyClaw Reporting Agent eine klare Identitätsgrenze geben
Ein Betriebsleiter fordert: „Bereiten Sie den Leistungsbericht dieser Woche vor, vergleichen Sie ihn mit der letzten Woche und senden Sie den Entwurf zur Überprüfung zurück.“
Der bewährte EasyClaw-Workflow öffnet ausgewählte Dashboards, lädt aktuelle Exporte herunter, liest den wöchentlichen Excel-Tracker, vergleicht den vorherigen Bericht, bereitet einen Entwurf vor, speichert das Paket und sendet es zurück. EasyClaw übernimmt die dokumentenintensive Ausführung, während Identitäts- und Sicherheitskontrollen festlegen, was es verwenden darf.
Identitätsgrenzen für einen EasyClaw Reporting-Workflow
| Identität oder Komponente | Rolle | Erforderliche Grenze |
|---|---|---|
| Betriebsleiter | Initiiert die Aufgabe | Kann mit dem genehmigten Berichtsworkflow beginnen |
| EasyClaw-Berichtsworkflow | Führt die Aufgabe aus | Beschränkt auf das Melden von Aktionen |
| Firmencomputer | Ausführungsumgebung | Zugelassenes und verwaltetes Gerät |
| Browseridentität | Liest Leistungssysteme | Lesezugriff auf ausgewählte Dashboards |
| Dateizugriffsbereich | Liest und schreibt Berichtsmaterialien | Nur wöchentliche Berichtsordner |
| Ausgabeverzeichnis | Speichert generierte Materialien | Eigener Rezensionsordner |
| Menschlicher Rezensent | Verifiziert den Bericht | Endgültige Schlussfolgerungen müssen genehmigt werden |
| Kommunikationskanal | Gibt das Ergebnis zurück | Nur genehmigter Anforderer und Zustellungspfad |
Die Attributionskette sollte sichtbar bleiben:
- Initiiert von: Betriebsleiter
- Ausgeführt von: EasyClaw-Berichtsworkflow
- Abgerufene Daten: Genehmigte Dashboards und Berichtsordner
- Bewertet von: Betriebsleiter
- Vertrieb durch: Menschlicher Eigentümer nach Genehmigung
Dies trennt Anforderung, Ausführung, Zugriff, Genehmigung und Verteilung. Wenn die Zahlen falsch aussehen, kann das Team genehmigte Quellen, verwendete Dateien, generierte Ausgaben und die Entscheidung des Prüfers überprüfen. EasyClaw ist die Workflow-Ausführungsebene; Bestehende Identitätssysteme bleiben für Authentifizierung, Anmeldeinformationen, Berechtigungen und Richtlinien verantwortlich.
Fazit: Jeder Agent benötigt eine Identität, einen Eigentümer und ein Ablaufdatum
Nicht-menschliche Identität umfasst Anwendungen, Dienste, Maschinen, Workloads, Skripte, Bots, automatisierte Prozesse und KI-Agenten.
KI-Agenten erhöhen den Einsatz, da ihr Verhalten anpassungsfähig, delegierbar und auf verschiedene Tools verteilt sein kann. Organisationen müssen wissen, welcher Agent handelt, wer ihn sponsert, welche Anmeldeinformationen und Berechtigungen er verwendet, wie Aktionen protokolliert werden, wann eine Genehmigung erforderlich ist und wann der Zugriff abläuft.
EasyClaw ist keine Identitätsverwaltungsplattform. Das Desktop-Ausführungsmodell zeigt, warum Agenten-Workflows benannte Eigentümer, eingeschränkten Datei- und Anwendungszugriff, sichtbare Ausführung, überprüfbare Ausgaben und menschliche Genehmigung für Folgemaßnahmen benötigen.
Jeder KI-Agent benötigt eine Identität, einen menschlichen Sponsor, eine Berechtigungsgrenze und ein Ablaufdatum.
FAQ
F: Ist ein API-Schlüssel eine nichtmenschliche Identität?
A: Nicht von alleine. Ein API-Schlüssel ist normalerweise ein Berechtigungsnachweis. Die Identität ist die Anwendung, der Dienst, die Arbeitslast, das Skript oder der Agent, der sie verwendet.
F: Ist ein Dienstkonto dasselbe wie eine nichtmenschliche Identität?
A: Ein Dienstkonto ist eine häufige Form nichtmenschlicher Identität. Die breitere Kategorie umfasst auch Dienstprinzipale, verwaltete Identitäten, Arbeitslasten, Maschinen, Geräte, Bots, Anwendungen und Agenten.
F: Warum sollte ein KI-Agent kein Mitarbeiterkonto verwenden?
A: Eine gemeinsame Identität verschleiert, ob eine Person oder ein Agent gehandelt hat, und gewährt möglicherweise übermäßigen Zugriff. Ein geregeltes Modell zeichnet den Anforderer, den Ausführenden, die Umgebung, den Zugriff und den Prüfer auf.
F: Benötigt jeder KI-Agent eine eigene Identität?
A: Produktionsagenten sollten ausreichend unterscheidbar sein, um Namensnennung, Richtlinien, Überprüfung und Widerruf zu unterstützen. Die Implementierung hängt von den Plattformfunktionen, dem Risiko, der Datensensibilität und den zulässigen Aktionen ab.
F: In welcher Beziehung steht EasyClaw zur Verwaltung nichtmenschlicher Identitäten?
A: EasyClaw ist kein IAM-Ersatz- oder Anmeldeinformationsverwaltungsdienst. Seine Desktop-Workflows zeigen, warum Teams Anforderer, Gerät, Browserkonto, Dateiumfang, Aktionen, Genehmigungen, Besitz, Überprüfung und Stilllegung definieren sollten.
F: Was sollte ein EasyClaw-Workflow aufzeichnen?
A: Notieren Sie Namen, Zweck, Sponsor, Gerät, Browserprofil, erlaubte Dateien und Apps, Aktionen, Genehmigungen, Ziel, Überprüfungsdatum und Einstellungsbedingung.
F: Welche Agentenaktionen sollten eine menschliche Genehmigung erfordern?
A: Beispiele hierfür sind externe Kommunikation, öffentliche Veröffentlichung, Dateilöschung, finanzielle Einreichungen, Zahlungen, Änderungen von Kundendatensätzen, Genehmigungsänderungen und Vertragsaktionen.