如何在不让代理拥有写入权限的情况下授权数据库访问?
摘要
一位开发者分享了一种解决方案,通过MCP服务器为AI代理提供只读数据库访问,该服务器强制实施READ ONLY事务和突变防护,防止写入操作并降低影响范围。
构建需要从数据库读取的代理时,总会遇到同样的矛盾:为了让代理查询你的数据,你通常会给它一个连接字符串——现在,如果代理幻觉出一个“修复”或被提示注入,它也能执行 `UPDATE`、`DELETE` 或 `DROP`。对于大多数代理用例,实际需求是*读*访问:查找记录、检查模式、拉取一些行进行推理。写功能纯粹是副作用——所有风险都在那里,几乎没有任何价值。因此,我构建了一个MCP服务器,让代理拥有读取权限,并使得写入不可能,而不仅仅是劝阻:
* 将其指向Postgres连接字符串,它会暴露一个MCP端点供你的代理连接。
* 每个查询都在 `READ ONLY` 事务内运行——即使代理生成了破坏性查询,数据库也会拒绝。
* 守卫会在执行前拒绝突变语句和危险函数(文件读取、SSRF式调用)。
* 返回模式+结果作为结构化内容供代理操作,无需第二次往返。
我不断回到的一点是:拥有只读数据访问的代理是*有用*的;拥有对生产库写入访问的代理是一种你尚未被收费的负担。好奇这里其他人如何处理——单独只读副本?受限角色?应用层封装?只是信任模型?有一个沙盒可以尝试此方法而不需要连接你自己的数据库(评论中的链接)。
相似文章
如何阻止编码代理接触生产数据?
讨论防止AI编码代理意外修改生产数据库的策略,主张使用只读访问、沙盒环境和审批关口,而不是仅仅依赖提示。
我们让AI代理访问数据库、邮件系统和支付API。然后我们只是……信任它们。
本文强调了当前对能够访问数据库、邮件系统和支付API的AI代理严重缺乏治理层,指出目前在没有监督的情况下信任LLM的做法危险且不足。
给AI agent生产环境的密钥,这能行吗?
一种面向AI agent访问生产云基础设施的安全设计方案,采用拆分凭证和审批门控机制,防止在未经人工批准的情况下执行破坏性操作。
你们如何处理内部数据代理的权限边界?
本文讨论了在使用LLM的内部BI代理中实施基于角色的访问控制(RBAC)所面临的挑战,涉及数据泄露和操作工作流写入权限的担忧。
我不会推广 - 您在使用MCP时遇到了哪些跨服务器授权问题?
这篇文章探讨了当多个MCP服务器(例如Gmail、Github、Slack)在同一AI代理会话中一起使用时,所面临的跨服务器授权挑战,并提出是否需要除了每个服务器的OAuth之外的专用授权层。