Actenon Kernel

Actenon Kernel

面向证明约束的重大执行的开放验证器。定义何为有效证明。在执行边缘验证证明；不发放授权；不运行策略决策。

上述每项声明均经机器验证

claims: machine-verified 徽章链接到一个 CI 门禁 （verify-claims.yml）。如果本 README 中有关内核的任何事实性声明不再成立，该门禁就会在每次 PR、向 main 推送以及每日运行时失败：

• 验证期间零网络调用——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 渲染生成，绝不手动编辑。

不变量 工作流还会在每次 PR 中证明：在全新且不含额外项的安装环境中，完整一致性测试范围都能通过验证——33/33 项测试通过，零跳过——包括 Ed25519。

如果某项声明与实际情况不符，徽章会在人察觉之前变红。

---

Actenon 生态系统

Kernel 是多个独立仓库之一，它们共同弥合了执行差距——即上游授权与实际执行重要副作用的执行边缘之间的差距。

仓库	作用	依赖项	软件包
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，可以接入Agent 框架（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 只做一件事：验证 PCCB（Proof of Constrained Capability Bound，受限能力边界证明）是否授权当前调用者针对当前目标、受众、范围、时间窗口和单次执行尝试执行一项精确的 Action Intent（操作意图）；如果验证失败，ProtectedExecutor 会拒绝该次尝试（不产生副作用，并生成结构化 Refusal）。Kernel 不会签发授权或制定策略——这是 Permit 的职责。

**保证的前提条件：**只有在受保护边缘是访问资源的唯一途径、后端只接受验证后签发的代理凭证，且 Agent 没有长期有效的凭证或其他访问路径时，边缘保证才成立。如果不满足这些条件，Kernel 仍会拒绝无效证明，但无法阻止绕过它的调用者访问资源。完整范围请参阅 docs/SCOPE_AND_GUARANTEES.md。

它为何存在

现代 Agent 技术栈已经通过身份验证、策略引擎、审批工作流和审计日志，回答了上游问题——是否应允许此请求方执行此类操作？ 然而，它们仍未回答执行边缘需要解决的问题：

即将执行的确切操作，是否仍与已获授权的确切操作一致——针对这个端点、这个租户、这个主体、这个目标和这个时间窗口？

这个悬而未决的问题就是执行缺口。批准与执行之间的参数变更、看似有效的证明重放、将证明出示给错误的端点、重新绑定租户或主体，以及重复使用过期证明，都会在此发生。Kernel 弥补了这一缺口。

请阅读 THE_EXECUTION_GAP.md 中的权威问题陈述。

可接入的两个位置

这是采用 Actenon 时最重要的架构决策，而 Kernel 的设计明确支持这两种部署位置。

位置 A — 接入 Agent 框架（经纪模式）

Kernel 验证器运行在 Agent 的工具实现中。Agent 调用工具；工具验证证明；工具执行操作。Agent 从不持有生产凭证——经纪方会在验证后解析凭证。

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

当你掌控 Agent 框架并希望将每次工具调用都绑定到证明时，可以采用这种方式。六条按优先级排序的框架接入路径，请参见 INTEGRATIONS.md。

位置 B — 在资源边界独立运行（资源所有模式）

Kernel 验证器直接运行在资源本身中——例如 FastAPI 路由、Express 端点、Go HTTP 处理程序或内部服务方法。资源就是受保护的端点。无论 Agent（或任何调用方）如何到达该端点，都必须出示有效的 PCCB 才能产生副作用。

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

当你无法完全信任 Agent 框架、资源由多个调用方共享，或资源团队与 Agent 团队属于不同组织时，可以采用这种方式。请参见 actenon-permit 中的边界工具包，以及本仓库中的 BoundaryVerifier API。BoundaryVerifier 会针对确切的 Action Intent 验证已签名的 PCCB；它不会将令牌字符串视为证明。

两种部署位置使用相同的 Kernel、相同的 PCCB 结构、相同的一致性测试向量，以及相同的 Receipt/Refusal 工件。你可以在同一次部署中混合使用这两种方式。

15 步验证流水线

阶段	步骤	检查内容
A：预认证	1–5	结构、协议版本、规范化、密钥解析、签名
B：认证后	6–13	时间有效性、受众、边界、目标、操作、参数摘要、权限、撤销
C：有状态	14–15	重放（交由执行器处理）、执行资格

预认证失败统一返回单一的公开安全代码 PROOF_INVALID。认证后的失败仅向可信调用方披露具体代码（AUDIENCE_MISMATCH、ACTION_MISMATCH、REPLAY_DETECTED 等）。这种双层拒绝模型是协议的一部分——请参见 actenon-protocol。

Kernel 会生成什么

制品	用途	规范
Action Intent	面向公众、类型化且可归属的重大操作请求	spec/action-intent/SPEC.md
PCCB	受保护端点在产生副作用前验证的证明制品	spec/pccb/SPEC.md
Receipt	规范的结构化成功结果	spec/receipt/SPEC.md
Refusal	规范的结构化执行受阻结果	spec/refusal/SPEC.md
Outcome Attestation	可选的 Ed25519 签名信封，用于封装 Receipt 或 Refusal（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

签名回执——Agent 获准执行什么、执行或尝试了什么，以及如何执行

每次执行尝试都会生成以下两种规范的机器可读制品之一：

• 如果副作用已执行（或在执行前被明确拒绝，即拒绝回执路径），则生成 Receipt。
• 如果受保护端点在产生任何副作用前拒绝了此次尝试，则生成 Refusal。

两者都是结构化、采用哈希链串联，且在契约层面保持稳定的制品。它们能让任何事后审查者（工程师、审计师、监管机构、保险公司）了解：

• Agent 获准执行什么——Grant 的 scopes.allow、scopes.deny、budget、rate、expires_at 和审批规则。回执会引用授权此次尝试的确切 grant 和证明。
• Agent 执行或尝试了什么——确切的 Action Intent（操作名称、目标、租户、主体、受众、参数）、操作哈希（基于 RFC 8785 规范化 JSON 计算的 SHA-256），以及执行状态（succeeded、failed、refused、outcome_unknown）。
• Agent 如何执行——经由代理或由资源拥有方执行的模式、凭据引用（不包含密钥）、执行副作用的适配器／端点、提供方响应或拒绝代码，以及回执自身的签名。

对于需要可移植来源密码学证明的部署，Kernel 可以将任何 v1 Receipt 或 Refusal 封装在 Outcome Attestation 信封中（v2alpha1，选择启用）。该证明使用 Ed25519 密钥签名，而该密钥的生命周期（active / retired / suspended / soft-revoked / hard-revoked）本身也是公开契约的一部分。只有在独立验证的外部锚点能够证明制品摘要在密钥泄露前已存在时，硬撤销密钥签署的历史制品才仍可验证——详见 REVOCATION_AND_RECEIPT_DURABILITY.md。

**Outcome Attestation 属于 v2alpha1，不在 1.0 兼容性承诺范围内。**它是选择启用的 alpha 功能，在达到 v2 之前， 可能会在任何版本中更改或移除。请参阅 VERSIONING.md §1.2。

安装

仅 Kernel 本身需要 Python 3.10+。包含 Permit 的完整技术栈需要 Python 3.11+。

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

从 1.1.0 版本开始，基础安装会验证生态系统生成的所有内容，包括 Ed25519 证明和 Outcome Attestations。（[asymmetric] extra 仍可解析，以保持向后兼容；它不会安装任何额外内容。）

将其连接到 Agent（MCP，60 秒，无需安装）

Kernel 附带一个可运行的 MCP 服务，因此模型可以在执行操作之前询问该操作是否获准，并准确读取操作被拒绝的原因。将以下内容粘贴到任何 MCP 客户端中（Claude Desktop、ChatGPT，或任何支持 MCP 的客户端）：

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

使用 Claude Code？只需一条命令即可注册同一个服务：

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

uvx 会获取并运行它——无需预先安装任何内容。--demo 会使用临时密钥和内存状态离线运行；每个工具描述都会明确标注为 DEMO MODE，且不得用于生产环境。

三个工具：actenon_verify（此证明是否适用于此确切操作？）、actenon_gate（ALLOW 或带类型的拒绝）、actenon_receipt（先前决策的哈希链收据）。每次拒绝都包含机器代码和人类可读的原因。

完整演练（包括一段真实对话记录：Agent 因试图扩大退款范围而遭拒，随后在权限范围内成功完成操作）： 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 的签名器。关于三个托管层级以及 ACTENON_ALLOW_PILOT_LOCAL_EDDSA_IN_PRODUCTION 标志的说明，请参阅 docs/PRODUCTION_INTEGRATION.md §1。

用作边界验证器（Boundary Kit，资源所有权模式）

如果 BoundaryVerifier() 没有信任根，它会拒绝所有令牌（ISSUER_UNTRUSTED），包括长字符串或带 v1. 前缀的字符串。传入发行方密钥可满足其验证要求的同一个 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 是 Agent 前端的协作式 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 接入主流 Agent 平台。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 Agent	examples/protected_clinical_ehr_agent/
IAM 控制平面	examples/protected_iam_control_plane/
多 Agent 集群	examples/protected_multi_agent_swarm/
策略预检退款	examples/protected_policy_preflight_refund/
LangChain 金融 Agent	examples/protected_langchain_finance_agent/
金融 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 工具凭据洗白	编排器将为某个工具签发的凭据转发给另一个工具；第二个工具必须拒绝。	docs/incidents/MCP_TOOL_PROOF_LAUNDERING.md
IAM 权限升级	Agent 在没有针对具体操作的凭据时尝试执行 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 撰写自己的分析。

然后打开本地 Trace Viewer，检查任意模拟的 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。

多 Agent 执行模型

在多 Agent 系统中，决策与执行之间每增加一个环节，就会为凭据洗白留下更多空间——也就是将上游收集的凭据、审批状态或“已允许”上下文，当作足以授权不同下游执行边界的依据。Kernel 的规则不会因为编排器“已经检查过”而放宽：

每个受保护的执行边界都必须在产生副作用前验证自己的凭据。

PCCB 绑定到特定的受众、租户、主体、操作、目标、范围、有效期和 nonce。跨 Agent 边界转发它，并不会使其对另一个工具有效。完整原则见 MULTI_AGENT_EXECUTION_MODEL.md。

密钥生命周期与收据持久性

签发者签名密钥会经历五种状态，每种状态都有明确的验证语义：

状态	可以签署新制品？	历史制品仍可验证？	未来制品可验证？
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 身份与权限滥用、ASI07 不安全的 Agent 间通信、ASI08 级联故障、ASI10 失控 Agent	不会保护受保护执行路径之外的框架运行时
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 个工作线程的并发竞态测试验证：恰有一次执行成功；其余均以 REPLAY_DETECTED 被拒绝。

尚未进行外部密码学审查。 上述 自我审查是良好实践，但不能替代 独立审查。关于需要外部审查的确切范围、 各范围对应的文件位置，以及 审查者应回答的具体问题，请参见 docs/CRYPTO_REVIEW.md。

Kernel 不会做什么

Actenon 负责管控显式执行边界操作；它不会检查或过滤提示词、模型输出或带内响应内容。它可以要求显式导出或传输操作提供证明，但不会阻止普通输出中披露的数据，除非该披露本身被建模并路由为受保护操作。

• 充当操作系统级隔离环境。它不会拦截系统调用、限制进程、沙箱化原生代码，也不会阻止从未调用 protect() 或 BoundaryVerifier 的程序。恶意原生代码和同一用户下运行的程序需要操作系统隔离；Airlock 自己的文档对围绕此 Kernel 的 broker 也有同样的说明。
• 签发授权或证明——这是 Permit 的职责。
• 指明程序使用哪些权限——这是 Scan 的职责。Kernel 会根据调用方声明的允许列表（capabilities=）检查证明。
• 解析凭据——这是 broker 的职责。
• 执行提供商调用——这是适配器的职责。
• 管理租户——这是 Cloud 的职责。
• 检查提示词、模型输出或带内响应内容。它不是提示词过滤器，也不是通用 DLP。
• 证明上游策略或审批是正确的。
• 证明提供商在其一侧正确执行了操作（它会观察提供商响应，但不会验证提供商的内部状态）。
• 阻止控制权移交给适配器后，恶意或有缺陷的适配器撒谎。
• 替代生产密钥托管或基于 HSM 的签名（接口已就绪；部署时需接入提供商）。

边界保证仅在受保护边界是通往资源的唯一路径、后端只接受验证后签发的 broker 凭据，且 Agent 没有长期有效凭据或其他路径时才适用。完整范围见 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）的原子声明/消费/释放
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 引用与确切的执行尝试相匹配，然后才获取凭据。没有此钩子的边界会拒绝包含效果的证明。受信任的边界必须返回匹配的 effect_evidence，其确定性为 COMMITTED、NOT_EXECUTED 或 AMBIGUOUS；仅传输成功并不能证明某项后果已提交。存在歧义时，预留项会保持有效，直到受信任的协调完成。请参阅集成要求和攻击证据。

Python 资源边界和 VerifierSDK 也会强制执行必需的已签名效果约束。旧版托管中间件会拒绝包含效果的证明。验证本身不会确认某项后果已提交：只有构建回执时提供匹配的受信任效果证据，才可完成构建。请参阅入口覆盖范围和已复现攻击。