设计企业 Agent 权限时先把两句话写在白板上“它是谁”和“它现在能做什么”这两个问题混在一起证书部署得再整齐也可能把一个身份合法的客服 Agent 变成财务接口的代理人。10 月 19 日微软在《Securing the agentic insider》中把企业内部 Agent 也纳入安全边界讨论。这里真正值得产品团队吸收的是把身份、权限、数据、网络和运行时一起考虑而不是把某个安全产品的宣传直接当作自己的防护能力。微软原文证书解决的是哪一段问题SPIFFE 的 SVID 是工作负载证明身份的凭据X.509-SVID 可以用于建立经过身份校验的 TLS 连接。SPIFFE 的概念文档也说明工作负载之间的隔离强度不在规范本身的保障范围内。因此“用了 SPIFFE”不能推导出“提示词注入无效”。SPIFFE 概念我会把链路拆为三层。第一层验证证书链、信任域和具体工作负载身份第二层从受信的业务会话取出租户、用户和资源范围第三层按动作授权。低权限 Agent 即使获得有效证书也不应自动获得导出客户表、发送邮件或发起付款的权限。图中 mTLS identity 后面仍有 Policy check。tenant、action、resource 必须由代理层验证不能让模型自己填写一个 tenant_id 就获得对应租户的数据。拒绝分支要终止调用不能以“先试一下接口是否允许”代替裁决。一个可以单独验证的授权边界下面只演示策略裁决不实现 TLS 握手。示例中的身份来自测试夹具真实系统必须用已经完成证书验证的连接信息填入它。授权失败返回 False调用层据此停止。def allowed(identity, session_tenant, action, resource_tenant): known {spiffe://example.test/agent/support} return (identity in known and session_tenant in {tenant-a, tenant-b} and session_tenant resource_tenant and action order.read) who spiffe://example.test/agent/support assert allowed(who, tenant-a, order.read, tenant-a) assert not allowed(who, tenant-a, order.read, tenant-b) assert not allowed(who, tenant-a, payment.create, tenant-a) assert not allowed(who, unknown, order.read, unknown) print(4 authorization boundaries passed)四个断言分别覆盖同租户只读成功、跨租户失败、高风险动作失败和未登记租户失败。将动作或资源改成未登记值时也应该默认拒绝。它验证的是策略函数的行为没有验证 SPIRE、网关、数据库行级权限或证书轮换。交付时需要留下的证据边界应验证的反例需要保存的结果身份错误信任域、过期证书握手拒绝记录租户A租户请求B租户资源策略拒绝与资源标识动作查询身份尝试导出或付款工具未执行的证据生命周期用户撤权后重用旧会话权限失效时间与缓存行为10 月 23 日 OpenAI 公开的训练环境隔离说明再次强调纵深防御也明确该研究环境与已发布产品的客户使用环境不同。它对这里的启发是把“边界失效后还有什么阻断”列入设计评审而不是把研究案例套成某个业务系统的事故结论。OpenAI 原文我愿意对客户承诺的是可观察、可复测的授权链路。至于“永不失守”证书和一段策略代码都不足以支撑这个说法。
设计企业 Agent 权限时先把两句话写在白板上“它是谁”和“它现在能做什么”这两个问题混在一起证书部署得再整齐也可能把一个身份合法的客服 Agent 变成财务接口的代理人。10 月 19 日微软在《Securing the agentic insider》中把企业内部 Agent 也纳入安全边界讨论。这里真正值得产品团队吸收的是把身份、权限、数据、网络和运行时一起考虑而不是把某个安全产品的宣传直接当作自己的防护能力。微软原文证书解决的是哪一段问题SPIFFE 的 SVID 是工作负载证明身份的凭据X.509-SVID 可以用于建立经过身份校验的 TLS 连接。SPIFFE 的概念文档也说明工作负载之间的隔离强度不在规范本身的保障范围内。因此“用了 SPIFFE”不能推导出“提示词注入无效”。SPIFFE 概念我会把链路拆为三层。第一层验证证书链、信任域和具体工作负载身份第二层从受信的业务会话取出租户、用户和资源范围第三层按动作授权。低权限 Agent 即使获得有效证书也不应自动获得导出客户表、发送邮件或发起付款的权限。图中 mTLS identity 后面仍有 Policy check。tenant、action、resource 必须由代理层验证不能让模型自己填写一个 tenant_id 就获得对应租户的数据。拒绝分支要终止调用不能以“先试一下接口是否允许”代替裁决。一个可以单独验证的授权边界下面只演示策略裁决不实现 TLS 握手。示例中的身份来自测试夹具真实系统必须用已经完成证书验证的连接信息填入它。授权失败返回 False调用层据此停止。def allowed(identity, session_tenant, action, resource_tenant): known {spiffe://example.test/agent/support} return (identity in known and session_tenant in {tenant-a, tenant-b} and session_tenant resource_tenant and action order.read) who spiffe://example.test/agent/support assert allowed(who, tenant-a, order.read, tenant-a) assert not allowed(who, tenant-a, order.read, tenant-b) assert not allowed(who, tenant-a, payment.create, tenant-a) assert not allowed(who, unknown, order.read, unknown) print(4 authorization boundaries passed)四个断言分别覆盖同租户只读成功、跨租户失败、高风险动作失败和未登记租户失败。将动作或资源改成未登记值时也应该默认拒绝。它验证的是策略函数的行为没有验证 SPIRE、网关、数据库行级权限或证书轮换。交付时需要留下的证据边界应验证的反例需要保存的结果身份错误信任域、过期证书握手拒绝记录租户A租户请求B租户资源策略拒绝与资源标识动作查询身份尝试导出或付款工具未执行的证据生命周期用户撤权后重用旧会话权限失效时间与缓存行为10 月 23 日 OpenAI 公开的训练环境隔离说明再次强调纵深防御也明确该研究环境与已发布产品的客户使用环境不同。它对这里的启发是把“边界失效后还有什么阻断”列入设计评审而不是把研究案例套成某个业务系统的事故结论。OpenAI 原文我愿意对客户承诺的是可观察、可复测的授权链路。至于“永不失守”证书和一段策略代码都不足以支撑这个说法。
