Genehmigungskontrollen für KI-Agenten: Regeln oder klare Entscheidungen

Ein KI-Agent braucht nicht jedes Mal ein kleines Autorisierungsprogramm für Unternehmen, wenn er ein API-Token oder einen SSH-Schlüssel verwenden will. Die meisten Teams brauchen drei Entscheidungen, die auch unter Druck verständlich bleiben: Ist der Geheimnisspeicher verfügbar? Darf dieser Agentenprozess in diesem Lauf handeln? Und erfordert genau dieses Zugangsmittel eine neue Entscheidung durch einen Menschen?

Policy Engines können weit mehr Fragen beantworten. Sie können aber auch jede Änderung einer Berechtigung in ein kleines Softwareprojekt verwandeln, mit vertrauenswürdigen Eingaben, zu testenden Regeln, zu erklärenden Ausnahmen und Fehlern, die genau dann auftreten, wenn jemand eine Bedingung zum schlechtesten Zeitpunkt ändert. Verwende eine Rule Engine, wenn dein Zugriffsproblem tatsächlich wechselnde Zuständigkeiten und Einschränkungen hat. Setze sie nicht als Dekoration um eine einfache Genehmigungsgrenze ein.

Eine Rule Engine macht Autorisierung zur Softwarepflege

Eine Policy Engine ist Code, unabhängig davon, ob ihre Syntax wie Code aussieht. Jemand muss die verfügbaren Fakten definieren, Regeln schreiben, Prioritäten festlegen, Änderungen testen, Versionen veröffentlichen, unerwartete Treffer untersuchen und Regeln entfernen, die nicht mehr zur Organisation passen.

Diese Arbeit kann gerechtfertigt sein. Ein Unternehmen muss möglicherweise verschiedenen Ressourcenverantwortlichen erlauben, Zugriffsbedingungen festzulegen, Aktionen nach Region oder Umgebung zu beschränken oder rechtliche und vertragliche Vorgaben umzusetzen. In solchen Fällen kann eine kleine feste Kontrollmenge verschiedene Fälle in eine grobe Genehmigung zwingen. Der Fehler besteht darin, diese Komplexität als kostenlos zu behandeln, nur weil eine Policy-Sprache sie hinter deklarativer Syntax versteckt.

Betrachte eine bekannte Regel:

allow if
  agent.project == "payments"
  and request.host ends_with ".internal.example"
  and request.method in ["GET", "POST"]
  and time.weekday in ["Mon", "Tue", "Wed", "Thu", "Fri"]

Sie wirkt sinnvoll, bis jemand operative Fragen beantworten muss. Wer weist agent.project zu? Kann der Agent den Wert beeinflussen? Akzeptiert ends_with auch not-internal.example? Was darf POST an einem Endpunkt tun, der erstellen, erstatten, löschen oder eine Überweisung auslösen kann? Was passiert bei einem Vorfall am Samstag? Überschreibt eine spätere Ablehnung eine frühere Genehmigung?

Jede Frage fügt Semantik hinzu. Jede semantische Regel braucht einen Test. Jede Ausnahme wird Teil des Berechtigungsmodells, auch wenn sie in einer hastig geschriebenen Chatnachricht steht und eine Woche später in eine Regel kopiert wird.

Die Dokumentation von Open Policy Agent beschreibt Policies zu Recht als Code und empfiehlt, sie zu testen. Das ist kein Marketingspruch für Flexibilität. Es ist ein Hinweis auf den operativen Vertrag: Wenn eine Policy einen wichtigen Zugriff steuert, muss das Team Änderungen wie Codeänderungen behandeln. Reviewer brauchen Testdaten. CI braucht erwartete Entscheidungen. Ein Bereitschaftsmitarbeiter braucht eine Möglichkeit festzustellen, welche Policy-Version eine Anfrage erlaubt hat.

Viele Teams umgehen diesen Vertrag. Sie kopieren ein paar Regeln in eine Konfigurationsdatei und stellen sechs Monate später fest, dass niemand weiß, ob eine Ablehnung durch einen Tippfehler, eine fehlende Eingabe oder eine beabsichtigte Grenze entstanden ist. Ein KI-Agent macht diesen Fehler sichtbarer, weil er ungewöhnliche Aufrufabfolgen erzeugt und einen übersehenen Zweig viel schneller ausführen kann als ein menschlicher Bediener.

Feste Kontrollen verringern den Pflegeaufwand, indem sie keine beliebigen Bedingungen ausdrücken. Das wirkt begrenzend, weil es begrenzend ist. Die nützliche Frage lautet, ob diese Einschränkung eine Anforderung ausschließt, die du tatsächlich hast, oder nur eine zukünftige Regel, die jemand irgendwann vielleicht wünschen könnte.

Klare Entscheidungen zählen, wenn ein Aufruf Folgen hat

Ein Bediener muss in einem Satz erklären können, warum ein Aufruf erlaubt wurde. Wenn die Antwort erfordert, ein Regelpaket zu lesen, Prioritäten aufzulösen und vom Agenten gelieferte Attribute zu prüfen, kann der Bediener den Zugriff während eines Vorfalls nicht zuverlässig freigeben oder entziehen.

Klare Entscheidungen verhindern außerdem einen stillen Kategorienfehler: Eine Regel kann eine Aktion technisch erlauben, ohne sie für die Person verständlich zu machen, die die Folgen trägt. Ein Hinweis, dass ein unbenannter Prozess Zugriff auf eine allgemeine Fähigkeit angefordert hat, liefert dem Bediener fast keine Grundlage für eine Entscheidung. Das ist eine Formalität, keine Genehmigung.

Eine nützliche Autorisierungsansicht beantwortet konkrete Fragen:

• Welche ausführbare Datei wollte handeln, und wer hat sie signiert?
• Handelt es sich um einen neuen Prozess oder um einen Prozess, der für diese Sitzung bereits genehmigt wurde?
• Welches Zugangsmittel wird die Aktion verwenden?
• Wohin geht die Anfrage oder welchen Host kontaktiert SSH?
• Genehmigt die Person einen Lauf oder eine einzelne sensible Verwendung?

Der erste Punkt verdient mehr Beachtung, als er gewöhnlich erhält. Agentennamen sind Bezeichnungen. Die Prozessidentität ist ein Beleg. Ein Prozess kann sich release-agent nennen, während eine Codesignatur oder ein Pfad zur ausführbaren Datei dem Reviewer etwas liefert, das auch nach der Umbenennung eines Shell-Skripts Bestand hat. Identitätsnachweise beweisen nicht, dass jede Anweisung sicher ist. Sie lenken die Frage aber auf einen echten Prinzipal.

NIST Special Publication 800-207 beschreibt Zero Trust als explizite Überprüfung und fortlaufende Bewertung statt als geerbtes Vertrauen in das Netzwerk. Die praktische Lehre für lokale Agentenaktionen ist einfacher, als viele Implementierungen sie machen: Bewerte Akteur und Anfrage am Ort der Aktion. Übergib einem Agenten kein Token und hoffe dann, dass die Grenze noch sinnvoll ist, nachdem das Token deine Kontrolle verlassen hat.

Klare Entscheidungen sind auch eine Sicherheitseigenschaft. Wenn Menschen eine Genehmigung vorhersagen können, erkennen sie unerwartete Genehmigungen. Wenn ein Coding-Agent, der normalerweise Vorgangsdaten liest, plötzlich ein Produktionszugangsmittel zum Schreiben verwenden will, sollte der Unterschied sichtbar sein, bevor der Aufruf den Rechner verlässt.

Identität, Befugnis und Geheimnisverwendung sind verschiedene Fragen

Teams packen oft drei getrennte Fragen in eine Policy und können anschließend nicht erkennen, welche Annahme falsch war. Halte sie auseinander.

Die Identität fragt, wer die Anfrage gestellt hat. Bei einem lokalen Agenten können dazu der Prozess, seine Codesignatur, sein übergeordneter Prozess und seine Lebensdauer gehören. Eine verständliche Agentenbezeichnung kann helfen, sollte die Sicherheitsentscheidung aber nicht allein tragen.

Die Befugnis fragt, ob dieser identifizierte Prozess in diesem Lauf Aktionen ausführen darf. Eine Sitzungsfreigabe passt zu dieser Frage. Sie hält fest, dass eine Person einen neuen Prozess geprüft und ihm erlaubt hat, ein festgelegtes Aktions-Gateway zu verwenden, bis der Prozess endet oder der Bediener die Freigabe widerruft.

Die Geheimnisverwendung fragt, ob der konkrete API-Schlüssel oder SSH-Schlüssel für diese Aktion verwendet werden darf. Hier gehören eine Tresorsperre und eine Genehmigung pro Zugangsmittel hin. Ein gesperrter Tresor muss jede Aktion ablehnen, unabhängig von einer früheren Sitzungsentscheidung. Ein besonders sensibles Zugangsmittel kann bei jeder Verwendung eine menschliche Genehmigung verlangen, selbst wenn der Prozess bereits über eine Sitzungsbefugnis verfügt.

Wenn diese Fragen vermischt werden, entstehen vorhersehbare Fehler. Ein Team genehmigt einen Agentenprozess einmal und behandelt diese Genehmigung anschließend als Erlaubnis für jedes Zugangsmittel. Oder es entsperrt einen Tresor und verwechselt Verfügbarkeit mit Autorisierung. Oder es schreibt eine Policy, die Prozessnamen und Zielhost prüft, dem Agenten aber erlaubt, das Token abzurufen und an anderer Stelle weiterzuverwenden.

Der letzte Fehler wiegt am schwersten. Wenn ein Agent Zugangsdaten im Klartext hält, hat deine Policy nur die erste Verwendung geprüft. Der Agent kann den Wert an einen Unterprozess weitergeben, in ein Log schreiben, an einen anderen Dienst senden oder nach Ablauf der ursprünglichen Genehmigung weiterverwenden. Ein Gateway, das Geheimnisse vom Agenten fernhält, verändert die Grenze: Der Agent fordert eine Aktion an, und das Gateway führt die authentifizierte Aktion selbst aus.

Diese Unterscheidung geht über «Secret Masking» hinaus. Eine Ausgabe zu schwärzen, nachdem ein Token den Agenten erreicht hat, entfernt es nicht aus seinem Speicher, dem Prompt-Verlauf, der Shell-Umgebung oder einem Kindprozess. Wenn das Token gar nicht erst an den Agenten übergeben wird, fällt eine ganze Klasse versehentlicher Wiederverwendung weg.

Drei explizite Kontrollen decken den normalen Agentenfall ab

Eine kleine Kontrollmenge funktioniert, wenn jede Kontrolle für genau eine Entscheidung zuständig ist und keine vorgibt, die anderen zu ersetzen. Für lokale Entwickleragenten decken drei Kontrollen einen großen Teil des tatsächlichen Risikos ab, ohne eine Policy-Sprache zu erzeugen.

Erstens: Verwende eine absolute Tresorsperre. Solange der Tresor gesperrt ist, schlägt jede Aktion fehl. Das gibt dem Bediener einen physischen und gedanklichen Stopppunkt. Die Entscheidung sollte nicht von einer Regelauswertung, einer gemerkten Sitzung oder einer Netzwerkprüfung abhängen. Auf einem Mac kann das hardwaregestützte Entsperren über Secure Enclave und Touch ID diese Entscheidung besonders deutlich machen: Der Bediener hat den Tresor geöffnet oder nicht.

Zweitens: Autorisiere einen neu erkannten Agentenprozess für seine Lebensdauer. Die Genehmigung sollte den Prozess so identifizieren, dass eine freundliche Namensänderung nicht ausreicht, und beim Beenden des Prozesses ablaufen. So entfällt eine Rückfrage für jeden harmlosen Aufruf, ohne dass die Genehmigung standardmäßig dauerhaft wird.

Drittens: Markiere ausgewählte Zugangsmittel für eine Genehmigung bei jeder Verwendung. Setze das sparsam und bewusst ein. Ein Zugangsmittel für Bereitstellungen, das die Produktionsinfrastruktur ändern kann, eine SSH-Identität mit weitreichendem Hostzugriff oder ein Token, das Geld bewegen kann, rechtfertigt möglicherweise eine sofortige Entscheidung bei jedem Aufruf. Ein schreibgeschütztes Entwicklungs-Token, das ein Agent wiederholt verwendet, normalerweise nicht.

Die daraus entstehende Entscheidungsfolge ist leicht nachzuvollziehen:

if vault is locked:
    deny action
else if this agent process has no current session approval:
    ask for session approval
else if the selected credential requires approval per use:
    ask for credential approval
else:
    execute the action

Das ersetzt kein Least-Privilege-Prinzip. Das Zugangsmittel muss weiterhin einen engen Umfang haben, und der Anfrageweg braucht Transportsicherheit und eine Validierung des Ziels. Die Abfolge macht den menschlichen Kontrollpunkt sichtbar. Sie verwandelt ein Administratortoken nicht in ein sicheres Zugangsmittel.

Die Reihenfolge zählt. Eine Rückfrage pro Aufruf darf niemals eine gesperrte Tresorsperre umgehen. Eine gemerkte Sitzung darf niemals die Genehmigung eines Zugangsmittels umgehen, das bei jeder Verwendung bestätigt werden muss. In einer allgemeinen Rule Engine liegen solche Prioritätsbeziehungen oft in getrennten Policies und werden überraschend schwer zu prüfen. Bei einer festen Abfolge ist die Reihenfolge das Modell.

Eine Policy Engine verdient ihre Kosten, wenn Zuständigkeiten variieren

Eine Policy Engine ist gerechtfertigt, wenn die Autorisierungsentscheidung über viele unabhängig verwaltete Ressourcen hinweg variieren muss und sich diese Variation weder durch die Auswahl des Zugangsmittels noch durch wenige Genehmigungsklassen darstellen lässt.

Nehmen wir an, ein gemeinsamer Automatisierungsdienst verarbeitet mehrere Geschäftsbereiche. Jeder Bereich besitzt unterschiedliche Repositories, Cloud-Konten und Datenspeicher. Die Verantwortlichen müssen temporären Zugriff auf definierte Gruppen gewähren, unterschiedliche Aufbewahrungsbedingungen festlegen und Entscheidungen unter einer zentralen Governance prüfen. Eine Policy-Schicht kann hier das richtige Design sein, weil die Organisation delegierte Regelzuständigkeit und einheitliche Durchsetzung über eine große Landschaft hinweg braucht.

Ein zweiter guter Fall ist ein serverseitiger Dienst, der Anfragen von vielen nicht vertrauenswürdigen Clients erhält. Der Dienst muss möglicherweise Mandant, Rolle, Objekteigentümer, Herkunft der Anfrage und Transaktionsstatus prüfen, bevor er handelt. Eine feste lokale Sitzungsfreigabe kann das nicht ersetzen. Der Server muss jede Anfrage entscheiden, auch wenn kein Mensch in der Nähe sitzt, um sie freizugeben.

Übertrage diese Fälle nicht auf jeden lokalen Coding-Agenten. Auf einem Entwicklerrechner ist die Frage meist kleiner: Darf dieser signierte Agentenprozess dieses gespeicherte Zugangsmittel über dieses Aktions-Gateway verwenden, während der Bediener es erlaubt? Der Mensch kennt den lokalen Kontext bereits. Bedingungen zu Zeitfenstern, Projekt-Tags und spekulativen Risikowerten können mehr falsches Vertrauen als Kontrolle erzeugen.

Es gibt noch eine harte Grenze. Eine Policy kann ein zu weitreichendes Zugangsmittel nicht reparieren. Eine Regel kann Anfragen an nur einen Host erlauben. Wenn der Agent aber das Bearer-Token auslesen kann, muss der Aussteller des Tokens dessen Umfang selbst durchsetzen. Halte das Geheimnis im Gateway und begrenze es beim Anbieter. Betrachte die Gateway-Autorisierung als eine Schicht, nicht als Ersatz für die Zugriffskontrolle der Ressource.

Genehmigungsmüdigkeit bedeutet, dass der Umfang falsch ist

Wiederholte Rückfragen machen Menschen schneller, nicht aufmerksamer. Wenn jemand dieselbe Genehmigungskarte zwanzigmal sieht, während ein Agent Repository-Metadaten abruft, lernt diese Person, dass ein Klick die Arbeit fortsetzt. Die elfte Anfrage, die sich in einem wichtigen Punkt unterscheidet, erhält dann dieselbe reflexartige Zustimmung.

Die übliche Antwort besteht darin, intelligentere Regeln zu bauen, die Rückfragen unter immer spezifischeren Bedingungen unterdrücken. Häufig wird sichtbare Müdigkeit so gegen unsichtbare Komplexität getauscht. Jemand schreibt eine Ausnahme für Leseaufrufe und stellt dann fest, dass ein angeblich lesender Endpunkt eine entfernte Berechnung auslöst oder Daten offenlegt, die eigentlich geprüft werden müssten. Die Zahl der Genehmigungen sinkt, während die Entscheidung schwerer zu kontrollieren ist.

Lege den Genehmigungsumfang nach dem menschlichen Urteil fest, das erforderlich ist. Eine Sitzungsfreigabe sagt: «Ich erkenne diesen Prozess und erlaube ihm, mit den normalen Zugangsmitteln dieses Laufs zu arbeiten.» Eine Genehmigung pro Aufruf sagt: «Diese Verwendung eines Zugangsmittels hat weitreichende Folgen genug, dass ich sie einzeln prüfen werde.» Keine der beiden Rückfragen sollte nur existieren, weil eine Implementierung einen Bestätigungsdialog anzeigen möchte.

Ein gutes Design der Zugangsmittel erleichtert das. Teile Zugangsmittel nach ihren Folgen auf, statt ein mächtiges Token zu behalten und darauf zu hoffen, dass eine Policy jeden Aufruf filtert. Gib dem Agenten ein eng begrenztes Token für normale Entwicklungsarbeit. Halte das Token für Änderungen an der Produktion getrennt und verlange bei seiner Verwendung eine ausdrückliche Entscheidung. Das kann mehr Zugangsmittel erzeugen, entfernt aber fragile Anfrageanalysen aus der Autorisierungsgrenze.

Eine abgelehnte Empfehlung verdient eine direkte Antwort: «Verlange für jede Agentenaktion eine Genehmigung» klingt sicher, weil dadurch ein vollständiger Datensatz menschlicher Klicks entsteht. Für wiederholte Aufrufe mit geringen Folgen ist das meistens falsch. Menschen können eine Flut ähnlicher Anfragen nicht gut prüfen. Verlange eine Genehmigung dort, wo der Reviewer eine eigenständige Entscheidung treffen kann, und protokolliere den Rest, damit das Team das tatsächliche Verhalten untersuchen kann.

Eine harmlose Regel kann eine schädliche Anfrage autorisieren

Ein typischer Fehler beginnt mit einem Team, das einem Agenten erlauben möchte, einen Staging-Dienst zu aktualisieren. Es richtet eine Regel ein, die POST-Anfragen an api.example.internal erlaubt, wenn der Agent das Projekt staging angibt. Der Agent erhält ein Token in seiner Umgebung, weil das Gateway es nicht direkt einsetzen kann.

Während einer Fehlersuche folgt der Agent einem kopierten Befehl, der denselben Host, aber einen Verwaltungsendpunkt verwendet. Der Endpunkt akzeptiert POST und unterstützt eine Aktion, die eine Konfiguration in die Produktion befördert. Die Policy sieht eine erlaubte Methode, einen erlaubten Host und ein erlaubtes Projektlabel. Sie gibt «allow» zurück.

Das Team kann dies als Policy-Fehler bezeichnen, doch tatsächlich sind mehrere Dinge schiefgelaufen:

1. Die Methode war zu weit gefasst, um eine Absicht zu beschreiben.
2. Das vom Agenten kontrollierte Projektattribut belegte keine Zuständigkeit.
3. Der Host enthielt Endpunkte mit sehr unterschiedlichen Folgen.
4. Das Token befand sich außerhalb des Durchsetzungspunkts und konnte nach der Anfrage wiederverwendet werden.
5. Der Bediener sah keine Entscheidung, die zwischen Staging-Änderungen und einer Beförderung in die Produktion unterschied.

Das Ergänzen von Routenmustern kann diese konkrete Lücke schließen. Dann fügt jemand einen versionierten Pfad, einen alternativen Hostnamen, einen Batch-Endpunkt oder einen Query-Parameter hinzu, der das Verhalten verändert. Die Policy wächst, weil das zugrunde liegende Zugangsmittel zu viel kann.

Ein besseres Design trennt Staging- und Produktionszugangsmittel. Die normale Sitzung kann das Staging-Zugangsmittel über das Gateway verwenden. Das Produktionszugangsmittel verlangt eine Genehmigung pro Verwendung, und die Genehmigung nennt Ziel und Aktion. Das Gateway setzt das Zugangsmittel ein und gibt das Ergebnis zurück, während der Agent seinen Wert nie erhält.

Auch dieses Design hängt davon ab, dass der API-Anbieter beide Zugangsmittel korrekt begrenzt. Es verhindert nicht, dass ein genehmigter Agent eine fehlerhafte Änderung im Staging vornimmt. Es sorgt aber dafür, dass ein Staging-Ablauf nicht stillschweigend durch eine lockere Regel und ein wiederverwendbares Token Produktionsbefugnisse erbt.

Teste Ablehnungspfade, bevor ein Agent sie für dich testet

Autorisierungstests sollten belegen, dass das System Aktionen unter erwarteten Bedingungen verweigert, nicht nur, dass eine normale Anfrage erfolgreich ist. Die nützlichen Testfälle sind klein genug, um sie auszuführen, bevor ein Team Zugangsmittel oder Agentenintegrationen ändert.

Bei einer festen Entscheidungsfolge solltest du die erwarteten Ergebnisse als Tabelle festhalten und neben der Implementierung aufbewahren:

Diese Tabelle erkennt eine wichtige Klasse von Regressionen: Ein Entwickler fügt einen Komfortpfad hinzu, der die Sitzungsbefugnis vor dem Tresorstatus prüft, oder lässt einen gemerkten Prozess die Genehmigung eines Zugangsmittels pro Aufruf überspringen. Die Tabelle macht die beabsichtigte Reihenfolge überprüfbar, ohne dass man eine Policy-Sprache lernen muss.

Bei einer Policy Engine solltest du mehr testen als Beispiele, die erlaubt werden sollen. Teste fehlende Attribute, fehlerhafte URLs, alternative Hostnamen, Änderungen der Policy-Version, Regelkonflikte, Uhrzeitänderungen und ausdrückliche Ablehnungen. Das Testmodell von Open Policy Agent unterstützt Regeltests. Die schwierige Arbeit bleibt jedoch bei dir: Entscheide, welche Eingaben ein Angreifer, ein fehlerhafter Agent oder eine zukünftige Integration beeinflussen kann.

Teste auch den Widerruf, während ein Agent aktiv ist. Starte eine Sitzung, genehmige sie, führe eine normale Aktion aus, widerrufe den Zugriff und wiederhole dieselbe Anfrage. Der zweite Versuch muss am Aktions-Gateway eine Ablehnung erzeugen. Ein Widerruf, der nur einen Dashboard-Eintrag ändert, während ein Prozess ein verwendbares Zugangsmittel behält, hat die tatsächliche Befugnis nicht widerrufen.

Prüfe bei HTTP das zurückgegebene Ergebnis auf genügend Kontext, um den Fehler zu diagnostizieren, ohne Autorisierungsheader offenzulegen. Stelle bei SSH sicher, dass der Helfer die ausgewählte Identität für die Verbindung verwendet, aber kein Material des privaten Schlüssels an den aufrufenden Agenten übergibt. Diese Details wirken nebensächlich, bis ein Vorfall das Team zwingt festzustellen, was der Prozess tatsächlich besaß.

Ein Audit-Log muss eine andere Frage beantworten als eine Rückfrage

Genehmigungskontrollen verhindern eine Aktion im Moment ihrer Ausführung oder erlauben sie. Ein Audit-Log teilt dir später mit, was passiert ist, wer es genehmigt hat und ob jemand den Datensatz verändert hat. Vermische diese Aufgaben nicht in einer vagen Funktion für «Verantwortlichkeit».

Ein nützlicher Ereignisdatensatz enthält die Sitzungsidentität, die getroffene Entscheidung, die Referenz des Zugangsmittels statt seines Geheimniswerts, die Aktionsart, das Ziel, das Ergebnis und Informationen zur Reihenfolge. Er sollte auch den Widerruf einer Sitzung erfassen. Ohne diese Verbindung sehen Ermittler zwar eine Anfrage, können aber nicht feststellen, ob sie vor oder nach dem Entzug der Genehmigung durch den Bediener stattfand.

Bei Nachweisen gegen Manipulation ist eine genaue Formulierung wichtig. Eine Hash-Kette kann spätere Änderungen oder Löschungen erkennbar machen, wenn ein Prüfer über die erwarteten Kettendaten verfügt. Sie kann nicht beweisen, dass ein kompromittiertes System von Anfang an jedes Ereignis aufgezeichnet hat. Sie kann auch nicht entscheiden, ob eine Genehmigung klug war. Das Log liefert Belege über die aufgezeichnete Vergangenheit, keine Zeitmaschine.

Für ein lokales Gateway bietet ein verschlüsseltes Audit-Log, in das der ausführende Prozess nur schreiben kann, eine nützliche Trennung: Die Komponente, die Aktionen ausführt, schreibt Ereignisse, während normale Leser projizierte Journale nutzen, statt die Historie umzuschreiben. Eine Offline-Prüfung ist besonders nützlich, weil dafür weder ein verfügbarer Dienst noch ein Entschlüsselungsschlüssel erforderlich ist, nur um die Struktur der Kette zu prüfen.

Sallyport zeichnet Agentenläufe in einem Sessions-Journal und einzelne Aktionen in einem Activity-Journal auf. Beide werden aus einem verschlüsselten, hashverketteten Audit-Log erstellt. Der Befehl sp audit verify prüft die Kette offline über Chiffretext. Das ist die richtige Richtung für ein Log, das wichtig werden kann, nachdem der Rechner unter Verdacht geraten ist.

Halte die Audit-Prüfung praktisch. Wenn ein Agent dich überrascht, identifiziere zuerst den Prozess, der die Sitzungsfreigabe erhalten hat, liste die Aktionen in zeitlicher Reihenfolge auf, widerrufe die aktive Sitzung und prüfe die Logs des betroffenen Anbieters. Das lokale Journal erklärt, was das Gateway passiert hat. Der Zieldienst erklärt, was das entfernte System akzeptiert hat.

Wähle das kleinste Entscheidungsmodell, das du betreiben kannst

Beginne mit dem tatsächlichen Autorisierungspfad, nicht mit einem abstrakten Wunsch nach Flexibilität. Liste die Zugangsmittel auf, die ein Agent braucht, identifiziere diejenigen mit Folgen, die eine neue Genehmigung rechtfertigen, und entscheide, wie eine Person einen aktiven Prozess widerrufen kann. Wenn daraus drei stabile Entscheidungen entstehen, halte sie explizit.

Führe eine Policy Engine ein, wenn die Organisation Regelzuständigkeit und Variationen braucht, die sich durch eine Aufteilung der Zugangsmittel sowie Sitzungs- und Einzelgenehmigungen nicht ausdrücken lassen. Akzeptiere dann aber auch die daraus folgende Verpflichtung: Versioniere Policies, teste feindliche Eingaben, dokumentiere Prioritäten, benenne Verantwortliche und prüfe Ausnahmen so sorgfältig wie Code.

Das schlechte Design sind weder «Regeln» noch «Rückfragen». Schlecht ist eine Autorisierungsgrenze, die niemand erklären kann, während ein Agent auf seine Aktion wartet. Wenn dein Team nicht sagen kann, warum eine Anfrage erlaubt ist, verkleinere das Entscheidungsmodell, bevor du es intelligenter machst.