Lotor

Lotor

AI エージェントのセッションにおける、ローカルな記録と承認のゲートです。エージェントは操作できますが、署名はできません。

これは何か

Lotor は、セッション中にエージェントが行ったことを、署名付きで改ざんを検出できるログに記録します。実行した操作、アクセスしたファイル、送信したメッセージ、発生したコスト、遭遇した失敗などが記録されます。ログはお使いのマシン上に保存され、確認、検証、アーカイブが可能な形式です。

エージェントの操作が正しかったことを証明するものではありません。操作を記録し、後からの改ざんを検出できるようにします。

また、選択した操作にゲートを設けます。これらの操作は、モデルが見たことも導き出すこともできないパスフレーズで署名された承認があるまで停止します。エージェントは重大な操作を要求できますが、承認することはできません。

ローカル優先であり、デプロイ方法の選択肢としてのローカルではありません。 記録はお使いのマシンに書き込まれ、それ以外の場所には送られません。アップロード経路も、アカウントも、サーバーコンポーネントもありません。送信する仕組みがないため、外部に出るものもありません。アカウンタビリティツールの多くはクラウド監視であり、その場合、エージェントの履歴は誰かの台帳に記載される在庫になります。ローカルで動作するものは Lotor だけではありません。Obsigna（agentreceipts.ai）は、Claude Code のフックを備えたローカルの署名付き改ざん検出可能な記録を提供し、正式検証済みで、このリポジトリより前から存在しています。このリポジトリが記録に加えるのは、人間が署名するまで操作をブロックするゲートと、自らの限界を明らかにする台帳です。マシンが何をしたかの記録は、ベンダーの保持ポリシーではなく、あなたの鍵に従うべきです。

それが重要である理由についての詳しい主張は、ikeanalytics.com にあります。その主張の根拠となる測定もご覧ください。このファイルでは、実際の実行方法を説明します。

用途

何が実行されたかを把握する。 トランスクリプトを読み直す代わりに、記録に尋ねてください。再構成するより手間がかからず、エージェント自身の説明に左右されることもありません。このプロジェクトのあるワーカーはかつて、自身の報告の中で不確実性を認めるためのセクションに、実行中のモデルを記載しましたが、それは間違っていました。記録のほうは正確でした。

稼働中は眠っている。 誰も立ち会わない実行のあと、決して読むことのないトランスクリプトの山ではなく、署名付きの報告を確認して目を覚ましましょう。

コストの高い操作を止める。 削除、デプロイ、送信、支出は、該当する操作と正確なパラメーターに署名するまで、フェイルクローズで拒否されます。拒否も承認も、どちらも記録されます。

自分のコピーを保持する。 クライアント、ベンダー、または取引相手が何が起きたかを争う場合でも、記録はあなたのものです。相手の台帳に加えて、今やあなた自身の台帳もあります。

主張の節度

告発ではなく、測定です。記録されるのは、セッションが自己申告した内容です。意図を判断することはなく、表面化しない失敗を検出することもありません。

自己申告によるキャプチャです。ログは署名した時点から始まります。それより前に起きたことは、チェーンの対象外です。

ここで現在形で書かれている内容は、すべて実装済みです。未実装のものは、保留中として、以下またはKNOWN-LIMITS.mdのいずれかに、同じ文脈で明記しています。

群れのモード

複数のエージェントが連携するときは、ペットではなく家畜として扱うべきです。Lotor はそのために設計されています。

エージェントが1つなら、信頼するのは簡単です。与えた意図に沿って動き、以下のモードもその意図を言い換えるだけです。エージェントを一緒に働かせると、状況は変わります。群れはどの動物も単独では選ばなかった動きをします。人も同じです。集団の中では周囲に流され、一人なら選ばないような判断をします。アクションにゲートを設けることは、個々のエージェントへの判決ではありません。群れが動く間、それを囲い留める柵です。

10種類のマッチャーを頭の中で使いこなすのは、誰にとっても無理があります。3つのプリセットを使えば、マトリクスの代わりに1つ選ぶだけで済みます。

モード	姿勢	外部送信ルール（push、publish、egress-other、opaque-exec）	ローカルのみのルール（destructive、scope-escalation）
Herded	囲いの中	ゲート	ゲート
Grazing	柵の中、新規インストール時のデフォルト	ゲート	警告
Loose	開けた牧草地	警告	警告

self-mod と mode-change は、例外なくすべてのモードでゲートされます。Loose は、世界に対して自由に行動できるという意味であり、あなたを制止する仕組みを書き換えてよいという意味ではありません。Loose のエージェントも、あなたの署名なしにゲート、そのポリシー、そのフックを編集したり、モードを切り替えたりすることはできません。

Loose でもルールが完全に off になることはありません。警告が出され、記録が追加されます。そうしなければ、最も危険なモードが最も証拠を残さないものになってしまいます。一致するルールがない場合、チェーンへの書き込みを行わずに処理する高速経路が使われるためです。

npm run mode              # print the current mode and its rule-by-rule expansion
npm run mode -- herded    # switch (requires your approval passphrase at a real terminal)

現在のモードはすべてのセッションの開始時の記録に刻まれるため、モードを切り替えても後から見えなくなることはありません。この機能より前から存在する policy.json が、黙ってアップグレードされることはありません。既存のルールを維持したまま、custom モードとして読み込まれます。

正直に言えば、できることには限界があります。 Lotor のモードは、ハーネス独自の権限モードとは独立しており、互いの不足を補うことはありません。Lotor が Loose で、ハーネスが独自のチェックを回避する設定になっていれば、どちらのレイヤーでも本当に何も止められない状態になります。Lotor はこの組み合わせを検出すると警告し、その姿勢をセッションごとに一度記録します。検出は保護ではありません。KNOWN-LIMITS.md の項目15を参照してください。

インストール

Lotor をインストールするとは、2つの不変条件を受け入れることです。記録はあなたのマシンにのみ書き込まれ、他の場所には送信されないこと。そして、ゲートの対象にしたアクションは、あなたが署名するまでフェイルクローズすることです。以下で選ぶのは、これらを「どこで」実施するかであり、「実施するかどうか」ではありません。

2つ目の条件は、正確に理解してください。ゲートの対象となるのは、あなたが gate に設定したルールのうち、ツール名とパラメーターが一致するものです。これは、マシンから何も外部へ出ないという主張ではありません。マッチャーで検出できるものとできないものについては、KNOWN-LIMITS.md の項目11を参照してください。また、インストール環境でゲートされるルールと、警告のみのルールについては lotor_status を確認してください。

Lotor は別々にインストールする2つの要素で構成されています。照会、検証、承認を行うツールを提供する MCP サーバー。そして、実際に記録し、ゲートする 4つの Claude Code フックです。片方だけをインストールすると、Lotor が動作していると思い込むことになりがちです。

前提条件

• Node 18 以降。Claude Code にインストールする場合は、動作する claude CLI も必要です。
• テキストエディターと、JSON ファイルを手作業で編集する意思。 これが意外に思われる方も多いため、手順5で初めて気づくのではなく、ここに記載しています。

Lotor が独自のフックをインストールしない理由。 インストールすることは可能です。しかし、意図的にそうしていません。設定に独自の強制機能をひそかに登録できるツールは、それをひそかに解除することもできるツールです。また、承知のうえでインストールしていないゲートを信頼する理由はありません。設定ファイルは脅威モデルの外ではなく、その内側にあります。代わりに必要なのは、貼り付けを1回行うことです。その見返りに、何が動作しているのかを正確に把握できます。

1. 実行場所

インストール先	受け取れる内容	範囲
Claude Code、ユーザースコープ	すべてのプロジェクトにおける、すべての Claude Code セッション	最も広く、常時有効
Claude Code、プロジェクトスコープ	その 1 つのリポジトリ内で開始されたセッションのみ	プロジェクト単位
Claude Desktop 拡張機能（.mcpb）	Claude Desktop アプリのセッション	デスクトップアプリ

claude mcp add lotor -s user -- node /absolute/path/to/lotor/src/mcp/server.js

代わりに -s project を指定すると、Lotor を 1 つのリポジトリに設定し、そこにコミット対象の .mcp.json が書き込まれます。ワンクリックでデスクトップに設定する方法については、MCP-SETUP.md をご覧ください。

2. レシートの保存場所

Lotor は、履歴が分断されないよう、正規のストアを 1 つだけ保持します。デフォルトでは ~/.lotor、Windows では %USERPROFILE%\.lotor です。どのディレクトリからクライアントを起動したかにかかわらず、すべての CLI と MCP サーバーが同じストアを読み書きします。LOTOR_HOME で変更できます。

実際のローカルディスクに保存してください。 LOTOR_HOME を同期対象のクラウドフォルダーに指定すると、レシートログをサードパーティに再び預けることになります。これはまさに、Lotor が取り除くために存在するリスクです。

3. 有効化する

クライアントはセッションの開始時に MCP サーバーを読み込みます。セッションを再起動するか、新しいセッションを開いてください。インストール時に使用したセッションを再起動すれば十分です。

4. 初回実行：キーを設定する

npm run setup

セットアップによってログ整合性キーが作成され、その後、承認キーのパスフレーズ設定に進みます。承認キーの秘密鍵部分がディスクに書き込まれることはありません。 アクションを承認する時点でパスフレーズから導出され、それ以外の場所では導出されません。

キーを設定しても、ゲートは有効になりません。 キーは署名の生成に使われます。アクションを停止して署名を求めるのはフックです。パスフレーズを設定してもフックが登録されていない Lotor のインストールでは、何も記録されず、何もブロックされません。手順 5 に進んでください。

5. フックを登録する（必須）

この手順によって、Lotor はライブラリからゲートになります。省略すると、空のログを照会するツールをインストールしただけです。

Claude Code の設定ファイル（~/.claude/settings.json、Windows では %USERPROFILE%\.claude\settings.json）を開き、独自の絶対パスに置き換えて、以下のブロックを統合してください。すでに hooks キーがある場合は、置き換えるのではなく、その中に以下の 4 つのイベントを追加してください。Windows を含むすべてのプラットフォームで、スラッシュを使用できます。

{
  "hooks": {
    "SessionStart": [
      { "hooks": [ { "type": "command", "command": "node /absolute/path/to/lotor/bin/hook-session-start.js" } ] }
    ],
    "PreToolUse": [
      { "hooks": [ { "type": "command", "command": "node /absolute/path/to/lotor/bin/hook-pre-tool-use.js" } ] }
    ],
    "PostToolUse": [
      { "hooks": [ { "type": "command", "command": "node /absolute/path/to/lotor/bin/hook-post-tool-use.js" } ] }
    ],
    "SessionEnd": [
      { "hooks": [ { "type": "command", "command": "node /absolute/path/to/lotor/bin/hook-session-end.js" } ] }
    ]
  }
}

フック	動作	ない場合に起きること
SessionStart	記録を開始します：セッション ID、適用中のポリシー、チェーンの先頭、フック登録状況	セッションが異常終了しても痕跡が残らず、ログは問題がないように見えます
PreToolUse	ゲートとして機能します：署名するまで、ゲート対象のルールはフェイルクローズになります	ポリシーの内容にかかわらず、何もブロックされません
PostToolUse	外部送信に該当する呼び出しの完了を記録します	外部送信のアクティビティは、後から再構成するしかありません
SessionEnd	記録を終了します：実行した内容、操作した対象、コスト	セッションのレシートが記録されません

JSON を手作業で編集したくない場合は、対話型の claude CLI にある /hooks コマンドを使うと、メニューから同じファイルを編集できます。

編集後はセッションを再起動してください。 フックはセッションの開始時に読み込まれるため、変更は次のセッションから反映されます。

これらのフックがセッションを壊すことはありません。終了コードが 0 以外になるのはゲートだけで、意図的にブロックするときに限られます。標準出力への書き込みもありません。それ以外のエラーはすべて、標準エラー出力に 1 行のメモを残して無視されます。エディターを操作不能にするレシートレイヤーは、レシートレイヤーがないよりも悪いものです。

注意すべき点が 2 つあります。フックの登録情報は編集可能なファイルに保存されるため、脅威モデルに含める必要があります。SessionStart はその時点で存在するフックを記録するため、セッション間に行われた編集は次回の開始時に明らかになります。また、ゲートが対象にするのは、そのフックが読み込まれた後に実行されたツール呼び出しのみです。

6. 稼働中であることを確認する

npm run receipts

SESSION OPENS ブロックを確認してください。セッションが稼働中なら、開いたセッション数が閉じたセッション数より1つ多くなります。それが現在のセッションです。Opened: 0 と表示されている場合、SessionStart フックが登録されておらず、手順5が適用されていません。 Claude 内では、lotor_status ツールでも同じ内容を確認できます。

手順5をまったく行わない場合、自動では何も記録されず、npm run ingest -- /path/to/session.jsonl を使って手作業でトランスクリプトを取り込むことになります。

委任許可

1回限りの承認は、特定のコマンド1つに適用され、1回使うと消費されます。デプロイには適していますが、作業セッションには適していません。承認が必要な操作が40回あれば、ターミナルに40回移動することになり、手間のかかるゲートは無効化されてしまいます。それこそが、このゲートで防ごうとしていた事態です。

許可は、列挙されたN件のリクエストに対する1つの署名で、1つのセッションに紐付き、有効期限と共通の操作上限を持ちます。パスフレーズの入力を求める前に、すべてのリクエストが省略されずにそのまま表示されます。その一覧を読むことが、この仕組みのセキュリティです。

npm run grant -- --session <id> --all-pending --max-actions 20 --expires-in-ms 3600000

委任できない中核部分。 許可によって検証機能を編集できてしまうと、今後のすべての許可範囲を広げられるため、ハードコードされたパスの一部は、どの許可でも対象にできません。ゲート、ポリシー、フック、キーの取り扱い、そして許可の仕組み自体が該当します。これらに関する作業では、今後も操作ごとに1つの署名が必要です。負担を抑えられるよう、中核部分は小さくしています。

正直な限界。 許可は一度レビューされると、上限に達するまで使用できます。そのため、承認したコマンドは追加のレビューなしで繰り返し実行できます。これは意図的に選んだトレードオフです。KNOWN-LIMITS 17 を参照してください。

まだ実装されていない機能

• 範囲を限定した管理対象インテグレーション。 記録の一部を秘匿化して、監査担当者、クライアント、または自社のIT部門に届けるための正規の方法です。npm run export は公開鍵とともにチェーン全体をパッケージ化するため、書き込んだマシン以外でも検証できますが、全体を出すか何も出さないかのどちらかしか選べません。選択的開示はまだ実装されていません。詳細についてはお問い合わせください。
• 外部アンカリング。 タイムスタンプ機関がなければ、チェーンが証明できるのは改ざんの有無であり、消去の有無ではありません。末尾を切り詰めても、検証に成功する短いチェーンが残ります。KNOWN-LIMITS 3 を参照してください。
• ハードウェアを利用したキー管理。 チェーンキーは平文でディスク上に保存されています。KNOWN-LIMITS 8 を参照してください。
• ハーネスごとのコスト計上。 レシートにはモデルごとの内訳（cost.byModel）が含まれます。コストはまだハーネスごとには分けられておらず、合計額は最後に確認されたモデルのものとして報告されるため、合計額ではなくbyModelを確認してください。KNOWN-LIMITS 13 を参照してください。

既知の制限事項

Lotor の問題点として私が把握しているものはすべて、KNOWN-LIMITS.md に記載しています。自分の利益に反する内容も含めています。自分の製品の弱点を列挙したリストは、このリポジトリで偽装するのが最も難しい主張だからです。

いくつかは未解決の懸賞課題です。告白ボードでは、ファイルと行番号への参照、範囲、そして私を介さず自分で成果を検証できるように書かれた受け入れ基準とともに、それらを公開しています。

ID	タイトル	難易度
A1	Armed. Lotor をインストールし、ゲートを有効にして、最初の署名付きレシートを獲得する	trivial
LOTOR-C1	データがゲートを通らず、記録もされないままGETクエリ文字列で送信される	medium
LOTOR-C2	ゲート対象のルールで捕捉されない危険なコマンド	hard
LOTOR-C3	チェックアウト済みの保護ブランチへの単独の git push が検出されない	medium

自分の作業に対する署名付きLotorレシートを提出することで課題を申告できます。つまり、懸賞課題への申告にはツールの実行が必要です。功績は認められ、コントリビューターとして扱われます。今回のラウンドでは賞金はありません。

そして KNOWN-LIMITS を読んで、まだ記載されていない項目を見つけて戻ってきたなら、懸賞課題を1つ解決するよりも大きな貢献をしたことになります。

開発

npm install
npm test

実行可能な手順については DEMO.md を、MCP の設定ブロックと公開されるツールについては MCP-SETUP.md をご覧ください。