智能体
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