How Money ex Machina keeps Secrets

Designing for Trust, Not Just Security

At Money ex Machina, the systems being built are not just about functionality; they are designed to build trust. That means thinking deeply not just about what gets built, but how it's built. One of the most fundamental parts of any system is how it handles secrets.

Too often, secret management is either too lax (leaky .env files, hard-coded API keys or DB passwords in code) or too heavy (cloud-based vaults, multi-team infrastructure). This project follows a middle path: one that is minimal, inspectable, and secure—without compromising on control or composability.

A good secrets system should enable confidence. Not just "nobody will steal this key," but "I understand how this works and can reason about its boundaries."

The approach to secrets follows the same design principles used throughout Money ex Machina:

• Explicit: Nothing ambient. Every secret is requested with intent.
• Composable: Can be used in scripts, shells, Python, CI pipelines.
• Auditable: Access patterns and changes can be reviewed and tracked.
• Scoped: Only the right machines and users have the right access.
• Minimal: No third-party infrastructure, no black boxes.

And, crucially: Secure by design, not by obscurity. The policies and structures are public and inspectable. That is not a vulnerability, but a feature. If your security requires secrecy, it is already broken.

The System in Practice

This project uses a hybrid approach:

• gopass manages encrypted secrets backed by GPG keys
• Each secret is stored in a git-tracked repo under ~/.mxm-secrets-store
• Access is governed via .gpg-id files scoped per subfolder
• Read-only secrets are decrypted on runtime machines (mxm@monolith, mxm@wildling)
• Write access is restricted to the dev box (mxm@bridge)
• Fallback support for env vars allows rapid prototyping and CI flexibility
• The mxm-secrets Python package wraps it all in a clear, pluggable API

from mxm_secrets import get_secret
api_key = get_secret("prod/smtp-password")

Or from the command line:

poetry run mxm-secrets get mxm/dev/sample-secret

Why Not .env Files? Why Not Vault?

.env files tend to leak. They are prone to accidental check-ins, unclear scoping, and runtime ambiguity. They are fine for quick hacks. Not for trust.

Vault comes with significant operational complexity. It may be integrated later as part of a pluggable backend system—but only when needed.

This secrets system is:

• Easy to inspect
• Easy to audit
• Easy to reason about
• Hard to get wrong

That's a rare mix.

What This Enables

• Confidence in production deploys: it is clear what secrets are where.
• Security that is inspectable and shared, not hidden or magical.
• Collaboration across machines and contributors without trust leakage.
• Extensibility via an open mxm-secrets Python interface.

This is a tool built for daily use.

Learn More

The code is open source:

• GitHub: github.com/moneyexmachina/mxm-secrets

And the package is minimal:

• Pure Python, no dependencies
• CLI with Click
• Compatible with gopass, env, and more to come

If you're building systems where you want to remain in charge, this might be a good place to start.

In Closing: Building with Agency

MxM is built from components that are small, understandable, and under control.

Secrets aren't just about hiding things. They're about who gets to know. And how that decision is made matters. This system is designed so that decision is made clearly, inspectably, and with intent.

Thank you for thinking with me.

References

• mxm-secrets on GitHub – Minimalist secrets interface built for MXM
• gopass – Command-line password manager based on Git and GPG