Actenon Kernel

Actenon Kernel

証明に基づく重大な実行のためのオープンな検証器です。有効な証明の定義を定めます。実行の境界で証明を検証し、許可を発行せず、ポリシー判断も行いません。

上記のすべての主張は機械検証済みです

claims: machine-verified バッジは、README に記載されているカーネルに関する事実上の主張が一つでも真でなくなった場合、すべての PR、main へのプッシュ、および毎日 CI を失敗させるゲート（verify-claims.yml）にリンクしています。

• 検証時のネットワーク呼び出しはゼロ — tests/test_neutrality.py は、バッジのリンク先にあるだけでなく、ゲート内で実行されます。
• Permit、Cloud、Scan なしで実行可能 — tests/test_independence.py に加え、カーネルが Cloud または Permit をインポートしないことを証明するソーススキャンと、scripts/assert_dep_direction.py（ランタイム依存関係は actenon-protocol のみ）によって検証されます。
• 適合性の数 — ここにある「N 個の適合性ベクトル」／「N 件のテストに合格」という記述は、すべて actenon-kernel conformance run が実際に実行する内容と照合されます。ベクトルファイル自体は scripts/verify_conformance_manifest.py によってハッシュで固定されています。
• インストールコマンド — この README 内のすべての pip install は実際のレジストリを使って解決されます。Python バッジは手作業で編集されるのではなく、自動生成されます。
• エコシステムの表 — プロトコルの ecosystem.yaml から生成され、手作業で編集されることはありません。

Invariants ワークフローではさらに、クリーンな追加機能なしのインストールで、Ed25519 を含む適合性の全範囲をテスト 33/33 件、スキップなしで検証できることを、すべての PR で証明します。

主張に食い違いが生じると、人が気づく前にバッジが赤くなります。

---

Actenon エコシステム

Kernel は、連携して 実行ギャップ、すなわち 上流での認可 と、重大な副作用を実際に実行する 実行エッジ との間のギャップを埋める、独立したリポジトリの 1 つです。

リポジトリ	役割	依存先	パッケージ
actenon-protocol	中立的なワイヤー契約 — ワイヤー上で各アーティファクトがどのように表現されるかを定義します	—	actenon-protocol (PyPI) · @actenon/protocol-types (npm)
actenon-kernel ← 現在表示中	オープンな検証器 — 有効な証明とは何かを定義します	actenon-protocol	actenon-kernel (PyPI)
actenon-permit	開発者向けの導入窓口と権限ブローカー	actenon-kernel、actenon-protocol	actenon-permit (PyPI) · @actenon/sdk (npm)
actenon-scan	独立した静的解析スキャナー	—	actenon-scan (PyPI)
sdk-go	Go 検証 SDK — Go で保護エンドポイントの証明を検証します	actenon-protocol	リポジトリ
sdk-rust	Rust 検証 SDK — Rust で保護エンドポイントの証明を検証します	actenon-protocol	リポジトリ

任意： actenon-cloud — マネージドコントロールプレーン（非公開リポジトリで、一般には利用できません）。上記のどのコンポーネントにも必要ありません。このエコシステムのすべての機能は、これなしで動作します。

各リポジトリは個別に導入できます。特に Kernel は、エージェントフレームワーク内（LangChain ツール、MCP ツール、Claude Managed Agents カスタムツールなど）、または リソース境界で独立して（FastAPI ルート、Express ルート、Go HTTP ハンドラー）組み込むことができます。どちらの配置も正式にサポートされています。

---

これは何か

Kernel は、Actenon エコシステムの 信頼の起点 です。次の特徴があります。

• 独立性 — Permit、Cloud、Scan なしで動作します。検証中にネットワーク呼び出しは一切ありません。
• 実行エッジにおける検証器 — PCCBVerifier は純粋かつステートレスです。ProtectedExecutor は副作用が発生する前に、エッジでリプレイ、エスクロー、冪等性、認証情報のブローカー処理を強制し、その後 Receipt または Refusal を出力します。
• 適合性を厳密に固定 — 53 個の適合性ベクトルによって、言語を問わず「有効な PCCB」の意味が厳密に定義されています。
• マルチ言語対応 — Python のリファレンス実装に加え、すべて同じベクトルに準拠する TypeScript、Go、Rust の検証 SDK があります。
• フレームワーク非依存 — 証明の検証は関数呼び出しであり、フレームワークではありません。同じ検証器を LangChain の _run、MCP ツールハンドラー、Express ルート、Go HTTP ハンドラー内で実行できます。

Kernel が行うのは 1 つだけ です。PCCB（Proof of Constrained Capability Bound）が、この呼び出し元、この対象、このオーディエンス、このスコープ、この時間枠、およびこの 1 回の実行試行に対して、厳密な Action Intent を認可していることを検証します。検証に失敗した場合、ProtectedExecutor は試行を拒否し（副作用は発生せず、構造化された Refusal を出力します）。Kernel はグラントを発行したり、ポリシーを決定したりは しません。それは Permit の役割です。

保証の前提条件： 保護されたエッジがリソースへの唯一の経路であり、バックエンドが検証後に発行されたブローカー経由の認証情報のみを受け入れ、エージェントが常時有効な認証情報や別の経路を持たない場合、エッジの保証が成立します。これらの条件が満たされない場合でも、Kernel は無効な証明を拒否しますが、Kernel を迂回する呼び出し元がリソースに到達するのを防ぐことはできません。対象範囲の詳細は docs/SCOPE_AND_GUARANTEES.md を参照してください。

なぜ存在するのか

現代のエージェントスタックでは、認証、ポリシーエンジン、承認ワークフロー、監査ログによって、上流の問いである「このリクエスターに、この種の操作を許可すべきか？」にはすでに答えられます。しかし、実行境界で答える必要がある問いは、まだ残されています。

これから実行される正確なアクションは、このエンドポイント、このテナント、このサブジェクト、このターゲット、そしてこの時間枠に対して認可されたものと、依然として完全に一致していますか？

この未解決の問いが実行ギャップです。承認から実行までの間のパラメーター改変、一見有効な証明のリプレイ、誤ったエンドポイントへの提示、テナント／サブジェクトの再バインド、古い証明の再利用が実際に発生するのは、このギャップの中です。Kernel はこれを解消します。

問題の正式な説明は、THE_EXECUTION_GAP.mdをお読みください。

組み込み可能な2つの箇所

これは Actenon を導入する際に最も重要なアーキテクチャ上の判断であり、Kernel はどちらの配置にも対応するよう明示的に設計されています。

配置 A — エージェントフレームワーク内（ブローカーモード）

Kernel の検証器は、エージェントのツール実装内で実行されます。エージェントがツールを呼び出し、ツールが証明を検証し、ツールが実行します。ブローカーが検証後に認証情報を解決するため、エージェントが本番環境の認証情報を保持することはありません。

agent → framework tool (LangChain / MCP / Claude / CrewAI / ...)
          ↓ verifies PCCB locally
          ↓ brokers credential
          ↓ executes side effect
       Receipt or Refusal

エージェントフレームワークを管理していて、すべてのツール呼び出しを証明に結び付けたい場合は、この方法を選びます。優先順位付けされた6つのフレームワーク向け手順については、INTEGRATIONS.mdをご覧ください。

配置 B — リソース境界に独立して配置（リソース所有モード）

Kernel の検証器は、リソース自体の内部で実行されます。たとえば、FastAPI のルート、Express のエンドポイント、Go の HTTP ハンドラー、内部サービスメソッドなどです。リソースが保護対象のエンドポイントになります。エージェント（または任意の呼び出し元）は、どのようにそこへ到達したかにかかわらず、副作用を発生させるには有効な PCCB を提示する必要があります。

any caller (agent / human / service / attacker)
          ↓ presents PCCB
   resource boundary (FastAPI / Express / Go / ...)
          ↓ verifies PCCB locally
          ↓ executes side effect
       Receipt or Refusal

エージェントフレームワークを完全には信頼できない場合、リソースを複数の呼び出し元で共有している場合、またはリソースチームとエージェントチームが別の組織である場合は、この方法を選びます。actenon-permitのBoundary Kitと、このリポジトリのBoundaryVerifier APIをご覧ください。BoundaryVerifierは、署名済み PCCB を正確な Action Intent と照合して検証します。トークン文字列を証明として扱うことはありません。

どちらの配置でも、同じ Kernel、同じ PCCB 形式、同じ適合性テストベクトル、同じ Receipt／Refusal 成果物を使用します。1つのデプロイメント内で両方を組み合わせることもできます。

15段階の検証パイプライン

フェーズ	手順	検証内容
A：認証前	1–5	構造、プロトコルバージョン、正規化、鍵の解決、署名
B：認証後	6–13	時間的有効性、オーディエンス、境界、ターゲット、アクション、パラメーターダイジェスト、権限、失効
C：状態管理	14–15	リプレイ（エグゼキューターに委譲）、実行適格性

認証前の失敗は、公開しても安全な単一のコード PROOF_INVALID にまとめられます。認証後の失敗では、信頼された呼び出し元に限り、具体的なコード（AUDIENCE_MISMATCH、ACTION_MISMATCH、REPLAY_DETECTEDなど）が開示されます。この2層の拒否モデルはプロトコルの一部です。詳しくはactenon-protocolをご覧ください。

カーネルが生成するもの

成果物	目的	仕様
Action Intent	重大なアクションに対する、公開された型付きの、帰属を明示するリクエスト	spec/action-intent/SPEC.md
PCCB	保護されたエンドポイントが副作用の発生前に検証する証明成果物	spec/pccb/SPEC.md
Receipt	正常終了を示す標準的な構造化結果	spec/receipt/SPEC.md
Refusal	実行がブロックされたことを示す標準的な構造化結果	spec/refusal/SPEC.md
Outcome Attestation	Receipt または Refusal を包む、任意の Ed25519 署名付きエンベロープ（v2alpha1）	spec/outcome-attestation/SPEC.md
Receipt Counter-Signature	Receipt に対する任意の第三者による副署	spec/countersignature/SPEC.md
Transparency Log Entry	任意のダイジェストベースの公開アンカー	spec/transparency-log/SPEC.md
Issuer Status	キーのライフサイクル記録（active / retired / suspended / revoked / hard_revoked）	spec/issuer-status/SPEC.md
Approval Artefact	PCCB の発行時に要求される場合がある、構造化された承認記録	spec/approval-artifact/SPEC.md
Protected Endpoint behaviour	実行エッジの契約	spec/protected-endpoint/SPEC.md
Replay behaviour	単回使用の証明に関する契約	spec/replay/SPEC.md

署名付きレシート — エージェントに許可されていたこと、実行または試行したこと、そしてその方法

すべての実行試行では、次のいずれかの標準的な機械可読成果物が生成されます。

• 副作用が実行された場合の Receipt（または、実行前に確実に拒否された場合の拒否済みレシートの経路）。
• 保護されたエンドポイントが副作用の発生前に試行を拒否した場合の Refusal。

どちらも構造化され、ハッシュチェーンで連結され、契約レベルで安定しています。あらゆる事後レビュー担当者（エンジニア、監査人、規制当局、保険会社）に対して、次の点を示します。

• エージェントに許可されていたこと — Grant の scopes.allow、scopes.deny、budget、rate、expires_at、および承認ルールです。レシートには、この試行を許可した正確な Grant と証明が記載されます。
• 実行または試行したこと — 正確な Action Intent（アクション名、ターゲット、テナント、主体、オーディエンス、パラメーター）、アクションハッシュ（RFC 8785 の正規化 JSON に対する SHA-256）、および実行状態（succeeded、failed、refused、outcome_unknown）です。
• 実行した方法 — ブローカー経由またはリソース所有の実行モード、認証情報の参照（シークレットそのものではありません）、副作用を実行したアダプター／エンドポイント、プロバイダーの応答または拒否コード、およびレシート自体の署名です。

ポータブルな暗号学的出所証明が必要なデプロイでは、カーネルは任意の v1 Receipt または Refusal を Outcome Attestation エンベロープ（v2alpha1、オプトイン）で包むことができます。アテステーションは Ed25519 キーで署名されます。キーのライフサイクル（active / retired / suspended / soft-revoked / hard-revoked）も、公開契約の一部です。hard-revoked キーの過去の成果物が引き続き検証可能なのは、独立して検証された外部アンカーによって、侵害前に成果物のダイジェストが存在していたことが証明される場合に限られます。詳しくは REVOCATION_AND_RECEIPT_DURABILITY.md を参照してください。

Outcome Attestation は v2alpha1 であり、1.0 互換性の保証の対象外です。 オプトインのアルファ機能であり、v2 に到達するまで、 どのリリースでも変更または削除される可能性があります。詳しくは VERSIONING.md §1.2 を参照してください。

インストール

Kernel 単体の場合は Python 3.10 以上が必要です。Permit を含むフルスタックの場合は 3.11 以上が必要です。

pip install actenon-kernel            # full verifier: HMAC and Ed25519

1.1.0 以降では、基本インストールですべてのエコシステム生成物（Ed25519 証明と Outcome Attestations を含む）が検証されます。後方互換性のため、[asymmetric] エクストラも引き続き解決されますが、追加でインストールされるものはありません。

エージェントに接続する（MCP、60 秒、インストール不要）

Kernel には実行可能な MCP サーバーが付属しているため、モデルはアクションの実行前に、そのアクションが許可されているかを確認し、拒否された理由をそのまま読み取ることができます。これを任意の MCP クライアント（Claude Desktop、ChatGPT、または MCP に対応するその他のもの）に貼り付けます。

{
  "mcpServers": {
    "actenon": {
      "command": "uvx",
      "args": ["--from", "actenon-kernel[mcp]", "actenon-mcp", "--demo"]
    }
  }
}

Claude Code を使用していますか？コマンド 1 つで同じサーバーを登録できます。

claude mcp add actenon -- uvx --from 'actenon-kernel[mcp]' actenon-mcp --demo

uvx が取得して実行するため、事前にインストールする必要はありません。--demo は一時的なキーとメモリ内の状態を使ってオフラインで実行されます。すべてのツールの説明に DEMO MODE と明記されており、本番環境では使用しないでください。

3 つのツールがあります。actenon_verify（この証明はこのアクションに対して有効ですか？）、actenon_gate（ALLOW または型付きの拒否）、actenon_receipt（以前の判断に対するハッシュチェーン付きレシート）です。すべての拒否には、機械可読なコードと人が読める理由の両方が含まれます。

実際のトランスクリプトを含む詳細なチュートリアルでは、エージェントが返金範囲の拡大を拒否された後、範囲内で処理を成功させる例を紹介しています。 docs/integrations/MCP_QUICKSTART.md。

検証器として使用する（リソース境界）

from actenon.proof import PCCBVerifier, build_local_proof_signer

# For production, use a file-based or KMS-backed signer (see
# docs/PRODUCTION_INTEGRATION.md §1). The local HMAC signer below is
# development-only — it uses a public test secret.
signer = build_local_proof_signer()    # development only
verifier = PCCBVerifier(signer=signer)

# Raises ProofVerificationError on any failure; returns silently on success.
verifier.verify(intent, pccb, context)

本番環境でのキー管理： 上記のローカル HMAC 署名器は開発専用です。本番環境では、ファイルベースの Ed25519 キーまたは KMS ベースの署名器を使用してください。3 つのキー管理層と ACTENON_ALLOW_PILOT_LOCAL_EDDSA_IN_PRODUCTION フラグのドキュメントについては、docs/PRODUCTION_INTEGRATION.md §1 を参照してください。

境界検証器として使用する（Boundary Kit、リソース所有モード）

信頼ルートを指定せずに BoundaryVerifier() を呼び出すと、長い文字列や v1. で始まる文字列も含め、すべてのトークンが拒否されます（ISSUER_UNTRUSTED）。発行者のキーで検証できる同じ PCCBVerifier と、リクエストで実行される正確な Action Intent を渡します。

from actenon.boundary import BoundaryVerifier, BoundaryVerificationRequest
from actenon.proof import PCCBVerifier

# The trust root is mandatory: without a PCCBVerifier every proof is
# refused (ISSUER_UNTRUSTED). Pass a durable replay_store= when more than
# one worker serves the same boundary.
verifier = BoundaryVerifier(pccb_verifier=PCCBVerifier(signer=issuer_verifier))
result = verifier.verify_boundary(BoundaryVerificationRequest(
    proof_token=proof_header,         # PCCB JSON, or "v1." + base64url(PCCB JSON)
    intent=action_intent,             # the exact Action Intent this request performs
    action_type="payment.refund",     # must equal the intent's action name
    action_hash="",                   # optional; when set, must equal the proof's action hash
    audience="service:payments",      # this boundary's identity (required)
))
# result.valid         → True only after signature + exact-action verification
# result.refusal_code  → "PROOF_INVALID" | "AUDIENCE_MISMATCH" | "REPLAY_DETECTED" | ...
# result.proof_id      → the PCCB's pccb_id (for receipt correlation)

Airlock から Kernel を呼び出す方法

Airlock は、エージェントの前段にある協調型の Python ブローカーです。Scan が権限を指定し、Permit がその権限に対する許可を署名し、Airlock が副作用の発生前に Kernel に証明の検証を依頼します。src/actenon_airlock/broker.py からの呼び出しは次のとおりです。

from actenon.gate import ActenonGate
from actenon.replay import ReplayProtector, SqliteReplayStore

self.edge = ActenonGate(
    verifier=Ed25519PublicKeyVerifier([key.public_key_jwk]),  # actenon-permit
    audience="service:actenon-permit-gateway",
    issuer="service:actenon-permit",
    capabilities=tuple(sorted(self.allowed)) or ("airlock.none",),
    replay_protector=ReplayProtector(SqliteReplayStore(state.local / "replay.sqlite3")),
    revocation_checker=StoreRevocationChecker(self.store),    # actenon-permit
)
outcome = self.edge.protect(intent, proof, dispatch.run)

capabilities は境界の許可リスト（許可に含まれる Scan の権限）です。他の capability に対する証明は、dispatch.run の実行前に SCOPE_CAPABILITY_MISMATCH で拒否されます。revocation_checker(pccb, context) は、権限が取り消されていない場合に true を返す必要があります。false が返された場合、または例外が発生した場合は、AUTHORITY_REVOKED となります。Ed25519PublicKeyVerifier と StoreRevocationChecker は、これらの Kernel インターフェースを満たす Permit の型です。Kernel は Permit も Scan もインポートしません。

パイプラインは、Scan の語彙、署名付き許可、この Kernel のチェック、署名付きレシートの順で構成されます。Airlock は outcome.to_dict() を囲む独自のハッシュチェーン付きレシートを書き込みます。このパイプラインにおける Kernel の役割は、保護された呼び出しに対するチェックと Receipt または Refusal です。

ミンター兼実行器として使用する（ブローカー経由モード、ローカルで完全な証明）

python3 -m pip install -e .
python3 -m actenon.cli up
python3 -m actenon.cli doctor
python3 -m actenon.cli simulate --incident replit

次に、実際のエンドポイントを保護します。

python3 -m examples.refund_guard_local.server --runtime-dir artifacts/local_runtime

多言語 SDK

SDK	用途	パス
Python（リファレンス）	ミンター、検証器、実行器、CLI、適合性検証、ローカル証明モードを含むフルカーネル	このリポジトリ
TypeScript	Node／Express／TS サービスにおける検証器エッジでの証明チェック	sdk/typescript/
Go	Go HTTP サービスにおける検証器エッジでの証明チェック	Actenon/sdk-go（スタンドアロン。カーネルの CI で固定コミットをテストします）
Rust	システムコンポーネントにおける検証器エッジでの証明チェック	Actenon/sdk-rust（スタンドアロン。カーネルの CI で固定コミットをテストします）

すべての SDK は、同一のハッシュロック済み検証器ベクトル（actenon/conformance/vectors/verifier_sdk_v1。conformance/vector-lock.json で固定。Go および Rust SDK にはバイト単位で同一のものが同梱されています）を実行します。SDK_SELECTION_GUIDE.md をご覧ください。

フレームワークとプラットフォームのアダプター

このリポジトリには、Kernel を主要なエージェント向けプラットフォームに組み込んだ、実行可能なサンプルが優先順位付きで用意されています。MCP が中心的な導入経路であり、その他は配布を支援するものです。

#	プラットフォーム	サンプル	証明の検証場所
1	MCP サーバーのツール（中心的な導入経路）	examples/mcp_server_protected_tool/	MCP ツールの実装内
2	LangChain ツール	examples/langchain_protected_tool/	ツールの _run 内
3	Claude Managed Agents のカスタムツール	examples/claude_managed_agents_protected_tool/	agent.custom_tool_use ハンドラー内
4	LlamaIndex FunctionTool	examples/llamaindex_protected_tool/	ラップされた関数内
5	CrewAI ツール	examples/crewai_protected_tool/	ツールの _run 内
6	Semantic Kernel プラグイン	examples/semantic_kernel_protected_tool/	@kernel_function メソッド内

追加のサンプル（優先順位付きの初回リリースには含まれませんが、本番環境で使える品質です）：

プラットフォーム	サンプル
OpenAI Agents SDK	examples/openai_agents_sdk_protected_tool/
FastAPI の保護されたルート	examples/fastapi_protected_route/
Express の保護されたルート（TypeScript SDK）	examples/express_protected_route/
FastMCP の金融取引	examples/fastmcp_financial_transfer/
返金ガード（ローカルでの許可判定 → 実際の証明）	examples/refund_guard_local/
請求書支払いガード	examples/invoice_payment_guard_local/
臨床 EHR エージェント	examples/protected_clinical_ehr_agent/
IAM コントロールプレーン	examples/protected_iam_control_plane/
マルチエージェントスウォーム	examples/protected_multi_agent_swarm/
ポリシー事前確認付き返金	examples/protected_policy_preflight_refund/
LangChain の金融エージェント	examples/protected_langchain_finance_agent/
保護された送金を行う金融エージェント	examples/financial_agent_protected_transfer/
敵対的 RSA ポリシーのストレステスト	examples/adversarial_rsa_policy_stress_test.py

すべてのサンプルで境界は共通です。保護されたエンドポイントは Action Intent、PCCB、ローカルコンテキストを受け取り、副作用が発生する前に証明を検証し、標準形式の Receipt または Refusal を返します。ホスト型のコントロールプレーンを必要とするサンプルはありません。

インシデントライブラリ — ギャップを確認し、それが解消される様子を見る

このリポジトリには、現実のインシデントパターンが展開する様子と、保護されたエンドポイントで同じパターンが拒否される様子を確認できるローカルシミュレーターが用意されています。どれも数秒で実行できます。

actenon-kernel simulate --incident replit           # Replit-style destructive DB drift
actenon-kernel simulate --incident prod-delete      # Generic production destructive action
actenon-kernel simulate --scenario mcp-tool-proof-laundering
actenon-kernel simulate --scenario iam-escalation
actenon-kernel simulate --scenario data-export

パターン	内容	出典に忠実な解説
Replit風のデータベース削除	実行境界が、実際の操作と対象を検証せず、広範なツール権限を信頼したために、範囲の限定された開発タスクが破壊的なデータベース変更へと拡大します。	docs/incidents/REPLIT_STYLE_DATABASE_DELETE.md
本番環境での破壊的な操作	主要なシナリオである「レシートがなければ、本番環境では削除しない」の流れです。	docs/incidents/PRODUCTION_DESTRUCTIVE_ACTION.md
MCP ツール間の証明のロンダリング	オーケストレーターが、あるツール用に発行された証明を別のツールに転送します。2つ目のツールはこれを拒否しなければなりません。	docs/incidents/MCP_TOOL_PROOF_LAUNDERING.md
IAM 権限昇格	エージェントが、特定の操作に対する証明なしで put_user_policy / attach_role_policy を実行しようとします。	docs/incidents/IAM_PRIVILEGE_ESCALATION_PATTERN.md
データエクスポートによる情報流出	対象者や範囲を限定した証明なしで、機密データのエクスポート操作を試みます。	docs/incidents/DATA_EXPORT_EXFILTRATION_PATTERN.md

これらのページは出典に忠実です。インシデント名はパターンを表す言葉として用いており、事実に基づくインシデント報告として扱うことはありません。また、出典のない事実を、名前が挙げられたインシデントについて断定することも明示的に避けています。実行上のギャップがどこに現れるか、また、保護された Actenon 境界が副作用の発生前にプリフライト、証明、認証情報の仲介、Receipt／Refusal 成果物をどのように要求するかを示します。独自の解説を書く際は、INCIDENT_ANALYSIS_TEMPLATE.md を使用してください。

次に、ローカルのトレースビューアを開き、シミュレーションごとの Intent Record、Action Intent、PCCB、Receipt、Refusal、リプレイエントリー、保護されたエンドポイントの状態を確認します。

actenon-kernel up
# → http://127.0.0.1:8421

このビューアは、リポジトリに既存の証明フローによって生成されたローカル成果物（Intent Record、Action Intent、PCCB、Receipt、Refusal、リプレイエントリー、保護されたエンドポイントの状態）と、それらの成果物から再構成した実行フローを表示します。ホスト型サービス、オペレーターのワークフロー状態、有料レイヤーのランタイムインフラストラクチャは不要です。詳しくは TRACE_VIEWER.md を参照してください。

マルチエージェント実行モデル

マルチエージェントシステムでは、意思決定から実行までの間にホップが1つ増えるごとに、証明のロンダリングが起きる余地が広がります。これは、上流で得た証明、承認状態、または「許可済み」のコンテキストを、別の下流の実行境界に対する十分な認可として扱うことです。オーケストレーターが「すでにチェックした」としても、カーネルのルールは変わりません。

保護された各実行境界は、副作用が発生する前に、それぞれの証明を検証します。

PCCB は、特定の対象者、テナント、主体、操作、対象、範囲、有効期限、ノンスに紐付けられています。エージェントの境界を越えて転送しても、別のツールに対して有効になるわけではありません。詳しい原則については MULTI_AGENT_EXECUTION_MODEL.md を参照してください。

鍵のライフサイクルとレシートの耐久性

発行者の署名鍵は、明示的な検証セマンティクスを持つ5つの状態を移行します。

状態	新しいアーティファクトに署名できるか	過去のアーティファクトは引き続き検証できるか	将来のアーティファクトは検証できるか
active	はい	はい	はい
retired	いいえ	はい	いいえ
suspended	いいえ	はい（遡及的なポリシーが適用される場合を除く）	いいえ（一時停止中）
revoked（ソフト）	いいえ	revoked_at より前に発行されていれば、はい	いいえ
hard_revoked	いいえ	独立した外部アンカーがある場合に限り可	いいえ

ハード失効は、鍵の侵害により、発行者自身のタイムスタンプでは正当な過去のアーティファクトと遡及的に日付を偽装したアーティファクトを区別できなくなった場合にのみ使用します。Kernel の外部アンカー MVP により、デプロイ環境は発行者が署名したバイト列を変更することなく、ハード失効後も過去のアーティファクトの検証可能性を維持できます。ライフサイクルの全容については、REVOCATION_AND_RECEIPT_DURABILITY.md をご覧ください。

コンプライアンス対応表（部分的かつ誠実な範囲）

Kernel は、一般的なフレームワークの実行エッジに関する部分に適切に対応します。ただし、認証ではなく、網羅的な対応表でも、完全なカバレッジを主張するものでもありません。

フレームワーク	Kernel が役立つ領域	主張しないこと
OWASP Top 10 for LLM Applications	LLM01 プロンプトインジェクション（後続の被害を軽減）、LLM05 不適切な出力処理、LLM06 過剰なエージェンシー、LLM09 誤情報、LLM10 無制限の消費	モデル／プランナー／オーケストレーター自体へのプロンプトインジェクションは防止しません
OWASP Top 10 for Agentic Applications	ASI01 目標の乗っ取り、ASI02 ツールの誤用、ASI03 ID と権限の悪用、ASI07 安全でないエージェント間通信、ASI08 連鎖的な障害、ASI10 不正なエージェント	保護された実行経路の外にあるフレームワークのランタイムは保護しません
NIST AI RMF 1.0	GOVERN 1、MAP 1、MEASURE 1／2.4／2.7／2.8／2.9、MANAGE 1	完全な測定プログラムではなく、エンタープライズのリスク台帳でもありません

詳細な対応表については、COMPLIANCE_MAPPING.md をご覧ください。

適合性

actenon-kernel conformance run --require-complete
# → 53 tests pass. Mark: Actenon Verified (Conformance 1.1.0)

有効な v1 の互換性範囲は、Action Intent、PCCB、Receipt、Refusal、Protected Endpoint、Replay です。予約済みの範囲（Reconciliation、Policy Bundle）は、有効な v1 適合性の対象ではありません。サードパーティーの検証ツールを実装する場合は、これらの範囲を対象にし、同じテストスイートを実行してください。CONFORMANCE.md をご覧ください。

監査への回答

このリポジトリには、監査担当者が読みやすい THREAT_MODEL.md と、一般的なデューデリジェンスの質問を具体的なソースファイルに結び付ける AUDIT_RESPONSES.md が含まれています。

• ペイロードの改ざん — RFC 8785 JCS による厳密な正規化。浮動小数点数は拒否され、正規化の前に重複したオブジェクトキーは拒否されます。
• クロックのずれ — not_before と expires_at に対して、設定可能で検証済みの clock_skew_tolerance を適用します。デフォルトでは厳密にゼロです。
• 同時リプレイ（二重使用） — 永続ストア内の一意な replay_key に対する、アトミックなトランザクション方式の請求に加え、ミューテーションロックと単調性のアサーションを使用します。32 ワーカーによる同時実行競合テストで検証済みです。実行に成功するのは必ず1件だけで、残りは REPLAY_DETECTED により拒否されます。

外部による暗号技術レビューは実施されていません。 上記の セルフレビューは適切な実践ですが、独立した第三者による 確認の代わりにはなりません。外部レビューが必要な正確な 対象範囲、それぞれに対応するファイルの参照先、レビュー担当者が 回答すべき具体的な質問については、 docs/CRYPTO_REVIEW.md をご覧ください。

カーネルが行わないこと

Actenon は明示的な実行エッジのアクションをゲートしますが、プロンプト、モデルの出力、インバンドのレスポンス内容は検査もフィルタリングもしません。明示的なエクスポートまたは送信アクションに証明を要求できますが、その開示自体が保護対象のアクションとしてモデル化され、ルーティングされていない限り、通常の出力内で開示されるデータを止めることはできません。

• オペレーティングシステムのジェイルとして機能すること。システムコールをインターセプトしたり、プロセスを隔離したり、ネイティブコードをサンドボックス化したり、protect() または BoundaryVerifier を一度も呼び出さないプログラムを停止したりすることはありません。悪意のあるネイティブコードや同じユーザーのプログラムには OS による隔離が必要です。Airlock のドキュメントでも、このカーネルを囲むブローカーについて同じことが述べられています。
• 許可または証明を発行すること — それは Permit の役割です。
• プログラムが使用する権限を指定すること — それは Scan の役割です。カーネルは、呼び出し元が宣言する許可リスト（capabilities=）に照らして証明を検証します。
• 認証情報を解決すること — それはブローカーの役割です。
• プロバイダー呼び出しを実行すること — それはアダプターの役割です。
• テナントを管理すること — それは Cloud の役割です。
• プロンプト、モデルの出力、インバンドのレスポンス内容を検査すること。プロンプトフィルターでも、汎用的な DLP でもありません。
• 上流のポリシーや承認が正しかったことを証明すること。
• プロバイダーがその側で正しく実行したことを証明すること（プロバイダーのレスポンスは確認しますが、プロバイダーの内部状態は検証しません）。
• 制御が渡った後に虚偽を述べる、悪意のあるアダプターや不具合のあるアダプターを停止すること。
• 本番環境での鍵の保管や HSM ベースの署名に取って代わること（インターフェースは用意されています。プロバイダーはデプロイ時に接続します）。

エッジの保証が適用されるのは、保護対象のエッジがリソースへの唯一の経路であり、バックエンドが検証後に発行されたブローカー経由の認証情報のみを受け入れ、エージェントに常時有効な認証情報や別の経路がない場合に限られます。全範囲については、docs/SCOPE_AND_GUARANTEES.md を参照してください。

署名バックエンド

バックエンド	ステータス	ユースケース
development_local_hmac	開発専用	ローカルテスト — 本番環境では使用しないでください
pilot_local_eddsa	パイロット対応	実際の Ed25519、鍵はディスク上に保存されます。ACTENON_ALLOW_PILOT_LOCAL_EDDSA_IN_PRODUCTION=1 が必要です
external_managed	インターフェース準備完了	AWS KMS / GCP KMS / Azure Key Vault / HSM（PKCS#11）。プロバイダーはデプロイ時に接続します。

正確な接続方法については、上記の署名バックエンドの表を参照してください。本番環境への統合ガイドの全文は、このリポジトリの docs/PRODUCTION_INTEGRATION.md にあります（Apache-2.0、自己完結型、actenon-cloud は不要です）。

このリポジトリの内容

パス	用途
actenon/proof/	PCCB の発行、検証、正規化、署名
actenon/boundary/	BoundaryVerifier（リソース所有モード）
actenon/receipts/	Receipt + Refusal + Outcome Attestation
actenon/replay/	永続ストア（SQLite、Postgres）に対するアトミックな claim/consume/release
actenon/escrow/	エスクロー対応の実行チェック
actenon/evidence/	ローカルのエビデンス照会サポート
actenon/anchors/	外部アンカーの検証
actenon/policy/	ポリシーの事前チェック
actenon/preflight/	アクションの事前チェック
actenon/conformance/	53 件の適合性ベクター + スイート
actenon/cli.py	統合 CLI（actenon-kernel verify-proof、actenon-kernel up、actenon-kernel simulate、actenon-kernel conformance run）
actenon/local_runtime.py	ローカルの信頼ランタイム（外部アカウント不要）
sdk/typescript/	TypeScript の検証専用 SDK（Go および Rust の SDK は、sdk/standalone-sdk-pins.json で固定された独立リポジトリです）
examples/	20 件以上のフレームワークおよびプラットフォーム向けアダプター（上記を参照）
spec/	現行の v1 仕様（11 のサーフェス）
docs/incidents/	パターンベースのインシデントライブラリ
conformance/	ハッシュ固定された適合性ベクター

独立性

Kernel は actenon-protocol のみに依存します。Permit、Cloud、Scan には依存しません。Kernel の適合性ベクトルに準拠するサードパーティー製の証明は、発行者を問わず Kernel の検証器に受け入れられます。検証器は検証中にネットワーク呼び出しを一切行いません。

ライセンス

Apache-2.0 — LICENSE を参照してください。

保護されたエッジでのエフェクトの所有権

重大な結果を伴う再試行の安全性を確保するには、リソース所有者の名前空間と、権限エンジンのアトミックな台帳クレームフックを指定して、actenon.execution.effects の EffectProtector を構成してください。Kernel はエフェクトの識別情報を再計算し、資格情報を取得する前に、署名済みの extensions.effect 参照が実行試行と正確に一致することを要求します。このフックを備えていないエッジは、エフェクトを含む証明を拒否します。信頼された境界は、COMMITTED、NOT_EXECUTED、または AMBIGUOUS の確実性を示す、一致する effect_evidence を返さなければなりません。トランスポートの成功だけでは、結果がコミットされたことの証明にはなりません。不確実な場合、信頼された照合が行われるまで予約は保持されます。統合要件と攻撃の証拠を参照してください。

Python のリソース境界と VerifierSDK も、署名済みの必須エフェクト制約を適用します。レガシーのエスクローミドルウェアは、エフェクトを含む証明を拒否します。検証によって結果のコミットが確立されることはありません。レシートの構築には、一致する信頼されたエフェクト証拠が必要です。エントリーポイントのカバレッジと阻止された攻撃を参照してください。