maccessUK/MIC

# MIC — 机器意图合约 **状态：** MIC Core 协议 v0.1.1；独立验证器 v2.1.0 MIC 是一个用于自动化任务执行的实验性信任和证据层。 它使用签名合约、策略、受信任的引擎清单和审计记录，来证明机器、自动化工具、后台 worker 或 AI agent 被允许做什么——以及之后产生了什么证据。 MIC 专为那些不应被盲目信任自动化的系统而设计。 MIC 不是让软件或 AI agent 直接执行敏感工作，而是定义： * 正在请求什么 * 允许哪个 engine 处理它 * 允许执行哪些操作 * 适用哪些安全限制 * 允许访问哪些文件、路径或资源 * 必须产生什么证据 * 之后必须存在什么审计记录 MIC 不是 AI 模型。 MIC 不是 workflow engine。 MIC 是一个用于受控、可审计的机器执行的签名执行治理层。 ## 为什么需要 MIC 现代系统越来越多地允许软件和 AI agent 采取实际操作： - 批准付款 - 更改基础设施 - 处理受监管的文档 - 发布生产批次 - 访问敏感记录 - 触发操作工作流 问题不仅在于操作是否成功。 更棘手的问题是证明： - 谁或什么请求了它 - 检查了哪些规则 - 应用了哪些限制 - 允许或阻止了什么 - 产生了什么证据 - 执行是否与原始意图匹配 MIC 的存在是为了让这些操作变得明确、签名、受约束和可审计。 ## 核心理念 传统代码表示： ``` Do A, then B, then C. ``` MIC 表示： ``` Achieve this outcome, using only these allowed actions, within these limits, and prove what happened. ``` ## MIC 的适用人群 MIC 专为从事以下工作的开发者、研究人员、审计员、合规团队和系统设计者设计： * AI agent 治理 * 签名自动化 * 策略绑定执行 * 安全的后台任务 * 受监管的文档处理 * 重度审计的工作流 * 基于证据的任务审批 * fail-closed runtime 系统 * 机器操作验证 MIC 对于普通的 CRUD 应用、博客、基础脚本或低风险的内部工具可能是不必要的。 它针对的是那些问题不仅在于： ``` Did the task run? ``` 而更在于： ``` Was this task authorised, constrained, verified, and auditable? ``` ## 基本流程 ``` Human / System Intent ↓ Signed MIC Contract ↓ MIC Core ↓ Contract Verification ↓ Policy + Safety Checks ↓ Approved Engine Execution ↓ Evidence Output ↓ Audit Record ↓ Application Worker Applies Business State ``` MIC engine 产生证据。 应用程序决定是否应用业务变更。 ## MIC 的优势领域 MIC 专为那些证据和控制至关重要的系统而设计： - AI agent 治理 - 合规系统 - 受监管的自动化 - 安全的任务执行 - 高风险审批工作流 - 文档处理 - 基础设施变更控制 - 重度审计的业务操作 MIC 对于普通的 Web 应用、博客、小型脚本或简单的 CRUD 系统可能有些大材小用。 ## 为什么不直接使用 Workflow Engine？ Workflow engine 负责编排工作。 MIC 则是治理是否允许、限制、验证机器工作并为其提供证据。 一个 workflow engine 可能会回答： ``` What step runs next? ``` MIC 会问： ``` Was this machine action allowed to run at all, under this policy, with this trusted engine, and can we prove what happened? ``` Workflow engine 通常关注： * 队列 * 重试 * 分支 * 调度 * 长时间运行的进程 MIC 关注： * 签名的 intent * 受信任的 engine 身份 * 策略限制 * 允许的操作 * 核心约束 * 证据输出 * 审计记录 * fail-closed 行为 MIC 可以位于 workflow 系统的旁边、底层或内部。它并不试图取代编排。 ## 合约示例 ``` mic_version: "0.1.1" contract_id: "ai-refund-approval-001" engine_id: "example.ai_agent_action_approval" task: "approve_ai_agent_action" input: actor_type: "ai_agent" actor_id: "support-agent-17" requested_action: "issue_refund" target_id: "order_12345" amount_gbp: 149.99 constraints: allow_network: false max_runtime_seconds: 30 max_memory_mb: 256 require_audit: true require_policy_snapshot: true require_human_approval_above_gbp: 100 actions: - verify_actor_identity - verify_requested_action - verify_policy_limits - require_human_approval - generate_decision_evidence - write_audit_event output: format: "json" fields: - decision - reason - required_approvals - policy_snapshot_hash - audit_id signature: "" ``` 此合约不直接发放退款。 它验证请求的操作是否被允许并产生证据。如果 MIC 结果有效，单独的应用程序 worker 随后可以执行退款。 ## 仓库内容 ``` MIC/ ├─ README.md ├─ LICENSE.md ├─ SPECIFICATION.md ├─ SECURITY_MODEL.md ├─ GOVERNANCE.md ├─ CONTRIBUTING.md ├─ examples/ │ ├─ contracts/ │ ├─ manifests/ │ └─ policies/ ├─ docs/ │ ├─ core.md │ ├─ INDEPENDENT_VERIFICATION.md │ ├─ UPGRADING_CODE_ADMISSION_V1_TO_V2.md │ ├─ SIGNING.md │ ├─ TRUST_CHAIN.md │ ├─ positioning.md │ └─ terminology.md ├─ core/ │ ├─ mic_core.c │ └─ README.md ├─ schemas/ │ ├─ approval-manifest-v2.schema.json │ ├─ keyring-v1.schema.json │ ├─ security-profile-v1.schema.json │ └─ security-rule-pack-v1.schema.json ├─ bin/ │ └─ mic.mjs └─ validator/ ├─ README.md └─ verify-manifest.mjs ``` ## v0.1.1 包含哪些内容？ - C 核心源代码 - 合约示例 - engine 清单示例 - 策略示例 - fail-closed 策略模型 - 审计输出格式 - 针对已发布公钥的真实 Ed25519 验证 ## MIC v2 独立验证 独立的验证器在不导入生产者扫描器或审批 engine 的情况下验证代码准入证据： ``` npm run check mic verify-manifest \ --repository /path/to/repository \ --manifest /path/to/approval-manifest.json \ --keyring /path/to/public-keyring.json ``` 原生清单 schema `2.0.0` 和 `2.1.0` 包含已签名的仓库文件清单、扫描根目录、哈希规则、批准状态、阻断性发现摘要、异常过期记录以及 Ed25519 签名。 请参阅[独立验证](docs/INDEPENDENT_VERIFICATION.md)。 该验证器是一个零依赖的 Node.js 20+ 包。它可以通过 `mic` CLI 或导出的 `verifyManifest` API 独立使用。原生 v2 将签名元数据绑定到已签名的字节中，并拒绝不完整的扫描、未来的签名、过期的异常、格式错误的证据、未知的 schema 字段、仓库漂移以及注入的准入文件。 Schema `2.1.0` 还将选定的安全配置文件、精确的 rule-pack 哈希和解析出的规则覆盖率绑定到已签名的准入清单中。 包含的示例使用了显式的占位符签名和 engine 哈希。 它们演示了未经验证的试运行工作流，绝不能将其表示为已签名的生产制品。 ## 便携式安全规则包 MIC Core 现在定义了通用的安全配置文件和 rule-pack 解析： ``` mic validate-security-profile \ --profile examples/security-profiles/housefile-nextjs.example.json \ --rule-packs examples/security-rule-packs ``` 配置文件会选择精确版本的语言/框架 rule pack。核心组件在遇到缺失的 pack、不兼容的扫描器 API、缺失的语言或框架覆盖、缺失必需规则以及规则 ID 冲突时会采取 fail-closed 处理。项目可以无需重写准入、审查、异常、签名或验证机制，将 TypeScript/Next.js pack 替换为 Rust/Axum 或 PHP/Laravel pack。 请参阅[安全规则包](docs/SECURITY_RULE_PACKS.md)。 ## 源代码与二进制文件 公开仓库以源代码作为主要制品发布。 编译后的二进制文件可能稍后通过 GitHub Releases 发布。 除非二进制文件由项目维护者发布，并且其校验和/签名与已发布的发布元数据匹配，否则不要信任二进制文件。 切勿提交私有签名密钥。 ## 快速开始 在安装了 C 编译器、`make` 和 libsodium 开发头文件的情况下： ``` make build build/mic-core \ --contract examples/contracts/compliance-check.contract.yaml \ --manifest examples/manifests/compliance-check.engine.yaml \ --policy examples/policies/default-fail-closed.policy.yaml \ --audit-out audit/compliance-check.audit.json ``` 请参阅[核心文档](docs/core.md)、[签名](docs/SIGNING.md)以及[信任链](docs/TRUST_CHAIN.md)。 ## 当前状态 MIC Core 协议 v0.1.1 和 MIC v2.1 验证器仍处于实验阶段。 当前的重点是： - 定义合约格式 - 定义安全规则 - 验证签名合约验证 - 验证 engine 验证 - 产生有用的审计记录 - 探索真实的治理示例 未经独立审查、测试、认证以及法律/合规批准，请勿将 MIC 用于生命关键、医疗、核能、航空、金融或安全关键的生产系统。 ## 许可证 MIC 在 MIC 社区许可证 v1 下发布。 允许在个人、教育、研究、评估和非商业项目中免费使用。 商业用途需要商业许可证。 请参阅 [LICENSE.md](LICENSE.md)。 ## 简短描述 MIC 是一个用于自动化任务执行的实验性信任和证据层。它使用签名合约在执行发生之前定义 intent、允许的操作、安全约束和审计要求。 ## 关键词 AI agent 治理、签名自动化、机器意图合约、策略绑定执行、runtime 证据、审计跟踪、fail-closed 自动化、Ed25519 验证、安全任务执行、机器操作验证。

标签：MITM代理, Streamlit, 审计日志, 执行治理, 智能体治理, 策略引擎, 网络安全挑战, 网络调试, 自动化, 自定义脚本, 访问控制