Your AI agent holds more keys than you think: 14 critical findings from auditing our own deployments

We run four production agent deployments — long-lived processes with wallets, RPC keys and model credentials on disk. Before selling anyone an inspection, we inspected ourselves. Read-only, no network, secrets masked at capture.

Scope: 4,574 files across four deployments. Result: 14 critical findings, 11 high, 9 medium. Every one of them was a key-handling defect, not a prompt-injection trick.

Here is what actually showed up, in the order it would hurt you.

1. The wallet seed phrase was world-readable

A seed phrase file sat at mode 0644 in a home directory. Any local user, any process running as another service account, any backup agent that copies $HOME could read it. The agent itself did not need to be compromised. Nothing did. The file was simply readable.

Same deployment had a private key in a second file with the same permissions. Two criticals, one chmod.

Check: find ~ -maxdepth 4 \( -name "*.key" -o -name "*seed*" -o -name "*mnemonic*" -o -name "*.env" \) -perm /o+r 2>/dev/null

If that prints anything, stop reading and fix it.

2. Credentials inside generated artifacts

An API key appeared verbatim inside a security report the agent had produced and saved to disk — a report about its own configuration. The key had been pasted into a template, the template was written to reports/, and the report was then listed in an index.

This is the failure mode people miss: the output directory is an attack surface. Agents write logs, reports, transcripts and summaries. Every one of those is a potential credential leak with a longer half-life than the original file, because artifacts get copied, committed and shared.

Check: grep your output directory for the first six characters of every key you own.

3. Secrets in argv

A worker process was launched with an API token as a command-line argument. On Linux, /proc/<pid>/cmdline is readable by every user on the box unless you have hardened /proc. The secret was in the process table for the entire lifetime of the service.

Check: ps auxww | grep -i -E "key|token|secret|password" — if you see a value, it is public to the host.

4. MCP and agent configuration as an attack surface

Tool descriptions and MCP server configs are code you did not write, loaded with your privileges. We found literal credentials in config files (again, readable), and one tool description that instructed the model to read a path outside the project. That is a prompt-injection surface with filesystem access attached.

Check: every MCP server entry, every tool description string. Ask: does this text come from someone who could change it after I approved it?

5. Over-scoped RPC and spend authority

A signing service held an RPC endpoint with an admin key, and a wallet whose allowance covered far more than the agent's actual job. The agent could not be tricked into spending — it did not need to be. The scope was the vulnerability.

Check: what is the maximum damage one leaked key from this deployment can do, in dollars, without any further access? If you cannot answer in one sentence, that is the finding.

6. What survives: logs, backups, snapshots

Rotating a key does not remove it from the places it was written. We found live credentials in rotated logs and in a snapshot directory that predated the rotation.

Check: after rotating, grep the old locations. Rotation without a sweep is bookkeeping, not remediation.

---

The 10-minute version

1. find for key-shaped files with group/other read bits.
2. ps auxww for secrets in argv.
3. grep output/report directories for key prefixes.
4. read every MCP config and tool description as if a stranger wrote it.
5. write down the dollar value of the worst key leak you have.
6. rotate, then sweep the old copies.

Why we are telling you instead of selling you a scan

Because the scan is not the product. The product is knowing where the key lives, who can read it, and what happens the moment the agent is compromised — in your deployment, with your topology, not in a generic checklist.

We do this read-only, on material you provide, and we do not touch production. Short report: one surface, 48 hours, no call. Full review: fixed scope, five days, quoted after scope.

Contact and pricing: Custody audit for AI agent deployments

We publish findings in aggregate only: no client names, no paths, no access to anyone's systems. The numbers above are our own house, audited before we asked anyone for money.