Wer hat den Agenten autorisiert? Die Zurechnungslücke bei Servicekonten in der agentischen Finanzwelt schließen

Ein Prüfer zieht eine Buchung heraus, die um 2:14 Uhr an einem Sonntag 2,3 Mio. USD zwischen zwei Kostenstellen verschoben hat. Im Benutzerfeld steht svc_finance_automation. Er stellt die naheliegende Frage: Wer hat das autorisiert? Und im Raum wird es still, denn niemand kann sie beantworten. Die Buchung wurde von einem KI-Agenten erzeugt, der unter einem gemeinsam genutzten Servicekonto läuft, das 14 weitere Automatisierungen ebenfalls verwenden. Es gibt keinen Faden zurück zu einer Person, einer Anforderung oder einer Freigabe. Der Agent hat seine Arbeit getan. Die Kontrolle ist trotzdem ausgefallen.

Dies ist inzwischen der mit Abstand häufigste KI-bezogene Prüfungsbefund im Finanzbereich, und er hat eine nüchterne, strukturelle Ursache. Agenten werden auf dieselbe Weise an ERP-Systeme angebunden, wie es vor fünfzehn Jahren mit Batch-Jobs geschah: über ein generisches technisches Konto mit weitreichenden Dauerberechtigungen. Das war hinnehmbar, solange das Konto ein festes nächtliches Skript ausführte. Es ist nicht mehr hinnehmbar, wenn das Konto inzwischen ein schlussfolgerndes System ist, das kontextabhängige Entscheidungen im Auftrag desjenigen Analysten trifft, der gerade eine Anfrage gestellt hat.

Warum das Servicekonto-Muster unter Agenten zerbricht

Ein Servicekonto existiert, damit Software sich authentifizieren kann, ohne dass ein Mensch ein Passwort eintippt. So weit, so gut. Das Problem liegt darin, wofür das Konto steht. Ein Batch-Job steht für sich selbst: Er tut jede Nacht dasselbe, und seine Identität ist sein Verhalten. Ein Agent steht für denjenigen, der ihn aufgerufen hat, und das wechselt von Minute zu Minute. Wenn die Analystin im FP&A den Agenten bittet, einen Stapel Abgrenzungen umzubuchen, gehört die Aktion zu ihrem Urteil, kanalisiert durch die Ausführung des Agenten. Fassen Sie beides in svc_finance_automation zusammen, und Sie haben die einzigen beiden Fakten gelöscht, die für die Kontrolle zählen: welche menschliche Absicht die Arbeit ausgelöst hat und welche nicht-menschliche Identität sie ausgeführt hat.

SOX war es noch nie wichtig, ob eine Kontrolle von einer Person oder einem Prozess durchgeführt wird. Worauf es ankommt, ist die individuelle Rechenschaftspflicht: Jede Aktion, die sich auf den Jahresabschluss auswirkt, muss auf eine verantwortliche Partei mit angemessener Autorisierung zurückführbar sein. Ein gemeinsam genutztes Servicekonto scheitert daran offenkundig. Sie können keine Funktionstrennung durchsetzen, wenn zehn Agenten und drei Cron-Jobs alle denselben Ausweis tragen. Sie können den Zugriff eines Agenten nicht entziehen, ohne die anderen zu beeinträchtigen. Und Sie können die Absicht nicht rekonstruieren, was die Frage ist, die Prüfer tatsächlich stellen.

Identitätsanbieter haben das Jahr 2026 damit verbracht, darauf hinzuweisen, dass nicht-menschliche Identitäten in den meisten Unternehmen inzwischen zahlreicher sind als Menschen, mit Verhältnissen, die irgendwo zwischen 40 zu 1 und 80 zu 1 angegeben werden. Der Finanzanteil dieser Population ist klein, hat aber eine große Schadensreichweite: Es sind die Identitäten, die das Hauptbuch berühren dürfen. Sie als gesichtslosen Pool von Servicekonten zu verwalten, ist genau der Weg zu der Buchung um 2:14 Uhr, die niemand erklären kann.

Die zwei Identitäten, die Sie auseinanderhalten müssen

Die Lücke zu schließen bedeutet, bei jeder Agentenaktion zwei verschiedene Dinge zu protokollieren und sich zu weigern, sie verschwimmen zu lassen:

• Die nicht-menschliche Identität. Der Agent selbst braucht seine eigene erstklassige Identität, keine geliehene. Eigene Anmeldedaten, eng zugeschnittene Berechtigungen, ein dokumentierter Eigentümer, ein Lebenszyklus. Wird der Agent außer Dienst gestellt, stirbt sein Zugriff mit ihm. Verhält er sich fehlerhaft, entziehen Sie genau eine Sache.
• Der menschliche Auftraggeber. Die authentifizierte Person, deren Sitzung, Anforderung oder dauerhafte Delegation die Arbeit in Gang gesetzt hat. Das ist die Zurechnung, die die Frage „Wer hat das autorisiert?” beantwortet, und genau jene, die gemeinsam genutzte Servicekonten zerstören.

Sicherheitsteams nennen das duale Zurechnung: Binden Sie jede privilegierte Aktion sowohl an die Maschinenidentität, die sie ausgeführt hat, als auch an die menschliche Identität, die sie ausgelöst hat. Der Agent handelt als er selbst, aber im Auftrag einer benannten Person. Beide Hälften werden jedes Mal protokolliert, unveränderlich. Falls ein Agent jemals ohne einen Menschen in der Kette handelt – ein geplanter Lauf, eine autonome Schleife –, muss auch das ausdrücklich erfolgen und der Richtlinie und dem Eigentümer zurechenbar sein, die diese Autonomie genehmigt haben, und darf nicht stillschweigend in einem generischen Konto aufgehen.

Die Unterscheidung ist wichtig, weil die beiden Identitäten unterschiedliche Fragen beantworten. Die nicht-menschliche Identität beantwortet, was erlaubt war und was gelaufen ist. Der menschliche Auftraggeber beantwortet, wer rechenschaftspflichtig ist. Eine Prüfung braucht beides, und ein einzelnes Benutzerfeld kann keines von beidem ehrlich tragen.

Identität ist notwendig. Sie ist nicht hinreichend.

An dieser Stelle räume ich die Grenze der Identitätsarbeit ein, denn genau hier hören viele Governance-Programme zu früh auf. Zu wissen, wer einen Agenten autorisiert hat, sagt Ihnen nichts darüber, ob die Zahl, die er erzeugt hat, korrekt ist. Sie können eine makellose duale Zurechnung auf einer Kennzahl haben, die leise falsch ist – ein Agent, der selbstbewusst eine Marge meldete, die er innerhalb eines LLM berechnet hat, eine Abstimmung halluzinierte oder einen veralteten Saldo zog. Zurechnung macht den Fehler nachvollziehbar. Sie verhindert ihn nicht.

Zurechnung ist also eine Schicht eines Vertrauens-Stacks, nicht der ganze Stack. Die begleitende Frage – können Sie die Zahl selbst verteidigen? – ist Gegenstand unserer Arbeit zu Audit-Trails, die Entscheidungen festhalten, nicht nur Aktionen: das Protokollieren der Schlussfolgerung und der Eingaben, nicht nur des Datenbankschreibvorgangs. Und die Frage, was der Agent überhaupt unbeaufsichtigt tun darf, ist Thema des Frameworks der vier Autonomiestufen. Identität sagt Ihnen, wer. Entscheidungsprotokollierung sagt Ihnen, warum. Autonomiestufen sagen Ihnen, wie weit. Sie brauchen alle drei, und genau darum geht es bei dem agentischen KI-Vertrauens-Layer, auf den wir hinarbeiten.

Wie das in der Praxis aussieht

Ein praktikables Muster, abgeleitet daraus, wie Identity-Governance-Teams diese Befunde tatsächlich schließen:

1. Geben Sie jedem Finanzagenten seine eigene Identität in einem zentralen Inventar, zugeordnet zu einem fachlichen Eigentümer und einer Risikostufe. Keine gemeinsam genutzten svc_*-Konten für Agenten. Niemals.
2. Schneiden Sie Berechtigungen auf die Aufgabe zu, nicht auf die Plattform. Ein Agent, der Forderungen liest, um eine Mahnungsübersicht zu entwerfen, braucht keinen Schreibzugriff auf das Hauptbuch. Weitreichende Dauerberechtigungen sind der Grund, warum 2:14 Uhr passiert.
3. Stempeln Sie jede Aktion mit beiden Identitäten – Agent und menschlicher Auftraggeber – plus dem Token-Geltungsbereich, dem Zeitstempel und der auslösenden Anforderung. Machen Sie das Protokoll unveränderlich.
4. Koppeln Sie die Ausführung an eine deterministische Schicht, nicht an das Modell. Das ist der Teil, den die meisten Identitätsprogramme übersehen, weil er ein Finanz- und kein Sicherheitsproblem ist. Wenn der Agent eine Kennzahl benötigt, sollte er sie aus einem abgestimmten Modell abrufen, das mit dem Hauptbuch übereinstimmt, und jede Berechnung durch eine deterministische Engine laufen lassen – damit die Aktion, die Sie sorgfältig zugeordnet haben, auch eine Aktion ist, die Sie inhaltlich verteidigen können.

Genau dieser letzte Punkt ist es, wofür Rexfin existiert. Wir sitzen zwischen Ihrer KI und Ihren Buchhaltungssystemen – QuickBooks, Xero, NetSuite, Sage, SAP, Oracle, Ihrem Data Warehouse oder hochgeladenen Auszügen – und bauen ein einziges abgestimmtes Finanzmodell, das mit dem Hauptbuch übereinstimmt. Agenten rufen Kennzahlen daraus ab und leiten Berechnungen durch eine deterministische Engine, statt innerhalb des Modells zu rechnen. Wenn der Prüfer also fragt, wer die Buchung autorisiert hat, haben Sie den Menschen und den Agenten dokumentiert; und wenn er fragt, ob die Zahl stimmt, können Sie sie bis zur Quelle zurückverfolgen. Zurechnung und Korrektheit, an derselben Aktion.

Das Fazit

Die Zurechnungslücke bei Servicekonten ist kein Randfall, den Sie später flicken werden. Sie ist die tragende Frage dafür, ob autonome Finanzprozesse überhaupt innerhalb einer SOX-kontrollierten Umgebung existieren dürfen. Ein Agent, den Ihr Prüfer nicht zurechnen kann, ist ein Agent, den Ihr Prüfer Sie abzuschalten heißt. Zwei Identitäten an jeder Aktion – die Maschine, die sie ausgeführt hat, der Mensch, der sie autorisiert hat – sind der Boden, nicht die Decke. Bauen Sie zuerst den Boden.

Wenn Sie zurechenbare, verteidigbare Zahlen hinter Ihre Finanzagenten stellen wollen, buchen Sie eine Demo, und wir zeigen Ihnen die Schicht aus abgestimmtem Modell und deterministischer Ausführung, die das trägt.