Prismor — agent runtime security control plane

wiki/ai/sources/prismor-runtime-control-plane.md

分类：ai / sources · 更新：2026-08-13 09:05

Prismor — agent runtime security control plane

深度判断

结论：晋升为正式 source page。 Prismor 把 coding agent 的安全从“事后看系统日志”前移到 agent/tool 调用边界：pre/post tool-call hook、MCP gateway、tool tags、secret cloaking、canary、IAM、signed audit trail 和 attestation bundle 共同形成一个运行时控制面。它值得进入 llm-wiki，因为用户的 Hermes 自动化越来越多，真正的风险不在“模型是否听话”，而在工具调用、MCP 返回、secret、依赖安装和跨步骤数据流是否被治理。

机制 / 一阶原理

机制上，Prismor 采用四阶段路径：agent/tool call 先进入集成面（hooks、MCP gateway、framework adapters），再由 policy engine 和 pre-execution checks 给出 observe/enforce verdict，随后进入本地 tamper-evident evidence，最后可选接入 self-hosted control plane。关键思想是 policy 权威在外层控制面，而不是让 agent 自己解释规则；observe/enforce 还被设计成 per-rule 模式，便于先审计再逐步收紧。

与已有 wiki 概念的关系

它与 Harness-Engineering 的 effect boundary、Context-Engineering 的 context provenance、Agent-Benchmarks 的 security-tool eval、External-Agent-Skills-Design-Patterns 的 skill/MCP admission 直接相连。相比 Cyclops/MCP Guardrail 这类窄边界工具，Prismor 更像横跨 coding agents、MCP、framework agents、secret 与 audit 的 runtime membrane。

对 Hermes / llm-wiki / agentic workflows 的启发

对 Hermes 的可执行启发：高风险 cron、CVM 发布、外部 skill 安装、MCP 接入、浏览器抓取后写入等流程，应逐步抽象成同一类“pre-call policy + post-call receipt”接口；至少在报告中记录 action scope、是否读过 untrusted/source 内容、是否可能 egress、验证 receipt 和是否只是 observe。

失败模式、边界条件与未解问题

边界条件：README 声明的能力面很广，实际覆盖质量需要逐项验证；hook 层工具可能产生误报、漏报或性能/摩擦成本；如果控制面本身可被 agent 修改或禁用，就会形成 false confidence。因此本页只沉淀设计模式，不等于建议无人安装。

来源与证据

GitHub: https://github.com/PrismorSec/prismor
Stars at ingest: 284
Last pushed at ingest: 2026-08-12T21:05:40Z
Raw archive: prismor-runtime-control-plane-readme-2026-08-13

写入记录

2026-08-13 09:00 CST：从 GitHub README 深度入库，新增 source page、raw archive，并关联 harness/context/benchmark/skill 设计模式。