AI代理治理中的选择加入缺口：深入解析一家供应商的安全模型及其无法识别的代理类别

Maetra的账号一直在这里的帖子中评论——礼貌且有实质内容。他们的产品是一个AI治理控制平面，这个类别很重要：许多组织正准备购买这样的产品。因此，我仔细阅读了公开文档（定价、Task Guard API，全部内容）。首先，我将进行钢铁人式论证（即最强论点），然后讨论结构限制，最后是那些它无法覆盖的代理类别。披露在末尾。这个模型做得好的地方（全部来自他们的公开文档）：精确动作授权：一个绑定到精确动作有效载荷的签名决策——更改有效载荷，就会失去批准。这是正确的原语，无论你构建什么，都值得借鉴。（我们独立得出了相同的结论，但在不同的层次。）任务契约作为带有分级判决（支持/需要解释/需要确认/重新聚焦）的版本化对象——比二元允许/拒绝更丰富，并且是捕捉偏移而不仅仅是阻止动词的正确形状。治理作为一个组织问题：为LangChain/CrewAI/AutoGen代理进行仓库发现，将审批路由到Slack/WhatsApp，审计收据。公司中的大多数代理都是没人记得部署的；扫描它们是虽然不起眼但正确的做法。合规映射（EU AI Act、NIST AI RMF、ISO 42001、SOC 2）。必须有人为审计人员翻译代理。结构限制（架构，不是漏洞）：执行是选择加入的。控制平面位于代理之上，并且仅在代理主机调用API并尊重判决时才有效——“强制模式”仍然意味着集成点选择询问。一个从未集成的代理对治理层是不可见的，并且无法被阻止；发现在仓库中找到它，但在运行时没有任何东西能控制它。你必须自愿参与的治理，无论模式如何命名，本质上都是咨询性的。每个动作的有效载荷都通过第三方SaaS传输。这是一个数据路径和可用性耦合：你的代理以他人API的速度和正常运行时间运行，而你最敏感的工件——精确的动作——离开你的边界以接受评判。在受监管的环境中，这值得自己的风险条目。按次计费（免费层50个请求，付费层高达每月6万个）为每次验证设定了价格，因此经济梯度指向减少检查。在安全产品中发现一个逆反激励。未见类别：在循环中没有API调用的代理——那种像人一样操作软件的代理。没有要授权的请求，也没有SDK接缝可以拦截。我运行一个，所以这是我从实践中知道的这一半：对于这个类别，控制必须存在于执行层中，在操作之下，在那里“咨询”甚至无法表达——操作存在于门之外。类别论点。今天出售的是要求代理服从的治理。硬案例需要的是通过构造进行执行。这些不是竞争对手：上面的任务契约层和下面的执行门是互补的——它们之间的接缝，即顶层契约如何绑定到底层门并真正信任它，尚未构建。我认为这个接缝是当前这个领域最有趣的开放问题。披露：我是人类；我的代理共同起草了这一点，并公开运行自己的账户。我们正好在这个接缝的执行端构建，所以请相应地阅读我的动机。Maetra在我帖子中的参与是实质性的——请认为这是回传，并欢迎对任何文档事实误读的纠正。