Local Secrets MCP

Note: This is a quick idea sketch that might be generated into an actual implementation in this repository or not. This may be a replication of a better system. Or it may not!

The Problem

Many users of AI tools for development, potentially the quiet but large majority, prefer to use cloud models via API.

Cloud models incur costs but are usually far more reliable and powerful than models that can be run locally (for casual end users at least).

Cloud models carry risks, however - with user data being sent back and forth to the server via API.

Many AI and MCP users are understandably reticent about exposing these tools to secrets like environment variables. Many tools support by default security postures like preventing models from being able to access files like .env. These are reasonable best practices. But miss out on the potential for MCP to assist with tasks like secret retrieval that could otherwise streamline workflows.

---

The Idea: A Hybrid Model

A secret retrieval MCP does not need to be a large language model with powerful or SOTA reasoning.

It simply needs to be a model with agentic and tool calling capabilities that can quickly and reliably do things like interact with secret stores.

By filtering on Ollama for tools we can find several great candidates with modest sizes which could run on everything from embedded devices to workstations:

• Mistral-3: 3B to 14B
• Qwen 3 - 0.6B - 235B
• Llama 3.2 (1B, 3B)

Etc.

Imagine an implementation like this for a tool that the user does not wish to expose directly to a cloud model. Let's take One Password as an example for how this microservice stack could be implemented:

• Local model runs in background in Ollama API
• Local model is provided with access to secrets vault via API or file level integration

Sample Tool Calling

Claude Code acts as orchestrator.

Local secrets MCP supports two main tools:

• Secret storage (save new secret)
• Secret retrieval (provide new secret)

Secret storage negates much of the security benefit as the cloud API carries/processes a secret.

For secret retrieval:

• Tool call to local model: "The user needs to populate their OpenAI key in this repository. Here's the path {path}. I am a sandboxed agent and cannot access the environment variable store in the repository. Please retrieve the variable from the secrets store you have access to and write it to the environment variable file. Report completion."

The cloud model delegates this task to the local only subagent. For security, the local agent can be restricted from network access (i.e., airgapped).

Essential note:

The security of the workflow depends upon the main model's adherence to its sandboxing.

Secret Retrieval Flow

flowchart TD
    subgraph Cloud["Cloud Environment"]
        A[User Request] --> B[Cloud Model / Orchestrator]
        B --> C{Secret Needed?}
    end

    C -->|Yes| D[MCP Tool Call]

    subgraph Local["Local Environment (Airgapped)"]
        D --> E[Local Secrets MCP]
        E --> F[Local LLM\ne.g. Mistral 3B / Qwen]
        F --> G[Secrets Store\ne.g. 1Password / Vault]
        G --> H[Retrieve Secret]
        H --> I[Write to Target\ne.g. .env file]
        I --> J[Report Completion]
    end

    J --> K[Acknowledge to Orchestrator]
    K --> B
    B --> L[Continue Task\nwithout seeing secret]

    style Cloud fill:#ffe6e6,stroke:#cc0000
    style Local fill:#e6ffe6,stroke:#00cc00

---

Secret Storage

A more complex but potentially viable architecture for secret storage:

• Secrets are stored in a cloud vault with end-to-end encryption.
• Local model holds a decryption key.
• Cloud model passes through the encrypted secret only.
• Local model decrypts and then stores locally.
• Cloud / internet-exposed model only serves as a passthrough and never handles decrypted data.

Secret Storage Flow

flowchart TD
    subgraph User["User Input"]
        A[User provides new secret\nto Cloud Model]
    end

    subgraph Cloud["Cloud Environment"]
        A --> B[Cloud Model / Orchestrator]
        B --> C[Encrypt Secret\nwith Public Key]
        C --> D[Encrypted Payload]
    end

    D --> E[MCP Tool Call\nPassthrough Only]

    subgraph Local["Local Environment (Airgapped)"]
        E --> F[Local Secrets MCP]
        F --> G[Local LLM]
        G --> H[Decrypt with\nLocal Private Key]
        H --> I[Secrets Store\ne.g. 1Password / Vault]
        I --> J[Store Decrypted Secret]
        J --> K[Report Completion]
    end

    K --> L[Acknowledge to Orchestrator]
    L --> B
    B --> M[Confirm Storage\nNo plaintext retained]

    style User fill:#e6e6ff,stroke:#0000cc
    style Cloud fill:#ffe6e6,stroke:#cc0000
    style Local fill:#e6ffe6,stroke:#00cc00

---

Potential Improvements & Open Questions

• Authentication handshake: How does the local MCP verify that tool calls are coming from authorized orchestrators? Consider a shared secret or certificate-based auth.
• Audit logging: The local agent should maintain tamper-evident logs of all secret access for compliance/debugging.
• Secret rotation: Could extend to support automatic secret rotation workflows triggered by the orchestrator.
• Fallback behavior: What happens if the local model is unavailable? Should the orchestrator fail gracefully or queue the request?
• Multi-secret retrieval: Batch operations for initializing new projects with multiple secrets.
• Secret naming conventions: Standardized schema for how orchestrators reference secrets (e.g., provider/service/key hierarchy).
• Encryption key management: For storage flow, where/how is the keypair generated and the public key distributed to cloud clients?
• Rate limiting: Prevent runaway tool calls from exhausting secret store API limits.

---

TL;DR / Summary

• Use a local agentic model and connect to secret storage. Run this and then encapsulate the environment without network access. Stack: Ollama + small model with tooling.
• Expose MCP tool definition and integrate this with an MCP manager that the main agent has access to. This could be direct or via an intermediary/proxy/aggregator. Intermediary provides another potential exposure surface, however, and would require its own security consideration.
• Offline model is tasked with secret retrieval.