Rechte im System.

Jede Prüfung beantwortet eine Frage mit vier Teilen: Wer handelt in welcher Rolle, welche Handlung, an Daten mit welcher Markierung, zu welchem Zweck. Rollen bündeln Handlungen, das ist der rollenbasierte Teil (RBAC). Markierung und Zweck sind Attribute der Daten und der Anfrage, das ist der attributbasierte Teil (ABAC). Erlaubt ist nur, was auf allen vier Achsen erlaubt ist.

Rollen allein reichen nicht. Eine Rolle darf Objekte eines Typs lesen, aber nicht deren Felder mit der Markierung vertraulich, und nur zu dem Zweck, für den der Auftrag eingerichtet wurde. Der Zweck kommt aus dem Auftrag, nicht aus dem Text, den ein Sprachmodell erzeugt. So bildet das System die Zweckbindung ab, die Artikel 5 der DSGVO verlangt.

Ohne passende Regel gilt Ablehnung. Eine Lücke in den Regeln öffnet nichts, sie fällt bei der nächsten abgelehnten Anfrage auf.

Ein Sprachmodell hält sich nicht verlässlich an Anweisungen. Darum entscheidet die Laufzeit von AXON und nicht das Sprachmodell. Jeder Werkzeugaufruf geht an einen Durchsetzungspunkt im Server (Policy Enforcement Point), der eine Entscheidungsstelle (Policy Decision Point) mit Handelndem, Auftraggeber, Handlung, Objekt, Markierung und Zweck befragt. Erst ein ausdrückliches Ja führt den Aufruf aus. Die Begriffe stammen aus XACML und dem Leitfaden NIST SP 800-162.

Die Regeln liegen als Daten vor und sind versioniert. Sie lassen sich in einer Regelsprache wie Rego (Open Policy Agent) oder Cedar schreiben und vor dem Einsatz gegen Testfälle prüfen: Für jede Rolle steht fest, welche Anfragen angenommen und welche abgelehnt werden müssen.

Auch Lesen ist eine Handlung. Felder ohne Leserecht kommen gar nicht erst in den Kontext des Sprachmodells, statt nachträglich ausgeblendet zu werden. Was ein Sprachmodell nie gesehen hat, kann es auch nicht weitergeben.

Ein Agent meldet sich nie mit dem Konto einer Person an. Er hat eine eigene Identität, und jede Sitzung bekommt kurzlebige Zugangstoken mit eng begrenztem Geltungsbereich (scope) und festem Empfänger (aud): nur die Handlungen und nur das Zielsystem des Auftrags, gültig für Minuten statt für Tage.

Wird dem Auftrag ein Recht entzogen, scheitert der nächste Aufruf an der Prüfung im Server, und ein neues Token mit diesem Recht stellt AXON nicht mehr aus. Die Bindung des Tokens an einen Schlüssel des Agenten, nach DPoP (RFC 9449) oder über Mutual TLS (RFC 8705), sorgt dafür, dass ein abgegriffenes Token an anderer Stelle nicht nutzbar ist.

Zugangsdaten zu Zielsystemen hält die Laufzeit. Sie stehen nie im Kontext des Sprachmodells, in Werkzeugbeschreibungen oder im Verlauf.

Handelt ein Agent für eine Person, tauscht AXON das Token der Person und die Identität des Agenten gegen ein neues Token: OAuth 2.0 Token Exchange nach RFC 8693. Das neue Token nennt die Person als Subjekt (sub) und den Agenten als Handelnden im Claim act. Jede Stelle, die es prüft, weiß damit, wer beauftragt hat und wer ausführt.

Der Geltungsbereich des neuen Tokens ist höchstens die Schnittmenge aus dem, was die Person darf, und dem, was die Rolle des Agenten darf. Ein Agent hat so nie mehr Recht als die Person, die ihn beauftragt. Das gilt auch über eine Kette von Agenten: Jede Weitergabe kann den Geltungsbereich nur verengen, und act verschachtelt sich mit jedem Glied, sodass die ganze Kette lesbar bleibt.

Jede Entscheidung, auch jede Ablehnung, wird festgehalten: Handelnder, Auftraggeber, Handlung, Objekt, Markierung, Zweck, Version der Regeln und Ergebnis. So lässt sich später zeigen, warum ein Agent etwas durfte oder nicht durfte, mit genau der Regel, die damals galt.

Was die Grenze einer Rolle überschreitet, endet nicht als stille Ablehnung. Es wird als Freigabe für genau diese Handlung einer berechtigten Person vorgelegt; wie das Ja gebaut ist, beschreibt die Seite zur Freigabe.