Vault-backed MCP pattern keeps AI agents from ever seeing credentials

The problem with credentials in prompts

When teams wire autonomous AI agents into core infrastructure such as GitLab, MariaDB, OpenProject or Portainer, the reflex is to hand the model an API token or database password via its system prompt or environment rules so it can get work done. A post on dev.to by a longtime sysadmin and architect argues that this reflex is fundamentally unsafe.

The reasoning: an AI agent is a non-deterministic process. It can hallucinate, it can be steered through prompt injection, and its context transcripts may end up persisted in logs. Giving such a process raw credentials, the author contends, does not delegate authority so much as put a breach on the calendar. The question they set out to answer is how an agent can act on internal systems while a single password, personal access token or SSH key is never exposed to the model.

Inverting secret ownership

The answer described in the post is to move all secret handling out of the agent and into a Model Context Protocol (MCP) server backed by HashiCorp Vault. Ownership is inverted: instead of the agent holding credentials to reach backends, a trusted intermediary holds them, and the agent only ever references resources by short identifiers.

The architecture rests on four components:

• Logical handles only. The agent manipulates a resource_id and nothing else. It never sees, holds or transmits a password or token.
• An isolated MCP runtime. The MCP container authenticates to Vault via AppRole, fetches credentials into memory, opens sessions to the backend systems, and returns only the operational result to the agent.
• Scoped action policies. Tools are restricted at the Vault record level through an actions allowlist, enforced with the setting MCP_ACTION_POLICY=enforce. A tool can exist inside the container and still be denied by Vault if it is not authorized for that specific resource.
• Human-in-the-loop control. Any mutating action requires an explicit confirm: true parameter, enforced by host rules rather than left to the model's own judgment.

The net effect, per the author, is that a compromised, injected or merely confused agent has nothing valuable to steal: its context contains resource IDs and operation results, not secrets.

The remaining gap and the road to V2

The pattern is not presented as finished. Its current weakness is that the MCP container authenticates with a container-wide AppRole, which leaves a classic confused-deputy flaw: the agent's actions are attributed to the container's identity rather than to the originating user. A planned second version replaces this with LDAP identity propagated down to Vault ACLs, so each session carries its own authorization.

The full technical blueprint, including Mermaid sequence flows, Vault KV schemas and sample MCP payloads, has been published by the author on GitLab in both English and French. The post closes by inviting other engineers to compare notes on secret isolation, proxy layers versus native MCP servers, and mechanisms for enforcing human validation before an agent mutates state.

Why it matters

As agents move from chat demos into CI pipelines, databases and project management tooling, credential hygiene becomes an infrastructure problem rather than a prompt-engineering nicety. This pattern offers a concrete, reproducible answer: secrets stay in Vault, the agent stays ignorant of them, and authorization is enforced at the resource level with a human gate on state changes. It also signals where MCP is heading, from a way to expose tools toward a way to broker trust between models and infrastructure, and it names the unresolved issue, identity propagation, that any team adopting this design will hit next.