コンテンツにスキップ
AIOS
AI agent securityCodexactivation stateconcurrencyevidenceprompt injectiondeveloper productivity

エージェントセキュリティは状態機械の問題:Codex セキュリティスレッドが見逃したもの

エージェントセキュリティは状態機械の問題:Codex セキュリティスレッドが見逃したもの

クイックアンサー: 今週最大の AI コーディングスレッド——Codex セキュリティ議論——は 500 以上のポイントと 200 以上のコメントを集め、アドバイスのほとんどはプロンプトインジェクションとサンドボックス化に集中していました。それらも重要ですが、日常のエージェントワークフローで実際に牙をむく障害モードは状態機械の問題です:アクティベーション状態を分裂させるクラッシュ、同じトークンを消費する 2 つの並行呼び出し、スキーマ検証を通ってしまうプレースホルダー証拠。AIOS v5.4.0 はまさにこの 3 つの修正を搭載しています——write-ahead アクティベーショントランザクション、ストアファイルロック、厳格な証拠参照検証付きの型付き成果物スキーマ。

みんなが話題にしているスレッド

Codex セキュリティスレッドは今週 Hacker News のトップに立ち、数百のコメントが寄せられました。プロンプトインジェクション、情報の外部送信、サンドボックス境界についての健全な議論でした。しかし不完全でもありました。日常のエージェント作業で人々が実際に遭遇する攻撃はめったにエキゾチックではありません。それらはセキュリティ上の結果を伴う普通の信頼性障害です:

  1. 状態書き込みの途中でのクラッシュ。 ワークフローは前進したと信じますが、ディスク上のファイルは別のことを示しています。再起動時、エージェントはステップを二重実行するか、静かに落とします。
  2. 同じトークンを消費する 2 つの並行呼び出し。 リトライとスケジュール実行が競合し、両方がステップを所有していると思い込み、ワークフローは 1 つの計画で 2 回前進します。
  3. 本物に見えるが本物ではない証拠。 証拠フィールドの TODO 文字列が型なしスキーマを通り、計画は検証されたことのない主張の上でクローズします。

どれもプロンプトインジェクションではありません。すべてがエージェントが走る 状態機械 を破壊します——そして状態の破壊こそが「検証済み」が「実際には一度も実行されなかった」に変わる仕組みです。

なぜ状態の整合性がセキュリティ境界なのか

エージェントワークフローを状態機械と考えてください:計画 → タスク → 証拠 → 検証 → 完了。すべての遷移は状態を書き込みます。その書き込みが原子的で検証されていなければ、機械は同時に 2 つの場所にいることができます:

  • クラッシュ後の分裂状態 —— ワークフローログはあることを言い、投影は別のことを言い、次の実行は間違ったコピーに基づいて決定します。
  • 並行性の下でのトークン二重消費 —— 2 つの呼び出しが両方「現在のトークン = 3」を読み、両方「今トークン 4」を書き込み、計画の 1 ステップが静かにスキップされる一方、もう 1 つは 2 回実行されます。
  • 本物として受け入れられるプレースホルダー証拠 —— 任意の文字列を受け入れるスキーマは、TODO: verify this をタスク完了の証明にしてしまいます。

プロンプトインジェクションはモデルを騙そうとします。状態の破壊は プロセス を騙します——そして完了を承認するのはプロセスです。

v5.4.0 が実際に行うこと

AIOS は Claude Code、Codex、Gemini CLI、OpenCode、Grok Build の上に載るローカルファーストのワークフローレイヤーです。v5.4.0 は状態機械を直接堅牢化しました:

write-ahead アクティベーショントランザクション

Workflow と Activation の投影は、write-ahead トランザクション(.aios/workflow-activations/transactions/)を通じて書き込まれるようになりました。書き込みは原子的で、未完了のトランザクションは再起動時に自動的にロールフォワードされます。読み取りは 2 つの投影間の整合性を検証し、どちらか新しい方のコピーを信頼するのではなくフェイルクローズ(stale-activation-projection)します。

トークン前進のためのストアファイルロック

ファイルロックが Command トークンの前進を直列化します。並行呼び出しは、同じトークンを静かに二重消費する代わりに AIOS_REX_STORE_BUSY を受け取ります——リトライとスケジュール実行は競合できますが、ステップを勝ち取るのは 1 つだけです。

型付き成果物スキーマと厳格な証拠参照

Wayfinder と Planning の成果物には型付きスキーマ(wayfinder-artifact.mjsplanning-artifact.mjs)が付きました。部分的な成果物やブロックされた成果物は Decision Ticket や Next Slice を主張できず、Parallel Groups はグループ間で一意でなければなりません。証拠参照はプロトコルプレフィックス(artifact:receipt: など)を持たなければならず、TODO/TBD/プレースホルダー値を拒否します——つまり機械は未検証の主張で計画をクローズすることを拒否します。

すでに存在していたレイヤー

状態の整合性は新しい堅牢化であり、周囲のゲートはすでにありました:

  • Privacy Guard はモデル消費前に機密の読み取りを編集します(aios privacy read --file ...、厳格モードは aios privacy status)。
  • 検証ゲート は「計画済み」と「検証済み」を分離します。verification-before-completion は計画がクローズする前に本物の証拠を要求します。
  • 適応型ワークフローポリシー は小さな変更を guarded(編集ゲート + 集中検証)に保ち、リスクの高い多段階の作業を永続的な所有権と証拠を持つ planned にエスカレーションします。

安全な開始手順

aios init --all
aios doctor --native --verbose

ルートマトリクスと検証ゲートについては Workflow Policy ドキュメント、システム内での状態の流れについては Architecture ガイド、機密ファイルの安全な読み取りについては Privacy Guard ケース をお読みください。

FAQ

プロンプトインジェクションは本当の脅威ではないのですか?

それは本当の脅威であり、サンドボックス化も重要です。しかしエージェントを採用するほとんどのチームが最初に直面するのは状態の整合性障害です。それは静かで再現可能だからです。セキュリティ議論は両方を含むべきです:モデルは騙され得るし、プロセスは破壊され得る。

コーディングクライアントが内部で処理してくれないのですか?

クライアントは自分のセッション状態を処理します。ワークフローレイヤー——計画、アクティベーション、証拠、検証——はクライアントの外に存在し、だからこそ独自のトランザクション状態が必要なのです。v5.4.0 がクラッシュセーフにしたのはその部分です。

「フェイルクローズ」は私にとって何を意味しますか?

2 つの投影が一致しないとき、システムは推測で進む代わりに停止して stale-activation-projection を報告します。あなたはトランザクションを明示的に回復します。後になってステップが 2 回実行された、あるいは一度も実行されなかったことに気づく代わりに。

実装の詳細はどこにありますか?

Changelog は v5.4.0 の堅牢化をリリースごとに列挙しており、リリース記事 Workflow Iteration v2.1 はクローズされる 3 種類の静かな障害を解説しています。

次のセキュリティ見出しもおそらくまだプロンプトについてでしょう。1 週間を失わせる障害は、あなたの状態機械を静かに 2 回前進させたものになるでしょう。