人工智能领域正在经历一场关于高级模型在部署前治理与评估机制的广泛讨论，然而这些宏大的讨论往往忽略了实际的程序代码，正是这些代码决定了人工智能代理是否被允许执行敏感操作，例如发送电子邮件、修改加密密钥、合并软件分支或转移资金。这些决定并非由大型实验室或监管文本制定，而是由返回真或假值的简单程序函数所做出。
针对名为“PIC”的代理操作验证开源协议进行的压力测试表明，问题并不一定源于加密失败，而是源于协议接受了多种表面上正确但可能产生不同解释的格式。例如，结构模式可能接受大小写字母的哈希码，而解释器处理它们的方式可能导致不同系统间产生迥异的结果，且并未违反已公布的标准规范。
JSON 模式在数据验证方面的局限性
JSON 模式在验证数据结构方面发挥着基础但有限的作用；它们确保了所需字段的存在、值类型的正确性以及对通用规则的符合性。然而，该模式无法强制执行复杂的关联规则，例如确保某个特定的证据引用指向资源数组中的唯一元素，而不产生重复或歧义。
不同编程语言在执行搜索或匹配标识符时的差异会导致所谓的“解析器差异”，这是一种曾在 HTTP 和 JWT 等协议中出现过的旧式安全漏洞，即两个组件以两种不同的方式读取相同的输入。在现代代理协议中，这些细微差别导致某些服务接受了操作，而使用相同策略和规范的其他服务却拒绝了该操作。
规范化操作对协议安全的影响
开发人员通常倾向于对输入进行规范化处理以避免拒绝可恢复的数据，例如删除多余空格、将字母转换为小写或修复 Base64 填充。然而，这些做法在身份验证边界处构成了真正的风险。例如，如果解释器在将工具名称与允许列表匹配之前对其进行了规范化或删除了空格，系统可能会执行签名方未批准的操作，或者在开发人员不知情的情况下操纵执行权限。
此外，依赖代理自身发送的字段来确认其来源的可靠性，会引发数字形式的“混淆代理”问题。信任必须完全源于法律执行和验证边界之内，通过验证数字签名并将其与操作员直接信任的加密密钥进行匹配，而不考虑请求负载中包含的声明。
三层架构与执行匹配向量
为了避免这些漏洞，需要一种明确区分以下三个连续层的架构：
- 模式验证：用于拒绝损坏的结构和不符合网络的表示形式。
- 语义验证：用于解析引用、验证关联并推导实际信任。
- 策略评估：用于就是否允许或阻止执行操作做出最终决定。
仅依靠文档说明是不够的；必须具备明确的执行匹配测试工具，其中包括精确的输入、预期的结果以及用于处理模糊情况的稳定错误代码。这些向量确保了所有实现中的行为一致性，并防止安全依赖于不同软件桥接器中差异化的默认配置。