Financial MCP Server Launched With Inline Secrets Or Unattended Write Flags
This detects when a financial trading/transfer server (used by AI agents to move money) is launched in a way that either leaks its credentials or removes the human approval step before payments go through. It does not detect prompt injection or an actual hack; it flags the risky launch configuration that would make one dangerous.
How the attack works
An AI agent or a shell it controls starts the @dfm-fi/agent MCP server, which exposes live financial operations like deposits, redemptions, and fund launches as callable tools. The detection looks at the exact command used to start it. It fires if that command line contains a real signing key, mnemonic, or API token in plain text, or if it combines a money-moving action with a flag like --force, --auto-approve, --non-interactive, or --yolo that skips human confirmation. A normal launch that reads secrets from environment variables and keeps confirmation on does not trigger anything.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7b3d1c2e-9a54-4f61-b8de-0c2a5f4e17d9
- Severity
- Medium
Why it matters
A key typed into a command line is visible to anyone who can run ps, read /proc, or check shell history, so it can be stolen and used to move funds. A financial write server running without a confirmation gate lets any compromised or manipulated agent execute deposits, redemptions, or fund actions with nothing to stop it.
What you can do
- →Never pass API keys, private keys, or mnemonics as command-line arguments; use environment variables or a secrets manager instead.
- →Keep confirmation/approval flags enabled for financial write operations; do not run these servers with --force, --auto-approve, --non-interactive, or similar flags in production.
- →Rotate any credential that has appeared in a command line, process list, or shell history, since it should be treated as exposed.
- →Review deployment and CI scripts for financial MCP servers and replace inline secrets with secret mounts or short-lived tokens fetched at runtime.
Known benign look-alikes
- An operator or deployment script legitimately starting the DFM MCP server in production and passing a real API key or signer key on the command line. This is a true positive of credential-in-argv exposure even when the launch itself is authorised, and should be remediated by moving the value to an environment variable (env-var references such as $DFM_PRIVATE_KEY are already suppressed by filter_placeholder).
- Integration or QA harness invoking the server with a funded testnet key literal that does not contain any placeholder token; indistinguishable from a mainnet key on the command line, so it is reported rather than blocked.
- CI pipelines that inline a short-lived access token instead of using a secret mount.
- A file path or unrelated argument that coincidentally contains a financial verb (e.g. a directory named transfer/) together with a --force flag. Requires the exact scoped package name in the same command line, which makes the coincidence unlikely.
- --dry-run and --simulate invocations are deliberately NOT filtered: a literal key in argv is readable via ps and /proc/<pid>/cmdline regardless of whether the transaction executes, and filtering on a self-declared flag would be trivially spoofable.