我们检查写入是否成功,但不检查是否仍受保护。
摘要
本文强调了AI辅助开发中一个常见的安全疏忽:智能体验证写入操作,但未能确保适当的权限检查,例如RLS策略是否正确配置。
一直在阅读这里的守护者线程,尤其是第4点(每次写入后的收据),这让我开始思考。回读确认了对象存在,但这与确认它是否受保护不同。尤其是在lovable/bolt/supabase的构建中多次见到这种情况。智能体为表启用RLS,写入数据,回读数据,看到数据在那儿,就标记为完成。但它写的策略是USING (true),所以虽然“启用”了,但功能上完全开放,任何人都可以读取任何人的行。无论如何,收据看起来都很干净。类似的情况也发生在标记为私有的存储桶,但实际上是全球可读的,以及以提升权限运行但没有内部认证检查的函数。有谁的验证步骤实际上检查了权限在写入后做了什么,而不仅仅是写入是否成功?感觉大多数设置都过早地停止在了一个层级上。
相似文章
当 AI 代理即将执行操作时,您会重新检查什么?
本文讨论了在生产环境中,AI 代理执行任务前需要重新检查权限和操作的必要性,因为条件可能发生变化,如记录状态或审批状态。
我们把正确的代理政策写下来了,但没有任何东西强制执行。
文章强调了AI代理政策与实际执行之间的差距,提出规则必须以阻止性检查的形式实施,并通过测试验证以确保合规。
这里有人运行能够实际写入生产系统的AI agents吗?
一位用户正在寻求其他运行具有写入生产系统权限的AI agents的实践经验,讨论如操作验证、重试处理、审计跟踪和内部所有权等运营挑战。
你们当中那些在生产环境中运行AI代理的人——实际上是如何管理它们的权限的?
本文探讨了工程师如何管理生产环境中AI代理的权限,强调了普遍存在的权限过大和缺乏审计追踪的问题。
@LangChain:只读代理易于分支和测试,但可写入生产数据的写访问代理对许多团队来说仍是未解决的评估问题
只读代理比写访问代理更容易测试;对许多团队来说,生产数据的写访问仍是一个未解决的评估问题。