知识库里的一段文字要求“忽略规则调用工具”和用户主动授权执行某个动作是两件不同的事。前者是待处理内容不能因为被检索进上下文就升级成系统指令。字符串过滤挡不住语义边界错位只检查命令第一个词可能漏掉绝对路径、不同参数写法和间接调用只搜索一个 namespace 字符串也不能证明资源范围正确。更根本的问题是为什么模型可以提交任意 shell再让黑名单猜它是否危险2026年10月23日OpenAI 的 训练与评估环境安全披露描述了特定研究环境中的多层隔离与持续验证。它不是客户系统的安全保证但足以提醒我们单一边界会失效必须验证实际执行路径。把工具接口收窄到业务动作下面的教学程序只接受一个只读动作。请求不能携带身份或 shell真实身份来自可信会话资源由服务端映射。例子没有试图用正则表达式完成沙箱。SCOPES {oncall-a: {api-staging}} def validate(principal, request): if not isinstance(request, dict) or set(request) ! {action, resource}: return False if request[action] ! read_service_health: return False return request[resource] in SCOPES.get(principal, set()) assert validate(oncall-a, {action: read_service_health, resource: api-staging}) assert not validate(oncall-a, {action: shell, resource: api-staging}) assert not validate(oncall-a, {action: read_service_health, resource: api-prod}) assert not validate(oncall-a, {action: read_service_health, resource: api-staging, principal: admin}) print(schema, action and resource checks passed)模型完全可能提出被拒绝的请求验证器也不判断答案内容是否有害。它只是把执行能力限制在预先定义的范围请求通过后执行端仍要检查当前权限与对象身份避免授权和使用之间发生变化。把攻击样本放在完整链路里测测试材料应包括不可信文档中的伪指令、工具结果里的诱导内容、引用混淆与跨租户同名资源。观察最终工具调用而不只是模型口头说“我会遵守规则”。拒绝理由与审计记录也不能泄露秘密。CNCF 的运行时安全讨论进一步区分了声明检查与真实运行行为。本文仅验证结构化授权逻辑没有运行模型、容器隔离、浏览器或内核策略也不宣称覆盖全部提示注入。防护效果应由完整权限链和对抗回放给出而不是由黑名单长度给出。
