Logos Protocol

なぜ、いま「出口」で止めるのか

攻撃と防御の費用は、非対称になりうる。

侵入経路の監視、脆弱性修正、資産管理には継続的な費用と人手が必要です。

AIで攻撃側の試行費用が下がる一方、防御側にも自動化の余地があります。
既存の境界防御やパッチ適用を続けつつ、許可された操作の実行前にも確認点を置きます。

入口の防御に、実行前の確認を重ねる。

ファイアウォール、認証・認可、EDRなどの対策は今も重要です。
ただし、正規の権限を持つ処理が意図しない操作を実行する場面では、別の確認が必要になります。

• サイバー攻撃：侵入後に既存のAPIや許可済み経路が悪用される可能性がある。
• エージェントの暴走：誤った要求が外部作用へ直結する設計では、被害が生じうる。
• プロンプトインジェクション：外部文書や入力内の指示が、正規の実行要求に混入することがある。

入口を守る対策と、外部送信・設定変更・発注などの実行直前を検査する対策は、互いに補完します。

出口に、信号機を。

Logos Protocolは、既存の入口側の対策を置き換えず、実行前の検問を重ねる設計です。

AIが「外部へ送信する」「発注する」「本番に反映する」――。
その決定的な「実行（Action）」の直前に、決定論的なコントロール・レイヤーを配置します。

語句の巧妙さではなく、宣言された条件・経路・証拠参照を検査する。
固定された仕様・入力・設定で、PASS／HOLD／ESCALATE／FAILを区別します。

証拠名や承認参照の形式だけでは真正性を証明できません。信頼できる発行元・承認者への独立した照合が必要です。

HOLDは外部作用へ進まない保留状態です。必要な証拠や承認に不足があれば、正本の参照と承認者の確認を経たうえで再判定する運用を想定します。再開カード（HOLD Resolution Card）は、その状態遷移を記録するための模式仕様です。現行試作の自動復旧や無制限の再試行を認めるものではありません。

理由コードは攻撃者に不足条件を教える手掛かりにもなり得ます。利用者・監査者・実行AIで開示範囲を分離し、同一主体の再判定回数上限、連続HOLDへの対応、異常試行の抑制を、本番設計時に定義する必要があります。固定上限値や強制実装の成立はまだ主張しません。

{
  "ticket_id": "TKT-2026-0417-001",
  "initial_verdict": "HOLD",
  "reason_code": "EVIDENCE_INSUFFICIENT",
  "resolution": "PASS",
  "permit_token_issued": true,
  "evidence_added": "安全性試験報告書 v3.1",
  "its_rounds": 2,
  "resolved_at": "2026-04-17T11:23:00+09:00"
}

この表示は、HOLD後の再判定プロセスを説明する模式図です。自動解決、本番安全性、法令適合、監査合格、事故防止を保証するものではありません。