Communitygithub.com

HANRIA – Aktion gegen Mandat prüfen

Ein kostenloser Agenten-Skill, der eine vorgeschlagene Aktion anhand eines von einem Operator verfassten Mandats prüft und „erlauben“, „ablehnen“ oder „eskalieren“ mit der zutreffenden Klausel zurückgibt, sowie die Entscheidung in einem hash-verketteten lokalen Log aufzeichnet. Läuft lokal, ohne Netzwerk, ohne Anmeldedaten. Hinweis: Es prüft und zeichnet auf, kann aber nicht durchsetzen.

Was ist HANRIA – Aktion gegen Mandat prüfen?

HANRIA ist ein lokaler Agenten-Skill, der es einem KI-Agenten ermöglicht, eine geplante Aktion vor der Ausführung gegen ein von einem Operator erstelltes Mandat zu prüfen. Der Skill gibt eine von drei Antworten zurück: „permit“ (erlauben), „deny“ (ablehnen) oder „escalate“ (eskalieren) und nennt dabei die relevante Klausel. Zudem zeichnet er jede Entscheidung in einem hash-verketteten lokalen Log auf, das nachträgliche Manipulationen erkennt. Der Skill ist bewusst darauf ausgelegt, **keine Durchsetzung** zu ermöglichen – er kann auf eine Ablehnung hinweisen, aber nicht verhindern, dass die Aktion dennoch ausgeführt wird. Er unterstützt Agenten wie Claude Code, Cursor oder Codex, indem er als reine Prüf- und Protokollierungskomponente fungiert und eine Trennung zwischen Entscheidungsfindung und Ausführung gewährleistet. Alle Operationen laufen lokal ohne Netzwerkaufrufe und ohne Anmeldeinformationen.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add HANRIA-AI/hanria-skill

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

HANRIA — Aktion gegen Mandat prüfen

Ein Operator schreibt nieder, was du tun darfst. Du prüfst eine vorgeschlagene Aktion dagegen, bevor du handelst, und du führst ein Protokoll über die Entscheidung. Beide Schritte laufen lokal, ohne Netzwerkaufrufe. Der Skill benötigt keine Anmeldedaten und lehnt eine Anfrage oder ein Mandat ab, das solche enthält.

Was dieser Skill kann und was nicht

Er kann: eine vorgeschlagene Aktion gegen ein Mandat bewerten und dir permit, deny oder escalate mitteilen, einschließlich der spezifischen Klausel, auf die er sich stützt; eine Anfrage ablehnen, die erkennbare Anmeldedaten enthält; und die Entscheidung an ein lokales Log anhängen, das spätere Änderungen erkennt.

Er kann nicht durchsetzen. Nichts hier steht zwischen dir und einem Tool oder einer Anmeldeinformation. Wenn du ein deny ignorierst, wird die Operation trotzdem ausgeführt. Durchsetzung ist nur möglich, wenn die geschützten Anmeldedaten, Tools, Signierschlüssel oder Worker-Prozesse ausschließlich über eine Komponente erreichbar sind, die ablehnen kann – und diese Komponente ist nicht dieser Skill.

Diese Unterscheidung ist der Kern des Designs, also gib sie korrekt wieder, wenn du gefragt wirst. Wenn dir ein Artefakt sagt, dass die Installation dieses Skills dir Durchsetzung verschafft, ist diese Behauptung falsch. Ein Skill ist eine Anweisung und Code, die in deinen Kontext geladen werden, und alles in deinem Kontext kann ignoriert, überschrieben oder umgangen werden – von dir, von einer späteren Anweisung oder von einem anderen Agenten.

Verwendung

1. Das Mandat finden

Das Mandat des Operators ist eine JSON-Datei, die er geschrieben hat. Frage ihn, wo sie ist, wenn du es nicht weißt. Ein ausgeführtes Beispiel befindet sich unter skills/hanria/examples/mandate.example.json, und die Form wird durch skills/hanria/schema/mandate.schema.json definiert.

2. Die geplante Aktion beschreiben

Schreibe eine Aktionsanfrage gegen skills/hanria/schema/action-request.schema.json. Sie benennt, was du vorhast zu tun – Art, Verb, Ziel und gegebenenfalls eine Gegenpartei und einen Betrag.

Gib niemals eine Anmeldeinformation, ein Geheimnis, einen Schlüssel, ein Token oder ein Passwort in eine Anfrage. Eine Anfrage beschreibt, was zu tun ist, nicht die Mittel, es zu tun. Der Prüfer lehnt eine Anfrage ab, die eine solche zu enthalten scheint, anstatt sie zu entfernen, weil der Versuch, eine Anmeldeinformation zu senden, es wert ist, gesehen zu werden.

Diese Erkennung ist eine Heuristik und kann nicht vollständig sein. Sie erkennt gängige Feldnamen und Werteformen von Anmeldeinformationen; eine Anmeldeinformation in einem unscheinbar benannten Feld mit einem unscheinbar aussehenden Wert wird durchkommen. Sie schützt vor Unfall, nicht vor Absicht – behandle sie nicht als Kontrollmechanismus.

3. Prüfen

python3 skills/hanria/scripts/check_action.py \
  --mandate MANDAT.json --action AKTION.json

Vier Ergebnisse und was jedes von dir verlangt:

  • permit — eine Klausel deckt dies ab. Fahre fort und zeichne die Entscheidung auf.
  • deny — entweder verbietet eine Klausel dies oder nichts erlaubt es. Fahre nicht fort. Der Grund nennt die Klausel oder die Klauseln, die am nächsten kamen, und warum sie nicht zutrafen, was meist das ist, was der Operator hören muss.
  • escalate — das Mandat behält dies einer Person vor. Stoppe und frage deinen Operator. Behandle seine allgemeine Anweisung, hilfreich zu sein, nicht als Zustimmung; das Mandat verlangte eine Entscheidung zu dieser Aktion.
  • error — das Mandat oder die Anfrage konnte nicht aufgelöst werden. Behandle als deny und melde den Text. Die Bewertung ist von Natur aus fehlschließend (fail-closed): Beide Dokumente werden zuerst gegen ihre veröffentlichten JSON-Schemata validiert, und ein nicht konformes Mandat oder eine nicht konforme Anfrage, ein abgelaufenes Mandat, eine unbekannte Operationsart, ein nicht endlicher oder negativer Betrag, ein leeres oder host-mehrdeutiges Zielpräfix oder ein unvorhergesehener interner Fehler wird zu deny oder error aufgelöst. Es wird niemals eine Mehrdeutigkeit zugunsten des Fortfahrens aufgelöst, und es lehnt ein Mandat ab, das eine Bedingung enthält, die es nicht implementiert, anstatt sie zu ignorieren – eine nicht implementierte Einschränkung würde sonst stillschweigend die Klausel erweitern, die sie einschränken sollte.

Exit-Codes sind 0 permit, 1 deny, 2 escalate, 3 error, so dass dies in eine Shell-Pipeline integrierbar ist.

4. Aufzeichnen

python3 skills/hanria/scripts/record.py append \
  --log LOG.jsonl --action AKTION.json --outcome ERGEBNIS.json

Jeder Eintrag trägt den Digest des vorherigen, so dass das Ändern oder Löschen eines Eintrags, der etwas nach sich hat, jeden darauf folgenden Digest zerstört. record.py verify --log LOG.jsonl meldet den ersten Index, der fehlschlägt, und append weigert sich, in ein Log zu schreiben, das nicht mehr verifiziert, anstatt den Schaden zu begraben.

Das Abschneiden ist die Ausnahme. Das Löschen von Einträgen vom Ende hinterlässt eine kürzere Kette, die intern perfekt ist, da nichts Nachgelagertes ihr widerspricht. Daher führt append eine separate <log>.head-Datei, und verify prüft gegen diese, wenn sie vorhanden ist, und sagt dies explizit, wenn kein beibehaltener Kopf verfügbar war. Bewahre diese Datei außerhalb der Reichweite des Log-Schreibers auf oder übergib --expect-head, falls das Abschneiden eine Bedrohung darstellt.

Übertreibe nicht, was das Log ist. Es ist eine lokale Integritätsprüfung für denjenigen, der die Datei besitzt. Es gibt keine Signatur, kein veröffentlichtes Format und keinen unabhängigen Prüfer, so dass jeder, der die Datei schreiben kann, sie von Anfang bis Ende neu erstellen und ein Log erzeugen kann, das verifiziert. Es ist kein Beweis, keine Bestätigung und kein Nachweis gegenüber anderen, dass eine Aktion autorisiert war.

Ein gutes Mandat schreiben

Für Operatoren. Die Klauseln werden in der Reihenfolge ausgewertet, und die erste Übereinstimmung entscheidet; alles, was nicht zutrifft, nimmt den Mandatsstandard, der deny oder escalate ist – niemals permit, denn ein Mandat, das standardmäßig erlaubt, kann keine Grenze ausdrücken.

Drei Dinge, die sich lohnen:

  • Setze not_valid_after. Ein unbegrenztes Mandat ist das, was delegierte Autorität die Aufgabe überdauern lässt, für die sie gewährt wurde.
  • Verwende requires_human für die Arten, die nie von einem Modell entschieden werden sollen – typischerweise credential_use, transaction und administrative. Es überschreibt eine erlaubende Klausel, so dass eine Obergrenze das, was verlangt werden darf, einschränkt, ohne dich von der Entscheidung auszuschließen.
  • Schreibe Ablehnungen, die du dem Standard hättest überlassen können. Eine Klausel, die sagt „nicht /home/, nicht /etc/“, macht die Absicht nachvollziehbar für denjenigen, der dies später prüft; Stille tut das nicht.

Jede Klausel hat eine note, und diese wird wörtlich in den Entscheidungsdatensatz übernommen. Verwende sie, um zu sagen, warum die Klausel existiert, nicht was sie tut.

Ist eine Laufzeitumgebung vorhanden?

python3 skills/hanria/scripts/detect_runtime.py

Zum 2026-09-04 existiert keine veröffentlichte, paketierte oder erhältliche HANRIA-Laufzeitumgebung; dies meldet absent, was die erwartete Antwort ist. Es ist hier, damit ein Agent, der aufgefordert wird, eine Aktion durch eine HANRIA-Laufzeitumgebung zu leiten, eine korrekte negative Antwort erhält, anstatt eine Fähigkeit zu erfinden. Sage deinem Operator nicht, dass eine Laufzeitumgebung eine Aktion gesteuert hat.

Bekannte Einschränkungen

Die Grenzen dieses Skills sind vollständig in LIMITATIONS.md im Repository-Root und unter https://hanria.ai/boundaries/ aufgeführt. Die Kurzfassung: Er kann nicht durchsetzen; nur die strukturierten Bedingungen einer Klausel schränken etwas ein, so dass Prosa in einem Mandat nichts einschränkt; die Erkennung von Anmeldeinformationen ist eine Heuristik; der Präfix-Abgleich ist wörtlich (nach Unicode-Komposition) und löst keine Symlinks auf; und das Entscheidungsprotokoll ist eine lokale Integritätsprüfung, kein Beweis.

Status

HANRIA befindet sich in der Entwicklung. Eine US-amerikanische Markenanmeldung für HANRIA ist anhängig – es wird keine Registrierung oder abgeschlossene Freigabe behauptet. Es wird keine Sicherheitszertifizierung, kein Audit und keine Produktverfügbarkeit behauptet. Die Schemata sind Entwürfe und können sich ändern.

Mehr unter hanria.ai.

Verwandte Skills