AI Agent 进公司,第一件事不是提效,是管权限

过去聊 AI Agent，最容易让人兴奋的是“它能自动做什么”。

自动查资料，自动写代码，自动填表，自动发起工单，自动整理知识库。对创业者和产品团队来说，这些演示很有吸引力，因为它们直接指向一个结果：少招人，快交付，把复杂流程交给模型。

但 2026 年 8 月 6 日这期 AIHOT 日报里，几条消息放在一起看，真正的重点不是 Agent 又多会干活，而是企业终于开始认真面对另一个问题：

当 Agent 可以进公司系统之后，谁允许它看什么、改什么、花多少钱、把结果发给谁？

Cloudflare 同一天围绕企业智能体连续释放了三个信号：开源 Cloudflare OS，推出身份感知 AI Gateway 和 User Insights，又提出 Agent Access Model。旁边还有 Atlassian Rovo 被曝可通过间接提示注入窃取 Jira 和 Confluence 数据，Claude Platform 推出 inference hooks，把受管控提示词交给组织的安全服务器判定。

这几件事共同指向一个变化：企业 AI 的下一轮产品机会，不只是把 Agent 接进业务流程，而是给 Agent 建一套真正可用的权限系统。

Agent 工作台会变成企业入口

Cloudflare OS 的定位很清楚：每个员工都有一个基于公司上下文和技能的智能体工作区，可以连接内部系统，运行个人应用，共享修改结果。

这类产品形态对中国创业团队也很有参考价值。过去很多 AI 工具像“外接插件”：用户把一段内容复制进去，模型返回一段内容，结束。

但企业场景不会停在这里。真正高频的工作，往往发生在多个系统之间：

工作场景	Agent 需要触达的系统
销售跟进	CRM、邮件、会议纪要、合同系统
客服处理	工单、知识库、订单、退款规则
研发协作	代码仓库、Issue、CI、监控平台
人事流程	员工档案、审批、权限、薪酬规则

如果 Agent 只能回答问题，它只是一个聊天框。如果它能跨系统执行任务，它就会变成新的工作入口。

这也是风险开始变大的地方。一个员工自己点错按钮，影响范围通常有限；一个 Agent 被错误提示词诱导，可能在几秒内读完一批文档、调用多个工具、把敏感信息带到错误位置。

权限不能只看“这个人是谁”

传统企业权限管理，核心问题是“这个账号有没有权限”。但 Agent 场景里，这个判断不够。

因为 Agent 做事时至少有三层身份：

1. 发起任务的人是谁。
2. 执行任务的 Agent 是哪个。
3. 当前这一步动作要访问什么资源。

Cloudflare 提出的 Agent Access Model 有一个很重要的判断：不要信任运行过程本身，而是对任务执行图里的每个动作做实时授权。换句话说，不是给 Agent 一张通行证，让它在公司系统里自由移动；而是每到一个动作，都重新判断它是否应该继续。

这对产品设计影响很大。

很多团队做企业 Agent，第一版喜欢设计一个“连接所有工具”的配置页：接上飞书、钉钉、GitHub、Notion、数据库、客服系统，然后让 Agent 自己规划任务。

这个方向看起来很顺，但上线后最容易出问题。因为 Agent 的计划会变，工具调用会变，用户输入也会变。真正应该产品化的是动态授权：

授权维度	应该判断什么
用户身份	这个人本来能不能看这些数据
任务意图	当前任务是否需要访问这类资源
已触达资源	前面读过的数据会不会污染后续动作
动作类型	是只读、修改、发送，还是外部分享
风险等级	是否需要人工确认或额外审计

这不是安全团队的边角需求，而是 Agent 产品能不能进入企业核心流程的前提。

真正的事故常常来自“看起来正常”的工具调用

Atlassian Rovo 的漏洞值得产品团队认真看。根据 AIHOT 摘要，这个问题可以通过间接提示注入，利用 URL 检索工具窃取租户内 Jira 工单和 Confluence 文档；即使组织禁用 Rovo 的网页搜索功能，攻击仍然有效。

这里的警示不是“某个产品有漏洞”，而是一个更通用的问题：Agent 的危险动作，未必长得像危险动作。

它可能只是：

• 读取一个 URL。
• 总结一份文档。
• 帮用户补全一段说明。
• 把结果整理到另一个页面。

单独看，每一步都像正常工作。但如果前一步读到的内容里藏着恶意指令，后一步又拥有内部工具权限，数据就可能从内部系统流出去。

这也是为什么 Cloudflare 的身份感知 AI Gateway 和 User Insights 很值得关注。它们把每个 AI 请求绑定到经过验证的用户身份，并基于账户历史行为识别异常会话。比如某个用户平时一次会话只花很少成本，突然出现明显超出历史基线的调用，就应该被标记出来。

对企业 AI 产品来说，成本监控和安全监控会越来越像一件事。异常 token 消耗、异常工具调用、异常数据读取，经常是同一个风险的不同表征。

安全策略要进入提示词之前

Claude Platform 这次推出 inference hooks，方向也很明确：组织可以把 claude.ai、Cowork 和 Claude Code 中的受管控提示词交给自己的 AI 安全服务器，先做允许或拒绝判定，再继续推理。

这说明平台方也在把“安全判断”从模型回答之后，前移到请求进入模型之前。

这对创业团队有一个现实启发：不要把安全都压在系统提示词里。

系统提示词当然重要，但它不是权限系统。一个成熟的企业 Agent，至少应该有四层控制：

控制层	作用
请求前检查	判断任务是否允许进入模型
工具调用授权	判断每一步工具调用是否合理
运行中监控	识别异常成本、异常路径、异常外发
结果前审查	对发送、修改、删除等动作加确认

如果只靠提示词约束 Agent，就像让一个实习生背员工手册，然后把所有系统管理员权限都交给他。它可能大多数时候表现不错，但一旦遇到诱导、误解或越权场景，损失会很难追回。

产品团队现在该做什么

如果你正在做面向企业的 AI Agent，可以从这期日报里带走几个很具体的动作：

1. 不要只做“工具连接数”的竞争。连接越多，权限边界越要清楚。
2. 给每个 Agent 定义身份，而不是只继承用户账号。
3. 把任务拆成可审计动作，记录每一步读了什么、改了什么、发给了谁。
4. 对高风险动作设置人工确认，尤其是外发、删除、付款、权限变更。
5. 把成本异常当成安全信号，而不是只当财务指标。
6. 为间接提示注入准备测试集，别等客户数据出事后再补规则。

过去一年，企业 AI 产品最常见的卖点是“让员工更高效”。

接下来，这句话只说了一半。企业真正需要的是：让 Agent 更高效，同时让组织知道它为什么这么做、是否有权这么做、出问题时能不能立刻停住。

Agent 进公司，第一件事不是替人工作。

第一件事是拿到一张被约束、可追踪、随时可撤回的工作证。