Alles, was hier steht, gibt es heute im Produkt. The IT Lead hält fest, wer einen Service-Account verantwortet und was dein Team dazu entschieden hat. Es verbindet sich nicht mit deinem Verzeichnis, rotiert keine Secrets und deaktiviert keine Accounts. Die App ist auf Englisch, deshalb stehen Bezeichnungen wie „Settings“ oder „Agent Setup“ in diesem Text im Original.
Lade eine CSV mit Service-Accounts aus einem beliebigen System hoch. Der Import zeigt eine Vorschau und markiert Zeilen ohne Kennung oder Quellsystem, bevor du etwas übernimmst. Bereits vorhandene Zeilen werden übersprungen und mitgezählt, du kannst also einen aktualisierten Export gefahrlos erneut importieren.
Gespeicherte Daten: Pro Account: Kennung, Quellsystem, Beschreibung, Kennzeichnung als privilegiert und optional die E-Mail-Adresse des Owners. Pro Import: Dateiname, Zeilenzahl, Fehlerzahl und wer ihn ausgeführt hat.
Beispiel: Exportiere Service Principals aus deinem Identity Provider, importiere die Datei und sieh, welche Zeilen Fehler haben, bevor du bestätigst.
Jeder Account kann eine benannte Owner-E-Mail-Adresse, einen Zweck, einen verknüpften Dienst und ein Review-Intervall von 30, 90 oder 180 Tagen tragen. Das nächste Review-Datum ergibt sich aus dem Intervall. Accounts ohne Owner bleiben in der Übersicht sichtbar.
Gespeicherte Daten: Owner-E-Mail, Zweck, verknüpfter Dienst, Kennzeichnung als privilegiert, Review-Intervall, nächstes Review-Datum und ein Status wie „Owner benannt“ oder „Klärung nötig“.
Beispiel: Setze svc-backup-veeam auf den Owner j.keller@example.com mit einem Intervall von 90 Tagen. Nach 90 Tagen taucht der Account in der Übersicht wieder auf.
Eine Kampagne bündelt Accounts unter einer Bezeichnung und einem Fälligkeitsdatum. Solange sie ein Entwurf ist, wird nichts verschickt. Sobald du sie veröffentlichst, erhält jeder benannte Owner eine E-Mail mit einem persönlichen Link.
Gespeicherte Daten: Bezeichnung der Kampagne, Start- und Fälligkeitsdatum, Status und pro Account ein Bestätigungsdatensatz mit der Owner-E-Mail zum Zeitpunkt der Veröffentlichung.
Beispiel: Lege „Q4 service account review“ für 40 Accounts mit Fälligkeit 15. Dezember an und veröffentliche die Kampagne, sobald die Owner stimmen.
Der Link öffnet ein kurzes Formular, in dem der Owner die Zuständigkeit bestätigt oder bestreitet, ohne ein Konto anzulegen. Der Owner gibt an, wofür der Account genutzt wird, ob er noch gebraucht wird und ob sein Zugriff überprüft werden sollte. Eine abgelehnte oder unsichere Antwort setzt den Account auf „Klärung nötig“.
Gespeicherte Daten: Die Antwort (zuständig, nicht zuständig, unsicher), Zweck, weiterhin nötig, Markierung für die Zugriffsprüfung, Notizen und den Zeitpunkt der Antwort. Vom Link-Token wird nur ein Hash gespeichert, und der Link läuft 14 Tage nach dem Fälligkeitsdatum der Kampagne ab.
Beispiel: j.keller öffnet den Link, antwortet „I do not own this account“ und notiert „Moved to the platform team“. Der Account erscheint als „Klärung nötig“.
Nachdem ein Owner geantwortet hat, akzeptiert ein Reviewer in deinem Team die Antwort, fordert Klärung an oder öffnet sie wieder. So bleiben die Aussage des Owners und die Einschätzung deines Teams zwei getrennte Fakten.
Gespeicherte Daten: Reviewer, Entscheidung, Zeitpunkt der Entscheidung und der Status jeder Bestätigung in der Kampagne.
Beispiel: Du akzeptierst die Antwort zu svc-backup-veeam und öffnest die zu svc-print-legacy wieder, weil der Zweck vage bleibt.
Ein täglicher Job findet Owner, die noch nicht geantwortet haben. Sie bekommen eine Erinnerung 7 Tage und 2 Tage vor der Fälligkeit, am Fälligkeitstag und danach jede Woche, solange die Antwort überfällig ist. Jede Erinnerung enthält einen frischen persönlichen Link.
Gespeicherte Daten: Jede E-Mail in einem Postausgang mit Status, Empfänger, Betreff und Sendezeit, damit du nachvollziehen kannst, was verschickt wurde.
Beispiel: Ein Owner, der die erste E-Mail ignoriert, bekommt zwei Tage vor dem 15. Dezember eine Erinnerung mit neuem Link.
Importe, Owner-Änderungen, die Veröffentlichung von Kampagnen, Owner-Antworten und Reviewer-Entscheidungen landen in einem Aktivitätsprotokoll, mit Akteur und Kanal (Web, E-Mail oder MCP). Jede Kampagne lässt sich für Auditoren als CSV-Datei herunterladen.
Gespeicherte Daten: Akteur, Aktion, Objekt, vorheriger und neuer Wert und Zeitpunkt. Die Kampagnen-CSV führt jeden Account mit Owner, Owner-Antwort, Reviewer-Status und Notizen auf.
Beispiel: Lade „Q4 service account review“ als CSV herunter und lege sie in deinem Ordner für Audit-Nachweise ab.
Ein Workspace-Admin erstellt in der App ein Token und verbindet einen MCP-Client wie Claude Code oder Cursor. Der Client kann Accounts auflisten, Lücken im Review finden und den Bestätigungsverlauf lesen. Er kann einen Kampagnenentwurf anlegen, veröffentlichen muss ihn aber ein Mensch.
Gespeicherte Daten: Nur einen Hash jedes Tokens, seine Bezeichnung und den Zeitpunkt der letzten Nutzung. Tokens gelten für genau einen Workspace und lassen sich widerrufen.
Beispiel: Frage deinen Assistenten „Which privileged accounts have no owner?“, und er ruft list_owner_review_gaps für deinen Workspace auf.
Jeder Workspace ist durch Row-Level-Security isoliert. Admins fügen bestehende Nutzer als Mitglieder hinzu, im Rahmen des Mitgliederlimits des Plans, und verwalten das Abo im Abrechnungsportal.
Gespeicherte Daten: Workspace-Name, Zeitzone, Mitgliedschaften mit der Rolle Admin oder Member sowie Abostatus und Plan aus Stripe.
Beispiel: Füge einem Team-Workspace eine Kollegin hinzu, die bereits ein Konto hat, bis zu insgesamt fünf Mitgliedern.