我询问了20位Agentic AI创始人如何处理智能体访问权限。17位表示依靠临时权宜之计。
摘要
作者调查了20位Agentic AI创始人,发现由于缺乏可验证的授权层,其中17位依靠临时权宜之计来处理智能体访问控制。这突显了处理敏感数据的AI智能体在安全性和审计方面存在显著差距。
在过去几周里,我做了一些可能听起来有点 obsessive 的事情。我联系了那些正在将接触CRM、销售自动化、AI聊天机器人、支付API、电子邮件、患者数据及内部数据库的AI智能体推向生产的创始人和工程师,并向他们每个人问了同一个问题:“你们如何证明你们的智能体只执行了被授权的操作?”
17个人给了我大致相同的答案。他们知道访问权限的缺口是真实存在的,目前他们正通过临时权宜之计来管理这一问题。少数人构建了内部护栏。但没有一个人能生成审计员日后可以验证的加密证据。
最令人不安的故事来自一位金融科技创始人,其智能体负责处理退款。在一次安全审查期间,其企业客户的首席信息安全官(CISO)直接提出了这个问题。这笔交易虽然没有告吹,但因他们匆忙拼凑看似审计追踪的东西而停滞了六周。
我自己也在这个领域进行开发。我与这些人交谈,是想了解我所看到的缺口是否真实存在,还是我只是陷在自己的信息茧房里。20人中占17人的比例表明它是真实的。
从所有这些对话中,最引人注目的是几乎每个人都使用某种形式的提示级安全措施,一些基本手段,因为他们大多希望更快发布产品。几乎没有人拥有智能体与其可访问的工具之间的真实授权层。几乎所有人都承认,正因为如此,他们在安全审查中至少经历过一次令人不安的时刻。
目前我只是在收集数据。如果你正在推送接触敏感系统的智能体,或涉及Agentic AI的任何相关领域,我真的很想听听你们是如何处理授权问题的?哪些方法奏效了,哪些失败了?
相似文章
当你的智能体调用另一家公司的智能体时——谁在真正验证握手?
一位开发者描述了当一个AI智能体调用第三方供应商的智能体时遇到的认证和授权漏洞,重点说明了权限提升、未验证链和混淆代理攻击等故障模式。他们向社区询问如何处理跨组织智能体调用验证。
按治理层而非功能列表划分的AI智能体管理工具
分析指出,大多数企业AI智能体安全投资集中在模型层护栏和可观测性,在访问层和协议层留下了关键缺口。援引2026年报告,75%的企业AI智能体仍处于未保护状态,原因是这些层的覆盖面几乎为零。
我认为大多数“AI agent”项目失败是因为人们跳过了乏味的权限层
作者认为,成功的AI agent产品需要一个健壮的权限系统,包括只读、草稿、审批、有限执行和审计层,优先考虑安全性而非表面的神奇效果。
谁授予了你的AI代理权限?
讨论AI代理工作流中的安全漏洞,即代理在关键步骤中假设存在人类监督,并提出了一个运行时控制平面,用于强制执行权限,并在破坏性操作前要求人工批准,通过Tandem演示进行了说明。
我们让AI代理访问数据库、邮件系统和支付API。然后我们只是……信任它们。
本文强调了当前对能够访问数据库、邮件系统和支付API的AI代理严重缺乏治理层,指出目前在没有监督的情况下信任LLM的做法危险且不足。