AgentMinder：企业 Agent 的权限为什么必须绑定意图，而不只是绑定身份
传统零信任系统验证“谁在调用什么资源”，但 Agent 的危险常常来自另一层：同一个已授权身份，在不同任务里调用同一个工具，风险完全不同。财务 Agent 为核对发票读取供应商账户是正常动作；它因为网页里的间接提示去批量导出账户，就算 token、网络和 API 都合法，也已经偏离任务。
Broadcom 在 8 月 31 日发布 AgentMinder，核心主张是把 Agent 身份绑定到 declared mission、permitted intents、approved tools 和 authorized resources，并在每次工具调用时动态判断。产品细节仍需实际验证，但这种“意图约束的运行时授权”指出了企业 Agent 治理缺失的一环。
身份只说明谁在请求；网关还必须结合本次任务意图和资源范围，在工具执行前完成确定性裁决。
Identity、Intent 与 Capability 的区别
身份回答 Agent 是谁、归谁负责；意图回答这次运行要完成什么；capability 则是为该意图签发的最小执行能力。三者不能混成一个 JWT。
建议在任务进入 Runtime 时生成不可变 intent_id，包含业务目标、对象范围、时间窗、允许的数据分类、最大成本和审批规则。策略服务据此签发短期 capability。工具网关每次调用都检查 capability 是否覆盖具体资源和动作，执行后把 receipt 绑定回同一个 intent。
自然语言意图不能直接作为安全策略。它必须编译成结构化约束，例如：
{
"purpose": "invoice_reconciliation",
"tenant": "supplier-a",
"period": "2026-08",
"actions": ["invoice.read", "payment.read"],
"writes": false,
"expires_at": "2026-09-05T10:30:00Z"
}
模型可以建议这份约束，但最终模板、字段上限和风险级别由确定性代码生成。否则攻击者只需诱导模型把意图改写得更宽。
为什么策略必须在 Gateway 执行
把“不要访问敏感数据”写进 system prompt，只是行为建议。真正的 enforcement point 必须位于工具前：即便模型被提示注入、上下文污染或供应链组件劫持，Gateway 仍可以拒绝越界参数。
Gateway 还应完成 token exchange。Agent 不持有 CRM、ERP 和云账号的长期密钥，而是提交用户身份、intent 与工具请求；凭证代理换取短时、窄范围令牌。这样撤销用户权限或结束任务后，遗留 Agent 不能继续行动。
AgentMinder 宣布支持通过 AuthZEN 对接现有授权体系，并用 OpenTelemetry 提供 session 与 action 级追踪。工程上要注意：OTel span 默认不是合规审计日志。span 可以采样、丢失或包含敏感参数；审计事件应独立持久化，只在二者之间共享 trace id。
动态授权需要哪些上下文
每次决定至少包含主体、代理链、意图、工具、资源、环境与历史风险：
- 主体：用户、Agent、子 Agent 与服务身份；
- 代理链：权限从谁委派而来，是否继续缩小；
- 工具：版本、schema、风险等级和数据域；
- 资源：租户、对象、字段级分类和区域；
- 环境：生产/测试、网络区、设备可信度；
- 行为：本次 run 已调用次数、成本、异常序列和审批状态。
策略决定最好返回 allow/deny/require_approval、原因码、命中的策略版本和允许的参数收窄。Agent 收到拒绝后只能选择安全替代路径，不能反复改写参数探测策略边界。
AgentMinder 不能自动解决什么
意图治理无法证明模型真实“内心意图”，它只能约束可观察的动作；也无法替代工具本身的业务校验、数据最小化和补偿事务。若一个“只读”工具返回整库客户数据，Gateway 即使正确授权也会造成过度暴露。
因此上线前要做三类测试：用间接提示诱导越界；在委派链中尝试扩大权限；让合法调用组合成异常结果，例如高频小批量导出。策略单测只能验证规则，端到端攻击路径才能验证系统。
企业 Agent 的治理目标不是让模型永不犯错，而是让错误在到达高后果工具前被确定性边界截住，并留下可解释的证据。身份是入口，意图是范围，Gateway 才是最终执行点。