这篇论文（cs.AI / cs.SE）聚焦一个在「AI 编码智能体辅助科研开发」场景中日益尖锐但缺乏系统分析的矛盾：同一份代码仓库里，某些模块是构建物理求解器所必需的（编译器必须读取），但同时又属于不宜暴露给外部编码智能体的知识产权（agent 不该读）。换言之，安全策略需要做到「同一文件、同一路径，按读取主体区别对待」——允许编译器进程读取，禁止智能体读取。作者指出，当前把智能体接入开发环境时常用的三类隔离手段都默认了「谁读都一样」这一前提：(1) 容器隔离，(2) 文件系统权限规则，(3) 沙箱。论文把可能的读取路径系统性地归纳为十五条读取路由（read routes），并逐条对照上述三种机制进行分类验证，检验它们能否在「智能体正在读取」与「编译器正在读取」之间做出区分。核心结论是：这三种机制都无法判断究竟是哪个程序在执行读取——它们能约束读取的范围与身份，却缺乏对「读取者进程语义」的辨别能力，因此不足以承载这类细粒度的知识产权边界。其贡献在于把问题形式化为「读取主体识别」而非传统「访问控制」问题，并通过对十五种读取路径的对照分类，说明现有工程化防线在这一维度上的共同盲区，为后续研究（如基于进程溯源、构建行为建模或工具调用拦截的方案）提供了问题定义与评估基线。适合 AI 智能体安全、开发者平台安全、供应链与知识产权防护方向的研究者和工程师阅读。
💡 推荐理由: 越来越多团队把编码智能体接入真实研发仓库，其中常含未公开算法或专有求解器代码。本文说明容器、权限规则、沙箱这三类主流防线都无法区分「编译器读取」与「智能体读取」，意味着单靠部署时的隔离配置并不足以保护这类知识产权，需要更细粒度的读取主体识别能力。
🎯 建议动作: 研究跟进：在内部智能体接入评估中加入「读取主体识别」测试项，验证现有隔离措施能否区分构建进程与智能体进程的读取行为。