OpenAPPA
OpenAPPA 是「面向 LLM 智能体的信息流策略引擎 / 确定性 AI 护栏」：它不在 agent 的 prompt 或执行循环里（模型看不见、无法协商操纵），而是用声明式 appa.toml 描述数据源、受众、信任级别与权限，对每一次工具调用的数据流转做代数推导式决策，宣称对 prompt injection 与模型幻觉导致的数据外泄 100% 免疫、且不像概率型 auto-mode 那样破坏 agent。兼容 Claude Code / Codex / kAgent / MCP 网关 / 生产 agent，MIT 开源、vendor-agnostic，可在 CI/CD 校验整张工具图覆盖。适合自己构建并部署 AI agent、担心「agent 被注入后把密钥/PII 外发」的工程与安全团队。
核心功能
- ✓ 智能体
- ✓ 开源
- ✓ 可自托管
- ✓ 企业级安全
👍 优点
- + 真·确定性护栏，不是概率判断：用信息流（information-flow）代数而非「第二个模型打分」来决策，宣称对 prompt injection / 模型幻觉导致的数据外泄 100% 免疫，因为「你没法 prompt-inject 一个代数」
- + 实测强于概率型方案：基准上任务完成率 OpenAPPA 89% vs Claude Auto 90% vs 微软 FIDES 41%；成功攻击 0% vs Auto 10% vs FIDES 31%，且不像 auto-mode 那样把工具输出藏起来导致「法官看不到数据」
- + 跑在 agent 的 prompt 与执行循环之外：模型看不见、无法协商或操纵它，单点接入现有 agent loop（Claude Code / Codex / kAgent / MCP 网关 / 生产环境 agent），vendor-agnostic
- + 声明式配置可审计、可 CI 校验：appa.toml 描述数据源、受众、信任级别与权限，而非「允许/禁止工具」黑名单；可在 CI/CD 验证整张工具图被覆盖，可扩展到百万级 agent 而无需改配置
- + 开源 MIT + 不破坏 agent 体验：返回机器可读的 remedy plan（sanitizer 脱敏/掩码 PII、authority 单次授权等）让 agent 合法继续，而非粗暴 forbid 导致卡死重试；含现成 batteries、可自建
👎 缺点
- - 定位极专业、受众窄：面向「自己构建/部署 LLM agent 的团队」，需要理解信息流策略与 appa.toml，非开箱即用的终端用户产品
- - 生态与成熟度尚早：作为较新的开源项目（Archestra 旗下），社区规模、第三方 batteries 数量、长期维护与文档完善度仍需观察
- - 基准由自家发布：89%/0% 等数字来自项目方 benchmark，外部独立复现与大规模实战案例有限，应审慎看待
- - 需要正确配置才有价值：声明式策略若写得过松则漏防、过紧则仍可能绊住 agent；落地效果高度依赖团队对数据分类与信任模型的建模
- - 非「全能安全」：聚焦数据外泄/权限流控制，不替代完整的应用安全、鉴权或合规栈，需与其余控制组合
适合人群
最适合： 自己构建并部署 LLM agent 的工程与安全团队：用 Claude Code/Codex/kAgent 等 coding agent 或自建 MCP 网关/生产 agent，担心被 prompt injection 诱导把 API key、客户 PII、私有代码外发；希望护栏跑在模型之外、无法被协商操纵，且能用声明式策略在 CI/CD 审计「整张工具图是否被覆盖」；偏好开源、vendor-agnostic、可自托管、按自身信任模型扩展的团队；需要确定性（而非 99.3% 概率）防数据外泄、且不想因严格拦截把 agent 卡死（靠 remedy plan/sanitizer 让其合法继续）的组织。
不适合： 非技术、只想用现成聊天/助理产品的个人用户（这是给开发者集成的安全引擎，不是终端 App）；不愿写声明式策略、配置数据分类与信任模型的团队；期待开箱即用、无需理解信息流概念就能防一切安全的用户；把 OpenAPPA 当作完整应用安全/合规栈的替代品（它聚焦数据外泄与权限流，不替代鉴权/AppSec）；要求大量独立第三方实战案例与商用 SLA 支持的大企业（生态尚早）。
