PP123: Using Gridctl to Keep MCP Configs From Leaking Secrets

The episode explores the critical problem of secrets and credentials being stored in plain text across developer machines, a practice that has become worse with MCP adoption. William Collins, a Cloud and Automation Engineer and co-host of the Cloud Gambit podcast, describes his frustration with the manual burden of configuring MCP servers—each requiring hand-edited JSON files with hardcoded paths, absolute interpreter paths, and credentials scattered across systems.

The problem is twofold: first, MCP's protocol-only design leaves packaging and operational security to developers; second, the human tendency to prioritize speed over security leads to credentials being stored insecurely. Collins explains that MCP is a protocol for connecting AI applications to external tools and data sources, but it doesn't provide guidance on credential management. This creates a surface for prompt injection attacks and exfiltration if a model has file-reading and fetch capabilities.

GridCTL solves this by providing a single YAML configuration file that generates MCP endpoints while managing secrets securely. The tool uses industry-standard encryption: Argon2ID for key derivation and XChaCha20-Poly1305 for envelope encryption. Secrets are never stored in plain text on disk—only references are kept in configuration files. Variable injection happens at runtime into the process environment, and users can organize secrets into sets and groups for specific environments. The tool also handles the complexity of multiple MCP transports (HTTP, SSH, stdio) and can import OpenAPI specifications to generate MCP tools.

Collins emphasizes that GridCTL is not meant to replace enterprise solutions like HashiCorp Vault; rather, it's designed for developers in rapid prototyping phases who need disposable, repeatable environments. He compares it to ContainerLab in networking—both provide ephemeral, infrastructure-as-code approaches that eliminate state management problems and enable testing from known baselines. The tool follows patterns similar to Terraform, with validate, plan (showing diffs before applying), apply, and destroy phases.

On security practices, Collins underwent OpenSSF best practices certification, a two-month effort that taught him the importance of verifiable security claims and transparent procedures. He emphasizes starting with secure practices early in development rather than relying on post-hoc detection tools like TruffleHog. GridCTL is meant to shift security left by preventing secrets from being leaked in the first place, while TruffleHog detects secrets already exposed. Collins has moved the project toward RC1 release with real-world usage from Fortune 100 companies in segmented labs, and he actively seeks community feedback and contributions.