AI workflow builder に露出リスクが出た後、なぜ最初に認証情報をローテーションすべきではないのか

最初に問いを正す。探すべきものは製品名ではなく、プロセス内の鍵である

workflow builder の問題を見たとき、多くのチームはまずこう尋ねる。「うちは Langflow を使っているか。バージョンは修正済みか」

もちろん、この問いは必要だ。ただし、これは第一層を解くだけである。より重要なのは、その後に続く4つの問いだ。

• どの flow が外部、社内ネットワーク、テストアカウント、または想定外の利用者に開かれていたか。
• どの flow に認証情報、環境変数、接続文字列、差し替え可能な secret が含まれていたか。
• どの flow が顧客データ、内部文書、CRM、ticket、データベース、ファイルシステムを読めたか。
• どの flow が実行、再実行、export、複製されたか。または触るべきではない人に見られたか。

以前に CRM 連携 token の漏えいを扱ったことがあるなら、ここでの考え方は近い。「どの鍵が漏れたか」だけを問うのではなく、先にその鍵でどの扉を開けられるのかを描く。近い状況として、こちらも参考になる：CRM 連携 token の漏えい後は、まずデータ境界を描く。

AI builder には、さらに面倒な点がある。認証情報が1つの設定画面だけに置かれているとは限らない。ノード設定、環境変数、テスト input、prompt 例、connector 設定、export された JSON、古い版の flow、複製 flow、あるいは「一時的に admin token で試す」ためのテストノードに隠れていることがある。

だから最初の一歩は、どの token が最も危険かを当てることではない。外部から動かせる経路を塞ぎ、証拠を残したまま「プロセスが過去にどう動いたのか」を復元することだ。

40分の初回棚卸し：グループチャットの記憶に頼らない

チームが2、3人のエンジニア、1人のプロダクト責任者、1人のシステム連携に詳しい人だけなら、初回棚卸しを大規模な war room にする必要はない。40分で実用に足る版を作れる。

第1ステップ：出血を止め、証拠を変えてしまう操作を避ける

まず5つ行う。

1. 公開共有リンク、不審な webhook、外部 API route を一時停止する。
2. builder と admin 画面への到達を VPN、allowlist、社内ネットワークに絞る。
3. 高リスク flow の新規作成、変更、実行を一時停止する。ただし flow、実行履歴、設定、ログは削除しない。
4. 現在の flow 一覧、connector 一覧、環境変数名、権限画面を export またはスクリーンショットで保存する。
5. builder access log、flow execution log、API gateway log、outbound webhook log を保全する。

ここで注意したい。secret を見つけたからといって、すべての画面を共有ドキュメントに貼ってはいけない。共有ドキュメントに書くのは「token の種類、権限範囲、owner、最後に使われた時刻」までであり、token の原文は書かない。

API は「システムとシステムがデータを交換するための接続口」とまず理解すればよい。builder の背後に API gateway や reverse proxy があるなら、そちらの log も一緒に残す。builder の画面内にある記録だけでは不十分なことが多いからだ。

第2ステップ：使っている flow だけでなく、すべての flow を列挙する

flow を4つの群に分ける。

• production で稼働中：顧客、社内業務、正式データに影響する。
• staging / sandbox：理屈ではテストデータだけに触れるが、正式 token を持っていることがある。
• archived / disabled：停止済みだが設定は残っており、複製や export が可能な場合がある。
• personal / experiment：個人テスト、demo、臨時の PoC。名前のない token が最も隠れやすい。

多くの事故で見落とされるのは後ろの2群だ。監視図にも載らず、正式なアーキテクチャ文書にも書かれていない。それでも、当時のテストを急ぐために権限のある key を直接貼っていた可能性がある。

第3ステップ：各 flow に4つの欄を付ける

ここでは表は1つで十分だ。棚卸しを表だらけにしない。

この表には2つの使い方がある。第一に、エンジニアが記憶だけで「それはテスト flow だから」と言うのを防ぐ。第二に、非エンジニアの owner が、なぜある token を先に止め、ある flow を先に隔離し、ある credential を先に交換する必要があるのかを理解できる。

すでに agent の認可設計を進めているチームなら、ここを別の早期チェックリストにつなげてもよい：AI agent の認可を考える4つの問い：身元、権限、理由、結果。あちらは事前設計寄りで、この記事は事後棚卸し寄りだ。両方を合わせると、agent が「ログインしているように見える」だけで過大な権限を得る状況を減らせる。

第4ステップ：見られただけの flow より、実行可能だった flow を先に扱う

すべての露出が同じ重大度ではない。次の順で並べるとよい。

1. 不審期間中に実行され、production token を含む flow。
2. 不審期間中に読み取りまたは export され、設定内に secret 名、connector、内部 endpoint が見える flow。
3. 実行証拠はないが、公開共有されていた、権限が過大、または owner が不明な flow。
4. 停止済みだが、複製、export、admin アカウントによる再有効化が可能な flow。

queue は待機中のタスク一覧である。ここでの queue には「token を交換する」とだけ書かない。各項目を、どの flow、どの credential、どの owner、どのシステム、どの検証方法に分解する。

たとえば、こうは書かない。

• Salesforce token を交換する。

こう書く。

• Flow lead-summary-prod が使う Salesforce OAuth app（flow が許可された Salesforce の身元としてアクセスする接続設定）：refresh token を一時停止し、最小権限 app を再発行する。直近100回の flow execution に未知の実行者がいないことを確認する。owner：RevOps。検証：Salesforce Login History + builder execution log。

この書き方なら追跡しやすく、後から引き継ぎやすい。

production token の境界は作り直す。同じ大きさの鍵に交換するだけでは足りない

credential rotation でよくある失敗は、古い token を、同じだけ大きな権限を持つ新しい token に置き換えることだ。短期的には処理が終わったように見える。しかし長期リスクは下がっていない。

rotation のとき、次の4つも一緒に行う。

1. production token を個人アカウントから service account へ移す。
2. 読み取り権限と書き込み権限を分ける。要約 flow がデータ削除権限まで持つべきではない。
3. 有効期限と owner を設定する。owner のいない token は production に入れない。
4. builder が使える secret 名を用途ベースにする。たとえば crm_read_contacts_prod とし、admin_key や test_key とは呼ばない。

owner は最後の判断と収束を担当する人である。ここでの owner は「最初に flow を作った人」ではない。この credential を残すべきか、権限を縮めるべきか、rotation すべきか、停止すべきかを決められる人だ。

rotation だけを終えて境界を作り直さなければ、次に builder、agent、connector で問題が起きたとき、チームは同じ問いに戻る。結局、どの flow がどの大きすぎる鍵を持っていたのか。

最初の最小アクション

今すぐ1つだけやるなら、「AI flow credential inventory」を作る前に、高リスク flow の実行、公開共有リンク、不審な webhook、外部 API route を一時停止し、builder / admin 画面を VPN、allowlist、社内ネットワークに絞る。そのうえで production と直近30日以内に実行された flow を先に列挙する。

各 flow には5項目だけ記入する。

1. flow 名と ID。
2. owner。
3. 接続している外部または内部システム。
4. 使用している credential 名。secret の原文は書かない。
5. 最終実行時刻とログの場所。

この inventory は、事故が起きてから作るものではない。平時に月1回更新しておけば、問題が起きたときにそのまま incident response の出発点になる。

生活四コマ

1. チームは AI workflow の入口が開いていることに気づき、すべての鍵を急いで交換する前に立ち止まる。
2. 入口を管理された範囲に戻し、ログと設定を消さずに残す。
3. どの connector、データソース、token に flow が触れられたのかをたどる。
4. 影響を受けた鍵だけを交換または無効化し、入口が閉じ、古い認証情報が使えないことを確認する。