agent-harness-defense 是一个面向 LLM 编码代理的准入层，通过 plan-first 信息流策略阻止指令权限提升。它并非运行时防火墙，而是一个库：在变更应用前调用 run_admission() 传入代理提议操作的显式描述，返回放行或拒绝的裁决及理由。
决策核心是双格信息流控制引擎，每个数据带两个标签：机密性（是否秘密）与完整性（是否可信）。当动作依赖低完整性数据（如仓库 README），即使内容不含任何触发词，动作也会继承不信任——这正是它能捕获 v0.1 启发式方法（触发短语）漏掉的提示注入的原因。v0.1 启发式保留为备份信号。
引擎机制：evaluate_plan 对 depends_on 图做分量格连接，机密性取最大值，完整性取最小值——UNTRUSTED 值与 SYSTEM 意图连接后仍为 UNTRUSTED，阻断升级规则。读取按路径分类：仓库文本产生 UNTRUSTED 完整性，系统文件产生 SYSTEM。依赖不可信读取的写入被拒绝（no-upgrade），env.SECRET 写入公共接收器被拒绝（no-downgrade）。
审计发现并修复了一个真实缺陷：_step_initial_label 对每次读取都返回 (PUBLIC, SYSTEM)，导致传播仅靠 value_source 中的魔法前缀工作。修复后由 _classify_read_path 从路径派生读取标签，并添加回归测试。
验证结果：pytest 23 项通过（0.29s），ruff 与 bandit 检查干净。评估套件覆盖 3 个场景（README 注入、CLAUDE.md 范围扩展、自有秘密泄露场景），每个场景都有测试证明 v0.1 会放行而新引擎会拦截。
需明确其边界：不自动提取计划，Plan 必须由调用方显式提供；传播基于声明而非真实内容；评估语料仅 3 个场景且均为英文直白攻击文本；无真实跨迭代持久化，也从未在真实代理或生产流量上运行。作者定位为经严格审计的研究原型，而非开箱即用的生产防御。
仓库：GitHub
#开发者 #工具 #agentharnessdefense #LLM #安全 #IFC #提示注入 #AGPL #Python
@DevToolboxHub