hachiflow.com
セキュリティ

追跡できるエージェント決済

エージェントがお金を使えるようになると、セキュリティ責任者の最初の質問は単純です。誰のエージェントが何をして、誰が承認したのか。イベントトレース全体がそれにどう答えるか、今あるもの、まだ作っているもの、そしてモデルにトレースを読み上げさせる方法を説明します。

問われるのはエージェントではなく人

エージェントに支払い手段を持たせると、レビューの場の話題が変わります。エージェントがどれだけ賢いかを聞く人はいません。誰のものか、何をしたか、何ができたはずか、誰が許可したかを聞きます。

これらは説明責任の問いであり、答えは記憶をたどって組み立てるものではなく、あとから調べられるものでなければなりません。そのためにあるのがトレースです。

依頼から結果まで、1 本のトレース

Waggle では、すべての操作がイベントバス上のイベントです。イベントには、ID、時刻、ソース、種別、ワークスペース、プリンシパル、トレース ID があります。プリンシパルは、どの人間またはどのエージェントが行ったかを ID で示します。イベントはトレース ID でつながり、連鎖になります。

トレースには、エージェントの 1 ターンごとに、ワークスペース、エージェント、そのエージェントが属するアカウント、きっかけ、結果、使ったツールと認証情報、承認とその決定者が表示されます。連鎖を 1 本たどれば、ひとつの仕事を、人の依頼から、エージェントのターン、貸し出された認証情報、承認、結果まで順に読めます。

これはエージェントの作業全般について、現在すでにあります。購入そのものを独立した種類のイベントとして扱う決済専用の部分は、これから作るものです。

依頼 人が頼む エージェントのターン どのエージェント、どのアカウント リース 値は渡さない 承認 誰が決めたか 結果 何が起きたか trace_id 1 つのトレース ID バス上のイベント。それぞれにプリンシパルがある
ひとつの仕事をイベントの連鎖として表した図です。現在のエージェント作業は、この形で追跡されます。金額と利用上限を持つ、購入そのものを表すイベントは計画中です。

決済セキュリティの審査担当が聞くこと

PCI DSS のような決済カードの基準に沿って審査する担当者は、大まかに言って似たことを求めます。個人ごとに責任が明確であること。認証情報が、それを使う側に見えないこと。使える金額に上限があること。そしてログが、個々の操作を 1 人の人間に結び付けること。

私たちは、いかなる基準への準拠も主張しません。言えるのは、設計がそれらの問いとどう対応しているかを率直に示すことです。説明責任:すべてのイベントがプリンシパルを ID で示します。認証情報:エスクローに置かれ、エージェントが持つのはリースであって値ではありません。ログ:イベントはトレース ID を共有するので、操作をたどると依頼または承認した人に行き着きます。

まだ存在しないのは、利用上限です。この話題が出るたびに、私たちはそう言います。

現在使えるものと、作っているもの

現在使えるもの:プリンシパルとトレース ID を持つイベント、エージェントのターンごとのトレース、決定者を記録する承認、エスクローに置かれた認証情報とエージェント向けのリース。決済に関するものは、まだ何も動いていません。現時点で、エージェントが Waggle を通じてお金を使うことはできません。

作っているのは、同じバス上の決済イベントです。誰が購入を承認したか、どのエージェントが支出したか、エージェントごとの利用上限、しきい値を超えたときの追加承認。さらに、改ざん検知できる決済ログと、受信時のカード番号のマスキングも作っています。メッセージに貼り付けられたカード番号がログに残らないようにするためです。

ログの現状ははっきり書いておきます。イベントログには署名もハッシュチェーンもなく、保持期間は既定で 90 日、アーカイブを設定すればそれより長くなります。誰にも気づかれずに書き換えることができず、1 年以上保管されるログが必要な審査担当には、今あるものでは足りません。決済ログへの署名またはハッシュチェーンと、より長い保持期間が、これから加えるべきものです。

モデルにトレースを読ませる

トレースは MCP エンドポイント上のツールなので、アシスタントに直接見せられます。お使いのクライアントに https://api.hachiflow.com/mcp を追加してサインインし、エージェントが何をしたかを普通の言葉で尋ねてください。

アシスタントは hachi_traces_ls でエージェントのターンを一覧し、1 件を選んで hachi_trace_get を呼びます。すると、その仕事に関するイベントのつながり全体が返り、モデルはそれを短い説明に直して伝えます。誰が頼み、どのエージェントが動き、どの認証情報を使い、誰が承認し、何が起きたか、です。

現在は、エージェントの行動を誰が承認したかに答えられます。決済イベントはまだありません。できたときには、同じ質問で支出も分かるように作っています。金額と、適用された上限も含めてです。

assistant
# 普通の言葉で尋ねます > what did my agents do yesterday and who approved the spend? # エージェントのターンを一覧し、1 件を開きます $ hachi_traces_ls $ hachi_trace_get # そして連鎖を読み上げます

質問と、使う 2 つのツールです。答えはモデルの記憶ではなく、トレースから得られます。

トレースは、モデルに任せなくてよい仕事も教えてくれる

トレースを読むことには、もう 1 つの使い道があります。同じ仕事が何ターンも、同じツールを同じ順に使い、同じ結果になるなら、それはもう判断ではありません。決まった手順です。

そういう仕事こそ、決定的なコードに置き換える価値があります。モデルには毎回違う仕事を任せ、変わらない仕事は単純なスクリプトに任せます。トレースは誰かの記憶ではなく実際に起きたことを記録しているので、どちらなのかを教えてくれます。

ここまでのまとめ

エージェントの作業に対する説明責任は、現在使えます。プリンシパル、トレースの連鎖、承認、認証情報のリースです。エージェントの支出に対する説明責任は、計画中です。決済イベント、利用上限、追加承認、改ざん検知できるログです。片方がもう片方を満たしているように見せるより、どちらがどちらかをお伝えします。

← フィールドノート一覧