Free Open Source Secure AI Agent | Self-Hosted LLM Agent for macOS Linux WSL2 | MIT Licensed | No API Keys

I build a small open-source device agent. Before I designed it, I sat down and read the actual incident reports from the last two years — not vendor blog posts, the forensics.
Four things kept showing up. None of them is prompt injection. Here they are, then what I built, then what I still haven’t fixed.

1. Someone steals your API key and runs their AI on your bill
There’s a name for this now: LLMjacking. Sysdig’s threat research team coined it in 2024.
How it works: attacker gets your cloud credentials, uses them to hit hosted LLM services, and resells that access to other people. You never lose data. You just get an invoice.
The number that made me sit up: a stolen key sells for about $30 on underground markets, and can generate over $46,000 a day in inference charges on Claude 2.x through Bedrock. On Claude 3 Opus, later reports put it past $100,000 a day.
It’s not niche anymore. Between December 2025 and January 2026, researchers logged 35,000+ attack sessions against exposed AI infrastructure — roughly 970 a day — feeding a marketplace that resells access across 30+ providers.
The nasty part: this attack has exactly one symptom, and it’s your billing dashboard. Attackers actively disable invocation logging to keep it that way.
Source: https://www.sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack

2. Malware started hunting specifically for AI tool credentials
In August 2025, poisoned versions of the Nx build system hit npm. The attack got called s1ngularity.
It scanned machines for GitHub tokens, SSH keys, npm keys, and API keys, then pushed them to public repos under the victim’s own account.
The damage, per GitGuardian’s analysis:
• 2,349 credentials stolen from 1,079 developer machines
• Over 1,100 of them still valid when researchers checked
• Attackers used them to flip 10,767 private repos public, exposing 82,901 more secrets
Here’s the part that changed my thinking. The malware looked for AI CLI tools already installed on the machine and used them to do the searching. It found Claude, Gemini, and Amazon Q, ran them with permission-bypassing flags like --yolo and --trust-all-tools, and had them scan the filesystem and list sensitive files.
To be clear, because people flatten this: the AI tools were not the attacker. They were the victim’s own software, hijacked by a bad dependency. Nobody’s product stole anything.
But that’s the lesson. An agent with broad filesystem access and a “trust everything” mode is a lever sitting on your machine, waiting for someone to pull it.
Source: https://blog.gitguardian.com/the-nx-s1ngularity-attack-inside-the-credential-leak/

3. We leak keys faster every year, and we never rotate them
GitGuardian scanned public GitHub for all of 2025 and found 28.6 million new hardcoded secrets — up 34% in a year, their biggest jump ever.
Two findings I can’t get out of my head:
24,008 secrets were sitting in MCP config files. Why? Because popular MCP setup guides tell you to put API keys straight into config files and command-line arguments. When the official quickstart says hardcode it, hardcoding is the default, not the mistake.
64% of keys that leaked in 2022 were still working in 2026. Rotation isn’t hard to do. People just don’t.
There’s also a related finding from a different breach: on compromised machines, each live secret showed up in an average of eight different places — .env files, shell history, IDE configs, cached tokens, build artifacts. You don’t have one copy of your key. You have eight, and you know about two.
(Caveat: that’s a vendor’s own scan data. Directionally it matches everything else.)
Source: https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/

4. Nobody stole anything and you still lost thousands
The other half of “where did my API budget go” has no attacker at all. Agents get stuck in loops.
The structural reason is simple. An agent re-sends its whole context every step. By step 20, you’ve paid for the same context 20 times. Agent workloads run roughly 50x the token consumption of normal chat on the same task.
Then it gets worse:
• Retry storms — a rate-limit response comes back looking like success, the wrapper script reads it as failure, retries, gets rate-limited again
• Hook recursion — tool call fires a hook, hook fires a tool call, no depth limit
• Refactor loops — agent keeps trying to fix a file bigger than its own output limit
A Stanford / Microsoft Research study across eight frontier models found runs on the same task varying by up to 30x in total token cost. And models predict their own spend only weakly.
The agent cannot tell that it’s stuck. From inside the loop, nothing has errored.
Uber reportedly burned its entire 2026 AI coding budget in about four months and capped engineers at $1,500/month.
Billing alerts don’t save you here. They arrive after.

So here’s what I built
mona-agent. MIT licensed, free, Node 20+, macOS / Linux / WSL2, one dependency.
The whole design comes down to one decision: no LLM provider keys on the device. Not encrypted ones. None.
The device runs a small daemon. It connects to a control plane, receives commands, runs tools locally in a sandbox, and streams results back. The thinking happens where the keys live. The device is a smart terminal, not a brain.
The only thing stored locally is one control-plane token, in ~/.mona-agent/credentials.json, mode 0600. Revoke it from the dashboard and that machine is cut off. No rotating keys across three providers. No wondering which of your eight .env copies is still live.
Against the four problems above:

|Stolen key → $46k/day of inference -> There’s no provider key on the device to steal. An attacker gets one revocable token. |
|Malware grepping for AI credentials -> It finds a single scoped token. Nothing else is there. |
|Same key in eight places -> One credential, one file, one known path, one revoke button. |
|Malware running your agent with `--trust-all-tools`-> There’s no `--yolo`. Shell runs off an allowlist; `rm -rf /`, `mkfs` and fork bombs are blocked outright; files are sandboxed; net is HTTP(S) only.|

Four tools, on purpose: sysinfo (read-only), shell (allowlisted), files (sandboxed), net (HTTP/S only).
There’s also a terminal dashboard in pure ANSI — live CPU and memory, streaming task output, color-coded activity log, no extra dependencies. Every command shows up in that log as it runs. That’s not a security control, but it’s the difference between spotting a runaway loop at minute two and spotting it on next month’s invoice.

One command:

curl -fsSL https://agent.mona.expert/install.sh | bash

Easy to install & free for ever.

Read the script before you pipe it to bash. I’d want you to.
Repo: https://github.com/MONAEXPERT/agent

Disclosure
I’m the developer. The agent is genuinely MIT and works with any control plane. There’s a hosted one at agent.mona.expert with a free tier, and that’s what eventually pays for this. Not pretending otherwise.
What I want from this post isn’t installs. It’s someone tearing the shell allowlist apart. If you can get past MONA_ALLOW_CMDS with something I haven’t blocked, open an issue — or just post it in the comments and I’ll take the hit.