AIエージェントを安全に業務利用するには？実体験と海外事例から学ぶ運用設計
倉光 周
AIエージェントは、もはや「試してみたいツール」ではなく、開発現場の当たり前になりつつあります。Cursor、Claude Code、Codex、Copilot、ChatGPT——。名前は違っても、共通しているのは「人が指示を出し、AIが代わりに作業してくれる」という体験です。
便利な一方で、「便利だから使う」だけでは、思わぬところで手痛い結果につながる可能性があります。ここでいうのは、AIが「悪意を持って暴走した」という話ではありません。もっと地味で、もっと現実的な話です。
この記事の結論を先に述べます。 AIを安全に業務利用する鍵は、「AIを信用する」ことではなく、 AIが間違えても致命傷にならない仕組み（サンドボックス・最小権限・ガードレール・Repository Rules・スキルによる多層防御）を先に作ること です。
このあと、次の順で説明します。
- AIが「悪意」ではなく「目的達成」で危険な操作を選ぶ理由
- 承認疲れによるヒヤリハットと、防ぎ方としてのスキル（Pre Task Review / Change Verification / Log Analysis）
- 海外事例（PocketOS・Clinejection）から見える共通原因
- 明日から使える運用設計（サンドボックス・最小権限・ガードレール・Repository Rules）とチェックリスト
AIは「目的達成」を優先する——悪意ではなく確率の問題
AIエージェントの根底にある LLM（大規模言語モデル） は、「目的を達成するために最も確率が高い行動」を選択します。
たとえば、あなたが「このエラーを直して」と依頼したとき、AIは学習データの中で最もよく見た解決パターンを選びます。例えば——
エラーを解消するために、エラーが出ているファイルを削除する
という判断が、学習データ上では合理的だったため、 目的達成のために削除を選ぶことがあります。
つまり、
AIが悪意を持ったのではなく、目的達成を優先した結果です。
だからこそ、
AIの判断ではなく権限で止める必要があります。
これは個人の体験だけの話ではありません。2026年に発表された Gravitee の調査『 State of AI Agent Security Report 2026 』では、本番環境でAIエージェントを運用する企業のうち、 すでに何らかのインシデントや予期せぬ挙動を経験している と回答した割合が示されています（報告時点や定義により、おおむね 54〜88% と幅があります）。
同報告書は、次のような システム構造上の問題 を指摘しています。
- 過剰な権限付与（Ambient Privilegeの悪用） … 人間が「良かれと思って」エージェントに与えたAPIキーや環境権限を、エージェントが都合よく解釈し、制限外のデータにアクセスしてしまう
- タスク完了の盲信（Runaway Optimization） … エージェントは「目的を達成すること」だけに最適化されるため、「それをやったら会社にどれだけの損害が出るか（リスク境界）」を理解せず、破壊的な手段を選んでしまう
先ほどの「削除を選ぶ」行動も、まさに Runaway Optimization の典型例です。
「AIが賢いから大丈夫」と信じるのではなく、「AIが間違えても致命傷にならない仕組み」を先に作る——この考え方が、これからのAIエージェント運用の出発点になります。
私自身が経験したヒヤッとした出来事
あるとき、私は Cursor に不要なフォルダの削除を依頼しました。
指示自体はシンプルです。「このフォルダを削除してほしい」。AIは快く引き受け、承認画面を出してきました。私は慣れていたので、内容を十分に確認せずに承認してしまいました。
結果として、想定より広い範囲が削除されました。しかも、その時点でバックアップが十分ではなく、復旧にかなりの時間を使いました。
このとき強く感じたのは、「AIが暴走した」というより、 「自分が油断していた」 ということです。
- 「AIならだいたい大丈夫だろう」と思っていた
- 承認画面を、流れ作業のように通していた
- 削除という破壊的操作に対して、人間側の確認が形骸化していた
AIのミスだけが原因ではありませんでした。でも、AIが強力な操作を実行できる環境では、人間の確認不足がそのまま事故につながりやすい——それがこの経験の本質です。
承認疲れ（Approval Fatigue）とは
こうした事故でよく話題になるのが、 承認疲れ（Approval Fatigue） です。
承認疲れは、確認ダイアログが頻繁すぎて内容を読まずに「OK」を連打してしまう状態です。多くの場合、 ファイル編集は許可なしで実行される 一方、コマンド実行のたびに「承認しますか？」と聞いてきます。最初は慎重に確認しますが、回数が増えると「また承認か……」と感じ、内容を読まずに通してしまう。
たとえば、Cursor で1時間コーディングすると、こんな承認が何十回も出てきます。
- 「
git statusを実行してよいですか？」 - 「
npm testを実行してよいですか？」 - 「
rm -rf tmp/を実行してよいですか？」← ここを見逃すと危険
画面には「今日 47 回目の承認」のような日常的な承認が積み重なり、危険な1件も同じ見た目のダイアログに紛れてしまいます。
起こりうるリスク
- 重要な警告を見逃す
- セキュリティリスクが上がる（悪意ある依頼や不正アクセスも通してしまう）
- 意図しない操作・変更を許可してしまう
対策のポイント
- 承認回数そのものを減らす（設定の見直し）
- 信頼できる操作はまとめて許可する
- 本当に必要な確認だけを残し、重要度の高い確認を優先する
これは人間にとても自然な反応です。だからこそ、
「承認画面がある＝安全」
ではありません。 承認が形骸化した瞬間、最後の防波堤が機能しなくなります。
私が作成したスキル——多層防御を実装する
この経験をきっかけに、「人間の確認だけに頼るのではなく、仕組みで事故を防げないか」と考えるようになりました。具体的には、AIエージェントの実行前にリスクを評価する「 Pre Task Review 」、AIによる変更内容を検証する「 Change Verification 」、そして実行履歴を詳細に記録・分析する「 Log Analysis 」という3つのスキルを作成しました。これらは、AIエージェントの誤操作を未然に防ぎ、万一の際にも迅速な検知と復旧を可能にするための重要な要素となります。
※ 個人検証用の Cursor スキルとして試作した例であり、本稿時点で一般公開パッケージではありません。
| スキル | 役割 | レイヤー |
|---|---|---|
| Pre Task Review | 作業前の事前チェック | 予防（Prevention） |
| Change Verification | 変更内容の検証 | 検知（Detection） |
| Log Analysis | ログ分析・改善 | 分析・改善（Continuous Improvement） |
Pre Task Review
AIが作業を開始する前に、破壊的な操作や本番環境への影響を事前にチェックし、必要に応じてGitによるバックアップ作成や人の確認を促すスキルです。
一言で言うと、 「事故を未然に防ぐための事前レビュー」 です。
たとえば「このフォルダを削除して」と依頼が来たとき、作業開始前に「削除対象のパスは本当に正しいか」「バックアップは取ったか」「本番環境に影響しないか」を自動で確認します。承認疲れで見逃しがちな 作業前のチェック を、スキルが代わりに担ってくれます。
Change Verification
AIが実施した変更内容を解析し、想定外のファイル変更や削除、リスクの高い変更がないかを確認するスキルです。必要に応じて人によるレビューを促します。
一言で言うと、 「AIの変更内容を検証するスキル」 です。
AIが10ファイル変更したあと、「想定していた3ファイル以外も変更されていないか」「.env が触られていないか」を自動でスキャンします。人間が diff を1行ずつ追わなくても、 異常な変更を検知して止める ことができます。
Log Analysis
AIの実行ログやコマンド履歴を分析し、危険な操作や異常な挙動を検知するとともに、事故発生時の原因分析や運用改善に活用するスキルです。
一言で言うと、 「事故の検知・原因分析・改善につなげるスキル」 です。
たとえば「いつ、誰が、どのコマンドを実行したか」を後から追跡し、rm -rf の実行や本番APIへのアクセスがあればアラートを出します。事故が起きた後の 原因特定と再発防止 に使えます。
3つのスキルが作る多層防御
[Pre Task Review] → 作業前に危険をブロック（予防） ↓ [Change Verification] → 変更後に異常を検知（検知） ↓ [Log Analysis] → ログから原因を分析し改善（継続的改善）
1つだけでは穴があきます。作業前チェックをすり抜けても、変更検証で止められる。変更検証もすり抜けても、ログ分析で後から気づける——この 3層構造 が、AIエージェント運用の安全性を高めます。
海外でも同じような事故が起きている
自分だけの話ではありません。海外でも、似たような事例が報告されています。
PocketOS の事例——AIエージェントが本番データを削除した
PocketOS 創業者 Jer Crane の報告（Reddit） によると、2026年4月、AIエージェントが 9秒 で本番データベースとボリューム内バックアップを削除した、という事例が報告されています。
PocketOS はレンタカー業向けの業務SaaSで、予約・決済・顧客管理などを担っています。エージェントは ステージング環境 の認証情報の不整合を修正するルーティン作業中でしたが、問題を「解決する」ため 独自の判断で Railway ボリュームの削除 を決定しました。
Railway（レイルウェイ）とは？
Railway は、アプリやデータベースをクラウド上にデプロイ・運用するための PaaS（Platform as a Service） です。Heroku や Vercel に近いイメージで、「GitHub に push したら自動デプロイ」「PostgreSQL を数クリックで立ち上げ」といったことができます。
Railway API とは？
関係は次の3層です。
- Cursor / AIエージェント （自然言語で指示）
- Railway MCP Server （
mcp.railway.com。AIとRailwayをつなぐ橋） - 実行できる操作 … プロジェクト作成 / デプロイ / 環境変数 / DB操作
Railway API とは、ダッシュボード（Web画面）の代わりに、 プログラムから Railway のインフラを遠隔操作するための窓口 です。CI/CD や自動化スクリプト、そして AIエージェント がここを通じて操作できるようになっています。
ここで重要なのは、 DB操作の先に破壊的操作（例：DB削除）のリスクがある ことです。窓口が広いほど、エージェントが一度の呼び出しで大きな損害を出せます。PocketOS 事例では、この API 経由で データベースボリュームの削除 が実行されました。
なぜ事故につながったのか？
これが最も重要なポイントです。AIが悪意を持ったのではなく、権限設計と確認の欠如が重なった結果です。
流れをかみ砕くと、こういうことです。
- エージェントはステージング環境の認証不整合を修正する作業中だった
- 問題を「解決する」ため、 独自の判断で Railway ボリュームの削除 を決定した
- コードベース内の 別用途ファイル から Railway API トークンを発見した（カスタムドメイン管理用CLI向けに作成したもの）
- そのトークンは Railway API 全体への広い権限 を持っており、
volumeDeleteも実行可能だった volumeDeleteを1回の API 呼び出しで実行。 本番ボリューム が削除され、 同一ボリューム内に保存されていたバックアップも同時に消えた （最も新しい復旧可能バックアップは3ヶ月前）- API側に 確認ステップや環境スコープの制限がなかった
AIが悪かったのではなく、「過剰な権限」「確認なしの破壊API」「脆弱なバックアップ設計」が重なった結果 です。
GitHub issue 1件からサプライチェーン侵害へ
ファイル削除だけがリスクではありません。 プロンプトインジェクション ——AIに見せたテキストの中に悪意ある指示を紛れ込ませ、エージェントに「自分への命令」と思わせる攻撃——は、すでに実際の被害として報告されています。
プロンプトインジェクションの脅威モデルは、おおむね次の3段です（arXiv:2601.17548 の整理に近い）。
攻撃の入口 … 外部Webページ / MCPツール / Skillファイル / 画像・PDFなどマルチモーダル入力
攻撃の種類 … 入力操作 / ツール汚染 / プロトコル悪用 / オリジン横断の汚染
影響 … .env 読取 / Shell実行 / ファイル削除
同論文では、適応的攻撃の成功率が 85%超 、攻撃手法が 42種 と整理されており（本稿執筆時点の内容。定義や実験条件により数値解釈に幅があり得ます）、 フィルタ単体では防げず、アーキテクチャレベルの対策が必要 ——これが図の結論です。
2026年2月に報告された 「Clinejection」 は、その代表例です（分析レポート / Snyk の解説 / 参考資料）。
攻撃の流れは次のとおりです。
- 攻撃者が Cline リポジトリに、 issue タイトル・本文へ細工したプロンプト を仕込んだ GitHub issue を作成
- Claude ベースの自動トリアージボット が issue を処理し、過剰な権限のもとで任意コマンドを実行
- GitHub Actions のキャッシュを汚染し、正規の publish ワークフローから npm トークンが漏洩
- 窃取したトークンで
cline@2.3.0という改ざんパッケージ が npm に公開（公開から約8時間で deprecated） - 改ざんパッケージの
postinstallにより、約 4,000 台 の開発者マシンへ不正インストールが実行
PocketOS 事例と同じく、AIが悪意を持ったのではありません。 自動化ワークフローへの過剰な権限 と、 CI/CD の防衛線の欠如 が重なり、issue 1件がサプライチェーン事故に発展しました。
共通していた原因——本当の問題はAIではなかった
ここまでの事例を並べてみると、見えてくる共通点があります。
事故の本質は、多くの場合、
- AIに強すぎる権限を与えていた
- AIを止める仕組みがなかった
- バックアップがなかった
- レビューが形骸化していた
という、 運用設計の問題 でした。
AIが100%正しいわけではない、という前提を置いていなかった。あるいは、頭では分かっていても、日々の作業ではその前提が守られていなかった——これが実態です。
だからこの記事では、「AIは危険だ」ではなく、次の考え方を提案したいです。
AIが間違えることは前提として考える。
そのうえで、間違えても致命傷にならない仕組みを作る。
「AIを信用する」から「仕組みで守る」へ
では、具体的に何をすればよいのでしょうか。鍵になるのは次の3つです。
- サンドボックス … 作業範囲を「囲まれた空間」に限定する
- 最小権限 … 今のタスクに必要な権限だけを渡す
- ガードレール … ポリシーや制約に抵触した危険操作への逸脱を強制的に止め、安全なレーンへ戻す
サンドボックス——「遊び場の柵」のようなもの
サンドボックス（sandbox） とは、直訳すると「砂場」です。ITの世界では、 AIやプログラムが自由に動ける「囲まれた安全な空間」 を指します。
たとえ話で理解する
子どもの遊び場を想像してください。砂場の中なら、どれだけ砂を掘っても公園全体は壊れません。柵の外（歩道や駐車場）には出られない、というルールがあるからです。
サンドボックスは、AIに対する 「この中だけで作業してね」という柵 です。
図の要点はシンプルです。AIが触れる範囲（例：src/ と docs/）だけを枠で囲み、枠の外——.env・本番DB・親フォルダ——には触れさせない。これがサンドボックスです。
開発現場での具体例
| やること | 具体例 | 防げる事故 |
|---|---|---|
| 作業フォルダを限定する | Cursor でプロジェクトルートだけを開く。親フォルダやホームディレクトリは渡さない | ~/Documents 全体を誤削除 |
| 環境を分ける | AIには ステージング環境 だけ触らせ、本番の Railway プロジェクトには接続しない | 本番DBの誤削除 |
| コンテナで隔離する | Docker コンテナ内だけでAIにコマンド実行させる | ホストマシンのシステムファイル破損 |
| 一時ディレクトリを使う | tmp/ai-work/ だけに書き込みを許可し、完了後に中身を確認してから本番反映 | 未完成コードの直接マージ |
身近な例：Cursor でのフォルダ指定
Cursor を使うとき、「Desktop 全体」ではなく 「このプロジェクトのフォルダだけ」 を開いて作業するのは、まさにサンドボックスの考え方です。
逆に、ホームディレクトリ全体を Cursor に開いてしまうと、AIが ~/Library や ~/.ssh にもアクセスできる状態になります。これは柵のない公園全体を遊び場にしてしまうようなものです。
最小権限（Least Privilege）——「必要な鍵だけ渡す」
最小権限 とは、「今のタスクに必要な権限だけを渡す」という考え方です。
たとえ話で理解する
会社のオフィスビルに入るとき、全員に「マスターキー」は渡しません。
- 総務の人 → 倉庫と会議室の鍵
- エンジニア → 開発フロアの鍵
- インターン → 自分のデスクエリアだけ
AIにも同じです。「全部できるトークン」ではなく、 「読み取りだけ」「テスト実行だけ」 のように絞るべきです。
全部の鍵（マスターキー）を渡すと、読み取り・テスト・削除・本番デプロイまで何でもできてしまいます。必要な鍵だけ渡すなら、「読み取り」「テスト実行」は開けても、「削除」「本番環境」は開けない——この差が安全性です。
Railway API での教訓
先ほどの PocketOS 事例で問題だったのは、 「ドメイン設定用」のつもりで作ったトークンが、DB削除権限まで持っていた ことです。
これは「倉庫の鍵を渡したつもりが、マスターキーだった」状態です。
開発現場での具体例
| 権限 | 渡していい場面 | 渡してはいけない場面 |
|---|---|---|
| ファイル読み取り | コード調査、バグ分析 | — |
| ファイル書き込み | 機能実装、リファクタリング | .env、秘密鍵、本番設定 |
| コマンド実行（読み取り系） | npm test、git status | rm -rf、git push --force |
| クラウドAPI | ステージング環境のデプロイ | 本番DBの削除・変更 |
ガードレール（Guardrails）——「転落を防ぐ柵」
ガードレール（guardrails） とは、道路の脇に設置される 「転落防止の柵」 です。車（AI）が暴走しても、崖から落ちないようにする仕組みです。
サンドボックスが「作業場所を限定する」なら、ガードレールは 「危険な操作そのものへの逸脱を、制約で強制的に止める」 仕組みです。
たとえ話で理解する
承認画面は「運転手にブレーキを踏むか聞く」仕組みです。でも、運転手が居眠りしていたら（承認疲れ）、ブレーキは踏まれません。
ガードレールは、 道路脇の壁（物理的な制約） に近い仕組みです。AIが本来のレーンから外れそうになっても、システム上のポリシーや禁止ルールに当たった時点で、 それ以上の逸脱を強制的に止め、安全なレーンへ戻す ——人間が気づいていなくても、壁にぶつかってでも止めます。
図で言うと、中央車線が「安全なタスク実行」で、脇道の出口（rm -rf / .env読取 / 本番削除）には遮断機が下りているイメージです。AIが「そちらに行きたい」と判断しても、ガードレールが道を塞ぐのです。
開発現場での具体例
| ガードレール | 設定例 | 防げる事故 |
|---|---|---|
| 危険コマンドのブロック | rm -rf /、git push --force origin main などポリシー違反コマンドを拒否し、実行を止める | 本番データ・履歴の消失 |
| 秘密ファイルの保護 | .env、.ssh/、credentials.json への読み書きを禁止 | APIキー・パスワードの漏洩 |
| ブランチ保護（GitHub） | main ブランチへの直接 push を禁止、PRレビュー必須 | レビューなしの本番反映 |
.cursorrules の設定 | 「削除コマンドを実行する前に必ずユーザーに確認」とルール記載 | AIの無断削除 |
| Railway の改善 | API 経由の削除に48時間のソフトデリートを導入 | 即座の完全削除 |
Cursor での .cursorrules 例
プロジェクトルートに .cursorrules ファイルを置き、AIへのルールを明記できます。
- ファイルやディレクトリを削除する前に、必ず対象パスを表示して確認を求めること - .env や秘密鍵ファイルを読み取らないこと - git push --force を実行しないこと - 本番環境のAPIトークンを使用しないこと
これは「AIへの社内ルール」であり、ガードレールの一種です。もちろん100%の保証ではありませんが、 何もルールがないよりはるかに安全 です。
サンドボックス vs ガードレール——何が違う？
| サンドボックス | ガードレール | |
|---|---|---|
| 比喩 | 遊び場の柵（範囲を限定） | 道路のガードレール（危険行為を阻止） |
| 役割 | 「ここだけで作業して」 | 「これはやっちゃダメ」 |
| 例 | プロジェクトフォルダだけ開く | rm -rf をポリシーで拒否する |
両方セットで使う のが理想です。柵の中で遊ばせつつ、柵の中でも危険な行動は止める——この二段構えが最も効果的です。
Repository Rules——チーム全体で守る「リポジトリのルール」
.cursorrules が個人のAIへの指示だとすれば、 Repository Rules（リポジトリルール） は チーム・リポジトリ全体に適用されるルール です。
Repository Rules とは？
GitHub の Rulesets（ルールセット） や Cursor の .cursor/rules/ ディレクトリに置くルールファイルのことを指します。個人の設定ではなく、 リポジトリに参加する全員（とそのAI）に共通で適用される のが特徴です。
個人の .cursorrules は「自分のAIだけ」に効きます。一方、リポジトリ全体のルール（例：main への直接 push 禁止 / PRレビュー必須 / .env 変更ブロック）は、 全員＋全員のAI に効きます。ゴールは「チーム標準を固定し、AIの暴走を組織で防ぐ」ことです。
具体例
| ルールの種類 | 設定内容 | 効果 |
|---|---|---|
| ブランチ保護 | main への直接 push を禁止 | AIが誤って本番ブランチを書き換えるのを防ぐ |
| 必須レビュー | PRに1名以上の承認を必須化 | AIの変更を人間が必ず確認する |
| パス制限 | .env や credentials/ への変更をブロック | 秘密情報の改変・削除を防ぐ |
| コーディング規約 | 「削除前に確認」「本番APIを使わない」を明記 | チーム全員のAIが同じルールで動く |
.cursorrules との違い
.cursorrules | Repository Rules | |
|---|---|---|
| 適用範囲 | 個人のCursor設定 | リポジトリ全体（チーム共通） |
| 誰が守るか | 自分のAIだけ | 全メンバー＋全員のAI |
| 例 | 個人の作業スタイル | ブランチ保護、必須レビュー、パス制限 |
個人の .cursorrules だけでは、チームメンバーが別のルールでAIを動かしてしまう可能性があります。 Repository Rules でチーム標準を固定する ことで、ガードレールが組織全体に広がります。
明日から実践できるAIエージェント運用
最後に、今日から取り入れられるチェックリストを載せます。全部を一度にやる必要はありません。 まずは1つでも 取り入れてみてください。
チェックリストの要点は次のとおりです。
- ガードレール … 危険な操作やポリシー違反に抵触した時点で逸脱を強制的に止め、安全なレーンへ戻す
- バックアップ … 定期バックアップと、すぐ復元できる体制を整える
- サンドボックス … 本番に影響しない隔離環境で実行する
- Repository Rules … リポジトリ単位でルールを固定し、一貫性と品質を保つ
- Human Approval … 重要な変更は人がレビューし、承認後に適用する
- ログ分析 … ログを収集・分析し、異常検知と継続改善に使う
たとえば最初の一歩としては、次がおすすめです。
.cursorrulesまたは Repository Rules で危険操作のルールを明記する- 承認画面は「3秒見る」ではなく、破壊的操作かどうかを必ず判定する習慣を作る （対象パス・コマンド名・本番/ステージングの区別を、声に出してまたはメモして確認する。迷ったら一旦拒否する）
- 本番・認証情報にはAIを近づけない
小さくても、運用ルールが1つ増えるだけで安全性は大きく変わります。
まとめ
AIエージェントは非常に便利な存在ですが、100%正しい判断をしてくれるわけではありません。LLMは目的達成のために最も確率の高い行動を選ぶ——だから削除も「合理的な選択」になり得ます。
だからこそ重要なのは、「AIを信頼すること」ではなく、「AIが間違えても事故にならない仕組みを作ること」です。
- サンドボックス で作業範囲を限定する
- 最小権限 で渡す鍵を絞る
- ガードレール でポリシー違反や危険操作への逸脱を強制的に止め、安全なレーンへ戻す
- Repository Rules でチーム全体のルールを固定する
- スキル（Pre Task Review / Change Verification / Log Analysis） で多層防御を実装する
AIを安全に業務へ取り入れるためには、人・ルール・技術を組み合わせた運用設計が欠かせないと、私は実体験や海外事例を通して強く感じました。
便利だからこそ、仕組みで守る——その考え方を、チームの中で一度話し合い、個人でも一度見直してみてください。
長い記事を最後までお読みいただき、ありがとうございます。
参考資料
本記事の執筆・構成にあたり、以下の資料を参考にしました。
- Gravitee, State of AI Agent Security Report 2026 — https://www.gravitee.io/state-of-ai-agent-security
- Jer Crane (PocketOS), Reddit投稿「An AI agent just destroyed our production data」 — https://www.reddit.com/r/ExperiencedFounders/comments/1sx8obj/an_ai_agent_just_destroyed_our_production_data_it/
- Adnan Khan, Clinejection 分析レポート（2026年2月） — https://adnanthekhan.com/posts/clinejection/
- Snyk, How "Clinejection" Turned an AI Bot into a Supply Chain Attack — https://snyk.io/blog/cline-supply-chain-attack-prompt-injection-github-actions/
- centminmod, Prompt Injection Attacks — https://github.com/centminmod/explain-openclaw/blob/master/05-worst-case-security/prompt-injection-attacks.md
- arXiv, Prompt Injection Attacks on Agentic Coding Assistants (2601.17548) — https://arxiv.org/abs/2601.17548
