在我雇佣第一个代理之前,我统计了我们的凭证。共有285个,其中5个有明确的所有者。
摘要
作者正在建立一家由AI代理运营的公司,详细描述了管理285个凭证的安全挑战,并寻求关于在自托管Phase实例中为代理配置秘钥访问的建议。
我正在建立一家依赖代理而非员工运营的公司。第一个代理负责配置和部署VPSs,因此它从第一天就需要真实的凭证。在编写任何代码之前,我盘点了我们已有的东西。共有285个凭证。其中180个是生产环境的。5个是任何人都能看出谁或什么在使用的。五个Cloudflare超级管理员权限,其中2FA是关闭的,三个绑定到个人Gmail账户。这是一个人类组织造成的混乱。现在我想添加一些能在凌晨3点工作且永远不会忘记它创建的令牌的东西。我在任何地方都找不到答案的部分是:秘钥存储在自托管的Phase实例中,我不知道每个代理是否拥有自己的工作空间,还是它们共享一个具有范围访问权限的工作空间。对于三个代理来说,每个代理一个工作空间是干净的。但到了三十个代理,就需要管理三十个需要轮换、审计和停用的东西。共享的话,就是一个东西运行,直到一个代理的泄露读取其中的所有内容。每个写这个的人都是一个有身份产品的供应商。如果你真的运行具有生产凭证的代理:你选择了哪种方式,在多少个代理时你后悔了?
相似文章
每个智能体都应该拥有自己的身份和凭据吗?
一场关于是否应该为每个 AI 智能体分配独立身份和短期有效、权限范围受限的凭证,而不是共享同一个 API 密钥的讨论,其中也探讨了 MCP 服务器如何融入这一模式。作者邀请大家分享实际部署方案和经验教训,探讨在什么情况下为每个智能体分配独立身份会显得过度设计。
我们构建了一个54个代理的生态系统,其中一些代理是持久的虚构角色——最困难的部分一直是控制他们被允许学习的内容
作者描述了为名为Trading Hearts的项目构建一个54个代理的生态系统,重点在于控制代理学习和维护持久身份与规则方面的挑战。
如何在不交出主账号的情况下处理智能体身份验证与授权?
一位开发者推广 Decoy (decoys.me) 这款产品,它为 AI 智能体提供作用域受限、可随时撤销的任务专属身份,而不是直接访问主账号;产品具备客户端加密功能,并提供一个由用户掌握的知识图谱,用于跨智能体的上下文共享。
20个代理之后,我们终于承认自己不知道公司里到底有多少代理
一家公司分享了他们在组织内部追踪AI代理的困难,最终开发了一个代理注册表,用于解决可发现性、访问控制、日志和使用指标等问题,并最终采用了TrueFoundry的解决方案。
大多数多智能体设置就像一屋子戴耳机的人。以下是我所做的改变。
作者分享了构建多智能体基础设施的心得,指出“身份漂移”是关键挑战,通过实施严格的智能体通行证和文件访问控制解决了这一问题。