最新资讯
dev.to 我们在 DolphinBench 上测试记忆检索:纯关键词搜索暴露了自身回归 dev.to 别再把 Agent 写成 while 循环,把它建模为状态机 bloomberg.com Rightmove 与 Scout24 借 AI 产品应对低迷房市并上调展望 stackoverflow.blog 欢迎来到芯片时代:半导体制造、AI 数据中心与芯片设计的未来 www.youtube.com AI Agent 总犯同样的错:CentralAgent AI 将记忆重构为经验系统 pub.towardsai.net Netflix 科学家建议重采样 LLM 评判:5 次仅将误差棒缩小 13% pub.towardsai.net Jev 作为 LLM 前的静默层:构建提示感知的模型路由器 reddit.com OpenAI 称 Astra 仅满足 10% 安全任务标准 dev.to FreeToken:在自有 GPU 上运行前沿 MoE 模型及其内存需求 dev.to 当 AI Agent 说“完成”时,究竟完成了什么? dev.to 部署 Underdog Bark 3.0 Pro:逐字转写、自定义后端与分块设置 dev.to 为艰难对话构建 AI:五个 Agent、一条安全正则与一位盲评监督者
多元动态
登录 注册
智能体 dev.to · @Alpha

我的 Agent 不要密码:一种零密钥架构模式

原文 我的收藏

文章指出,团队在把自主 AI Agent 接入 GitLab、MariaDB、OpenProject、Portainer 等核心基础设施时,常倾向于把 API token 或数据库密码直接放进系统提示或环境规则,但 Agent 是非确定性进程,可能产生幻觉、遭受提示注入或上下文被记录,等于把原始凭据交出去。作者提出的模式是反转密钥所有权:不把密钥给 Agent,而是由基于 Model Context Protocol(MCP)的服务器持有,使模型全程不接触任何密码、PAT 或 SSH 密钥。

AI推荐理由 来自开发者社区的技术模式分享,针对自主 AI Agent 接入 GitLab、MariaDB、OpenProject、Portainer 等内部系统时硬编码密钥的风险,提出把密钥所有权从 Agent 转移到基于 MCP 的服务器、使模型不接触任何密码/PAT/SSH 密钥的“零密钥”架构。问题定义具体、方案方向明确,对 Agent 安全与权限设计有实际参考价值;但正文片段未给出完整实现细节与验证结果,属个人经验分享,故质量分未给高分。

66

正文

The Classic Paradox: Trusting AI Agents with Hardcoded Secrets Whenever teams start integrating autonomous AI agents into their core infrastructure (GitLab, MariaDB, OpenProject, Portainer), the first instinct is often: "Let's just pass the API token or DB password into the system prompt or environment rules so it can get things done." As a long-time sysadmin and architect, this raises immediate red flags. An AI agent is a non-deterministic process. It can hallucinate, suffer from prompt injections, or have its context transcripts logged. Handing it raw credentials isn't delegation—it's a scheduled security breach. In my latest technical pattern, I wanted to solve a straightforward challenge: How do we let an AI agent interact with internal systems without ever exposing a single password, PAT, or SSH key to the model? The Core Approach: Inverting Secret Ownership Instead of giving secrets to the agent, we shift secret ownership entirely to a Model Context Protocol (MCP) server backed by HashiCorp Vault: Logical Handles Only: The agent only manipulates short identifiers (resource_id). It never sees, holds, or transmits passwords or tokens. Isolated MCP Runtime: The MCP container authenticates to Vault via AppRole, fetches credentials in-memory, opens backend sessions, and returns only the operational result to the agent. Scoped Action Policies: Tools are restricted at the Vault record level (actions allowlist with MCP_ACTION_POLICY=enforce). Even if a tool exists in the container, Vault denies execution if it's not authorized for that specific resource. Human-in-the-Loop Control: Mutating actions require explicit confirm: true parameters enforced by host rules. Trajectory to V2 (LDAP Identity): Moving from container-wide AppRoles to propagating session identity down to Vault ACLs to eliminate the "confused deputy" flaw. Enter fullscreen mode Exit fullscreen mode Let's Discuss: How Are You Handling Secret Governance? I've published the full technical blueprint—including Mermaid sequence flows, Vault KV schemas, and sample MCP payloads—on GitLab. I’d love to hear how other engineers and architects on dev.to are tackling these boundaries: How do you currently isolate AI agents from core infrastructure secrets? Are you relying on native MCP servers, proxy layers, or custom API wrappers? What mechanisms do you use to enforce human validation before an agent mutates state? Enter fullscreen mode Exit fullscreen mode Looking forward to reading your feedback, critiques, and alternative approaches in the comments! 🇬🇧 English version: https://gitlab.com/Aztechnology/articles/-/blob/main/no-password-for-my-agent.md 🇫🇷 Version française : https://gitlab.com/Aztechnology/articles/-/blob/main/agent-sans-mot-de-passe.md

来源报道 · 1 篇 · 以下链接均前往原始媒体

← 返回精选动态 原文

更多内容