deny 是 Agent 与开发工具权限控制体系中的一个核心操作，指系统在 Agent 或用户请求执行某个敏感动作时明确拒绝该请求的机制。随着 AI Agent 获得执行代码、调用外部工具的能力，「何时该 deny、deny 之后如何反馈」正成为安全设计的关键议题，Claude Code、Perplexity 等产品都在这一方向上持续迭代。
Agent 权限控制中的 deny 机制近期进展
Perplexity 为其 Computer 产品新增了连接器权限控制，支持人工干预。这意味着当 Agent 试图访问外部服务时，用户可以设定规则允许或拒绝（deny）特定连接，并在执行前进行审批，把「拒绝权」交还给用户。相关讨论见 Perplexity Computer 新增连接器权限控制，支持人工干预。
Claude Code 在近期版本中密集更新了权限相关逻辑。据社区统计，2.1.299 与 2.1.300 两个版本两天内更新 278 处，带来 7 项实用改动，其中涉及工具调用批准与拒绝规则的处理，用户可以通过配置文件更精细地定义哪些操作自动放行、哪些必须 deny。官方发布记录见 v2.1.300。
Docker 发布了 Sandbox Kit 规范 v3，并与 Linux Foundation 联手推动其成为开放标准。该规范强调把不可信代码放进隔离环境运行，从「运行时拒绝危险操作」转向「先隔离再授权」的思路，为 deny 之外提供了另一层防护。参见 Docker 发布 Sandbox Kit 规范 v3，与 Linux Foundation 联手推为开放标准。
当前焦点与观察点
目前社区讨论的焦点在于：deny 不应只是一个静默的报错。有开发者总结长程 Agent Harness 的设计模式时指出，一次性 Agent 失败会当着用户的面停下来，而长时程 Agent 在被拒绝或出错后可能悄悄隐藏问题、继续运行，这类事故表明 deny 之后的状态反馈同样重要（长程 Agent Harness 的 5 个设计模式）。
另一个趋势是 deny 的粒度在变细。从「允许/拒绝整个工具」演进到按参数、按连接器、按路径细粒度控制，Perplexity 的连接器权限和 Claude Code 的规则配置都体现了这一点。
观察点主要有三个：一是 Sandbox Kit 能否真正成为跨厂商标准，统一隔离与拒绝语义；二是各产品如何平衡自动 deny 带来的安全性与频繁中断带来的体验损耗；三是当 Agent 长时间自主运行时，被 deny 的操作是否会留下足够的审计痕迹。对于正在构建 Agent 系统的团队而言，把 deny 设计为可观测、可配置、有明确反馈的动作，而非简单的失败返回，是当前较稳妥的实践方向。