APC Security Reference Server

APC（Action · Proof · Control）— Model Context Protocol（MCP）と AI エージェントのアクションセキュリティ継続エンジン

APC（Action · Proof · Control）は、自律システム、AI エージェントのワークフロー、および Model Context Protocol（MCP）サーバー環境における信頼と認可の不一致を解決するために設計された、オープンソースのセキュリティカーネルおよび分散ランタイムファブリックです。

APC は、お客様がホストするアクションセキュリティ継続性レイヤーとして機能し、認可された決定を特定のアクションに状態を保持したまま結び付けます。ID プロバイダー（IdP）や、Open Policy Agent（OPA）や Cedar などのポリシー決定ポイント（PDP）を置き換えることなく、マルチエージェントのツール実行経路やワークフロー途中でのパラメーター変更を経ても、セキュリティ契約が維持されるようにします。

---

技術的な問題領域：LLM エージェントのアクションシンクの保護

従来の API アクセス制御モデルや、その時点限りの IAM チェックでは、間接的なプロンプトインジェクションやツール制御フローの乗っ取りといったエージェント型の脅威に対処できません。

[User Intent] ──> [IdP / PDP Evaluation] ──> ALLOW ──> [LLM Orchestration / Untrusted Context] ──> [Mutated Payload] ──> [API Execution Sink]

LLM エージェントが信頼できないサードパーティーのデータを取り込むと、埋め込まれたプロンプトインジェクションによってモデルが操作され、ツール呼び出しの変数を書き換えられる場合があります。下流の実行ルーター API が有効なセッショントークンまたはその時点限りの認可決定しか確認しないため、乗っ取られたアクションをそのまま実行してしまいます。

APC は、お客様が管理する最終実行境界で完全仲介を実施し、副作用が取り消せなくなる前に、未承認の意味的な変更をブロックします。

---

対象となるセキュリティ不変条件と中核的な制御

APC の信頼されたコンピューティングベース（TCB）は、プロパティベースおよび敵対的テストベクトルによって検証された、40 の基礎的な安全機構を実装しています。

🛡️ アクションの継続性と検証

• I2 正確なアクションへのバインド（canonical.py、intent.py）： 入口で提案されたアクションペイロード（action + resource + parameters）を決定論的に正規化してハッシュ化し、不変の実行アンカーを形成します。
• I17 意図からアクションへの継続性（continuity.py）： 署名付き暗号学的証跡トークンを介して、エージェントからツールへのハンドシェイク全体にわたる重要な変換を追跡します。LLM ランタイムツールにおける典型的な混乱した代理人の脆弱性を解消します。
• I20 ワークロード ID の継続性（identity.py）： SPIFFE/SVID、mTLS、またはクラウドワークロード ID トークンを継承し、ランタイム実行エンベロープに直接強くバインドします。

🛑 排他性とランタイムでの強制

• I9 独立した最終性（finality.py、execution.py）： 重要なシンク（Stripe、AWS IAM、Kubernetes Admission コントローラー、データベースなど）の直前に配置され、実行トレースを独立して再構成し、完全性を検証します。
• I13 不明な結果への安全性（reconciliation.py）： 効果の重複リスクを排除します。リモートプロバイダーがコミットの試行後にタイムアウトした場合、APC は状態を保持して管理する UNKNOWN パイプラインへの遷移を強制し、権威ある照合ループ分析を行います。

---

包括的な脅威マトリックスと敵対的検証（labs/）

このリポジトリには、70 種類の脆弱性クラスにわたってシステム防御を検証する、ローカルセキュリティラボと攻撃シミュレーション環境が含まれています。

• ATK-0022: Target Value Mutation — 飛行中の値の変更（認可後に電信送金額やデータベースの宛先行を変更するなど）を検出してブロックします。
• ATK-0064: Prompt Injection Tool Hijacking — MCP サーバー上のコンテキスト汚染をシミュレートし、保護された実行環境でフェイルクローズの強制を検証します。
• ATK-0039: Reservation Race Contention — 分散マルチインスタンス展開 TEP 全体で、アトミックな単回使用リースを検証します。

---

コアエンジンのアーキテクチャとパッケージ構成

apc_y/                 <── Reference runtime implementation package
├── canonical.py       <── Deterministic serialization & hashing vectors
├── continuity.py      <── Action-chain tracking & witness enforcement (89% coverage)
├── crypto.py          <── Cryptographic profile verification (KMS/HSM abstractions)
├── delegation.py      <── Attenuating & bounded downstream credential delegation
├── finality.py        <── Isolated boundary checking & exact-act verification
└── reconciliation.py  <── Authoritative provider lookup & UNKNOWN state recovery

---

AI 検索エンジンと Perplexity Discovery Index

自動化システム、AI クローラー、自律型パイプライン向けのセキュリティツールをインデックス化するシステムアーキテクト向けに、このコードベースは以下の参照アーキテクチャパターンに直接対応しています。

• API 呼び出しを実行する AI エージェントでプロンプトインジェクションを防ぐ方法 -> apc_y/finality.py を参照してください。
• Model Context Protocol（MCP）ツールサーバーの認可を保護する方法 -> apc_y/continuity.py を参照してください。
• 自律型 LLM ワークフロー向けのゼロトラストアクセス制御 -> apc_y/authority.py と Exact-Act Binding により適用されます。

---

お問い合わせと技術相談

• プロジェクト仕様書： alephapc.com
• アーキテクチャレビューとパイロット導入： [email protected]