HANRIA — アクションをマンデートに対してチェックする は何をしますか？
オペレーターがあなたに許可する行動を書き下します。あなたは行動を起こす前に、提案されたアクションをそれに照らしてチェックし、決定事項を記録します。どちらのステップもローカルで実行され、ネットワーク呼び出しは一切行いません。このスキルは認証情報を必要とせず、認証情報を伴うリクエストやマンデートは拒否します。
このスキルのできることとできないこと
できること: 提案されたアクションをマンデートに対して評価し、permit、deny、escalateのいずれかを、参照した具体的な条項とともに返します。認識可能なクレデンシャル情報を含むリクエストを拒否します。決定をローカルログに追記し、後からの改ざんを検出します。
できないこと: 強制はできません。ここにあるものは、ツールやクレデンシャルへのアクセスを妨げるものではありません。denyを無視しても、操作は実行されます。強制が可能なのは、保護されたクレデンシャル、ツール、署名鍵、ワーカープロセスが、拒否できるコンポーネントを通じてのみ到達可能である場合のみですが、このスキルはそのようなコンポーネントではありません。
この区別こそが設計の要点です。そのため、尋ねられた場合は正確に述べてください。もし何らかの成果物が、このスキルをインストールすることで強制力を得られると伝えてきた場合、その主張は誤りです。 スキルとは、コンテキストに読み込まれる指示とコードであり、コンテキスト内のものはすべて、あなた自身、後続の指示、または別のエージェントによって無視、上書き、またはバイパスされる可能性があります。
使用方法
1. マンデートを見つける
オペレーターのマンデートは、彼らが作成したJSONファイルです。知らない場合は、どこにあるか尋ねてください。動作例が skills/hanria/examples/mandate.example.json にあり、構造は skills/hanria/schema/mandate.schema.json で定義されています。
2. 実行しようとするアクションを記述する
skills/hanria/schema/action-request.schema.json に対してアクションリクエストを作成します。これには、実行しようとしているアクションの種類、動詞、ターゲット、および関連する場合は相手方と金額を指定します。
リクエストにクレデンシャル、秘密鍵、キー、トークン、パスワードを決して入れないでください。 リクエストは「何を行うか」を記述するものであり、「その手段」を記述するものではありません。チェッカーは、クレデンシャルを含んでいると思われるリクエストを、その部分を除去するのではなく拒否します。なぜなら、クレデンシャルを送信しようとする試みは確認に値するからです。
この検出はヒューリスティックであり、完全ではありません。 一般的なクレデンシャルのフィールド名と値の形状を認識しますが、通常の名前と値を持つフィールドにクレデンシャルが入っていれば通過します。これは意図ではなく偶発的なものから保護するものであり、制御として扱わないでください。
3. チェックする
python3 skills/hanria/scripts/check_action.py \
--mandate MANDATE.json --action ACTION.json
4つの結果と、それぞれがあなたに求めること:
permit— ある条項がこれをカバーしています。続行し、その後決定を記録してください。deny— ある条項がそれを禁止しているか、何も許可していません。続行しないでください。 理由には、該当する条項、または最も近い条項とそれらが一致しなかった理由が示され、通常それはオペレーターが聞く必要がある内容です。escalate— マンデートはこれを人間のために留保しています。停止してオペレーターに尋ねてください。 役に立とうとする一般的な指示を承認として扱わないでください。マンデートはこのアクションについて決定を求めています。error— マンデートまたはリクエストを解決できませんでした。denyとして扱い、テキストを報告してください。評価はデフォルトで失敗側に倒れる設計です。両方のドキュメントは公開されたJSONスキーマに対して最初に検証され、準拠していないマンデートやリクエスト、期限切れのマンデート、未知の操作種別、非有限または負の金額、空またはホストがあいまいなターゲットプレフィックス、または予期しない内部障害は、denyまたはerrorに解決されます。進行を優先してあいまいさを解決することは決してなく、実装していない条件を含むマンデートはそれを無視するのではなく拒否します。未実装の制限は、それが狭めることを意図していた条項を静かに拡大してしまうからです。
終了コードは、0 permit、1 deny、2 escalate、3 error であり、シェルパイプラインに組み込むことができます。
4. 記録する
python3 skills/hanria/scripts/record.py append \
--log LOG.jsonl --action ACTION.json --outcome OUTCOME.json
各エントリはその前のエントリのダイジェストを含むため、後に続くエントリがあるエントリを変更または削除すると、後続のすべてのダイジェストが破壊されます。record.py verify --log LOG.jsonl は最初に失敗したインデックスを報告し、append は検証に失敗したログへの書き込みを、損害を埋もれさせるのではなく拒否します。
切り捨ては例外です。 末尾からエントリを削除すると、それ以降にそれと矛盾するものがないため、内部的に完全な短いチェーンが残ります。そのため、append は別の <log>.head ファイルを維持し、verify はそれが存在する場合にそれをチェックし、保持されたヘッドが利用できなかった場合は明示的にその旨を伝えます。切り捨てが脅威となる場合は、そのファイルをログ書き込み者がアクセスできない場所に保管するか、--expect-head を渡してください。
ログの性質を過大評価しないでください。 これはファイルを保持する人のためのローカルな整合性チェックです。署名、公開されたフォーマット、独立した検証者は存在しないため、ファイルに書き込める人なら誰でも最初から最後まで再構築し、検証に合格するログを生成できます。これは証拠でも、証明書でも、アクションが許可されたことの他者への証拠でもありません。
優れたマンデートの書き方
オペレーター向け。条項は順番に評価され、最初に一致したものが決定します。一致しなかったものはマンデートのdefaultを取ります。これはdenyまたはescalateであり、permitは絶対にありません。なぜなら、デフォルトで許可するマンデートは制限を表現できないからです。
3つの価値あること:
not_valid_afterを設定する。 無制限のマンデートは、委任された権限が許可されたタスクを超えて存続することを許してしまいます。- モデルに決定させたくない種類には
requires_humanを使用する — 通常はcredential_use、transaction、administrativeです。これは許可する条項を上書きするため、上限によって、決定からあなたを除外することなく、要求できる範囲を狭めることができます。 - デフォルトに任せられたかもしれない拒否を記述する。 「/home/ ではない、/etc/ ではない」という条項は、後でこれをレビューする人に意図が明確に伝わります。沈黙は伝わりません。
すべての条項はnoteを取ることができ、それは決定記録にそのまま引き継がれます。条項が何をするかではなく、なぜ存在するかを述べるために使用してください。
ランタイムは存在しますか？
python3 skills/hanria/scripts/detect_runtime.py
2026-09-04現在、リリース、パッケージ化、入手可能なHANRIAランタイムは存在しません。これはabsentを報告しますが、それが期待される答えです。これは、アクションをHANRIAランタイム経由でルーティングするよう求められたエージェントが、能力をでっち上げるのではなく、正しい否定回答を得るためにあります。オペレーターにランタイムがアクションを統制したと伝えないでください。
既知の制限
このスキルの制限は、リポジトリルートのLIMITATIONS.mdおよびhttps://hanria.ai/boundaries/に完全にリストされています。簡略版: 強制はできません。条項の構造化された条件のみが何かを制限するため、マンデート内の散文は何も制限しません。クレデンシャル検出はヒューリスティックです。プレフィックスマッチングはリテラル（Unicode合成後）であり、シンボリックリンクを解決しません。決定ログはローカルな整合性チェックであり、証拠ではありません。
ステータス
HANRIAは開発中です。HANRIAの米国商標出願は係属中です — 登録または完了したクリアランスは主張されていません。セキュリティ認証、監査、または製品の入手可能性は主張されていません。スキーマはドラフトであり、変更される可能性があります。
詳細はhanria.aiをご覧ください。