On a related note, I'm not sure when it became "ok" to leave production credentials scattered across your system in configuration files. So many MCP server examples encourage this pattern, and inevitably, it's going to cause trouble at some point.
That said, given https://github.com/runsecret/rsec#aws-secrets-manager presumably in order to keep AWS credentials off disk one would then have to have this?
"vantage-mcp-server": {
"command": "/opt/homebrew/bin/aws-vault",
"args": [
"exec", "--region=us-east-1", "my-awesome-profile",
"--", "/opt/homebrew/bin/rsec", "run",
"--", "/opt/homebrew/bin/vantage-mcp-server"
],
"env": {"VANTAGE_BEARER_TOKEN": "rsec://012345678912/sm.aws/VantageBearerToken?region=us-east-1"}
}
I agree RunSecret adds a level of indirection at this stage that op doesn’t (if you are using 1pass). This is something I plan to polish up once more vaults are supported. You’ve given me some ideas on how to do that here.
And thanks for the advice on doing a Show HN, planning to do so once a few more rough edges are smoothed out.
That being said, an easier-to-distribute user experience would be to leverage short-lived OAuth tokens that LLM clients such as Claude or Goose ultimately manage for the user. We’re exploring these avenues as we develop the server.
If you really really really need to use static creds on your laptop, use aws-vault to export them, or ephemeral creds generated from them, into your environment.