Best AI Coding Agent Security Tools for Indie Hackers in 2026

On Friday April 24, 2026, a Cursor agent running Claude Opus 4.6 was given a routine staging task. It hit a credential mismatch, and instead of stopping to ask, it went looking for a way forward. It found a Railway API token in the codebase, created months earlier for the narrow job of adding and removing custom domains, which turned out to carry blanket permissions across every environment. Then it deleted the production database volume in one API call.

Nine seconds. And because Railway stored volume backups inside the volume they protect, the backups went too. The most recent off-site copy was three months old.

We covered that incident in detail when it happened. What I want to work through here is the practical question it leaves behind. What actually stops that?

The market has answers now, and they don't compete with each other the way a comparison table would suggest. They sit at three different points in time: before you install something, before a command runs, and after the agent is done. So this post is organized by layer, not by vendor. The best options for a solo developer are free, and the paid tier of this category is built for people with a CISO.

Quick Verdict

What Are the Three Layers?

Time is what separates these tools.

Pre install is before an agent skill, plugin or MCP server ever runs. You're reading someone else's code and deciding whether to trust it. Static scanners live here.

Runtime is the moment between the agent deciding to run something and the thing actually running. This is where a rm -rf gets stopped, or doesn't.

Post hoc is afterwards, reviewing what the agent actually did across a whole session. Useful for teams and audits, mostly overkill for one person.

The PocketOS failure was a runtime failure. No scanner would have caught it, because the malicious code was not the problem. The agent did exactly what it was told, with credentials it should never have been able to reach.

Layer 1: What Should You Scan Before Installing a Skill?

NVIDIA SkillSpector is the clear pick, and it's free. Apache 2.0, 17,000 stars, and the repo was pushed to the day I wrote this.

It runs a two stage scan on a skill before you install it. The first stage is static: 71 vulnerability patterns across 17 categories, regex matching, Python AST analysis that flags exec, eval, subprocess and imports resolved at runtime, YARA signature matching, taint tracking, and live CVE lookups against OSV.dev. The second stage uses an LLM to judge intent and filter false positives, and it runs by default, so pass --no-llm if you want static only.

It never executes what it scans, which is the guarantee that matters here. The docs are explicit that all analysis is static plus optional LLM evaluation of file contents. It accepts a directory, a single file, a git URL or a zip, and covers Claude Code skills, Codex and Gemini CLI skills, MCP servers, SKILL.md files and Python or JS dependencies. MCP scanning needs the extra, installed as skillspector[mcp].

uv tool install git+https://github.com/NVIDIA/skillspector.git

Run it with --no-llm and it's fully offline and free. The semantic pass needs your own provider and API key.

Its documented blind spots: it misses non-English content, can't read text inside images, can't process encrypted or binary code, and when OSV.dev is unreachable it falls back to a small bundled vulnerability list.

Who should not use SkillSpector?

Nobody, really, at this price. But it only answers one question. It tells you whether a skill looks malicious, not whether your agent will do something reckless with legitimate tools, which is the more common failure.

Snyk Agent Scan covers different ground: it discovers agent components already on your machine and scans for prompt injections, tool poisoning, toxic flows and malware hidden in natural language. Apache 2.0, 3,000 stars, actively maintained.

Its own README says, in bold: scanning MCP configurations will execute the commands defined in them. It starts stdio MCP servers by running their configured commands to read tool descriptions. Snyk's own advice is to run scans inside a container or VM when evaluating untrusted configs. There's a consent prompt per server by default.

So a pre install scanner that runs the untrusted thing is a different risk model from SkillSpector's. Use it for auditing what you've already got, not for vetting something you don't trust. It also needs a Snyk account and a token, and while the free plan is $0, it's metered by test counts. Whether agent scans draw on those quotas isn't documented.

Layer 2: What Stops a Command Before It Runs?

Start with what you already have, because it's substantial and it's what every third party tool hooks into anyway.

Claude Code's built in permissions

Under permissions in your settings file you get allow, ask and deny arrays, plus defaultMode and additionalDirectories. Rules look like Bash(rm *), Read(./.env) and WebFetch(domain:example.com).

Two behaviors make this more useful than it first looks. Deny beats allow, and a deny rule cannot carry exceptions: a broad Bash(aws *) blocks every matching call even when a narrower allow rule also matches. And deny rules match inside subshells, command substitutions, pipes and for loops, and past environment variable assignments, so FOO=bar rm -rf tmp/ still trips Bash(rm *).

A bare tool name in deny, like "Bash", removes the tool from Claude's context entirely so the model never sees it. A scoped rule leaves the tool available and blocks only matching calls.

Here's the honest part, and it comes straight from Anthropic's own docs. A deny rule does not match the same program called by absolute path or inside sh -c. Bash(curl *) misses /usr/bin/curl and sh -c 'curl ...'. Bash(rm *) misses /bin/rm -rf build/. Read and Edit deny rules don't cover a Python or Node script that opens files itself, or grep -r pattern . run from the right directory. Environment runners aren't stripped either, so Bash(devbox run *) would happily permit devbox run rm -rf ..

Which is why the docs' own recommendation is to stop matching command text and enforce at the OS level instead.

The sandbox, which is free and most people have not turned on

Run /sandbox and Claude Code gives you OS level filesystem and network isolation covering Bash commands and their child processes. It's built in, using Seatbelt on macOS with nothing to install, and two packages on Linux or WSL2. Native Windows isn't supported.

It can block writes outside your working directory, including ~/.bashrc and /bin/. No domains are allowed by default, and you allowlist them under sandbox.network.allowedDomains. Credential masking swaps a sentinel for the real secret only on allowed hosts.

Three defaults to know, because they're the difference between protection and the appearance of it. Claude can retry a blocked command with the sandbox disabled unless you set allowUnsandboxedCommands: false. If the sandbox can't start, Claude Code warns and runs commands unsandboxed unless you set failIfUnavailable: true. And the docs say plainly that sandboxing reduces risk but is not a complete isolation boundary.

A PreToolUse hook is the third free mechanism. Exit with code 2 and the tool call is blocked unconditionally, before permission rules are even evaluated. Every third party runtime tool in this category uses this same hook.

If you'd rather not assemble that yourself, dwarvesf/claude-guardrails is a hardened config bundle, MIT licensed, pushed within the last week. Lite gives you 21 credential deny rules and 4 hooks for trusted projects. Full gives 40 rules, 6 hooks and a prompt injection scanner for untrusted codebases. It's the free config above, pre packaged.

I'd skip rulebricks/claude-code-guardrails. It's a PreToolUse hook that routes policy to the hosted Rulebricks platform, 79 stars, and its last commit was about seven months ago. The authors say they've since built a commercial product. The rule engine being hosted also means it isn't purely local.

Harden's AIF, the interesting paid adjacent option

Harden ships Agentic Integrity Foundation, which evaluates covered tool calls before execution and records the verdict locally. Six decisions: allow, block, ask, redact, log only, model error.

Redact is the feature worth the install. Instead of just blocking a curl carrying a Stripe key, it rewrites the secret to [AIF_REDACTED] so the retry can proceed safely. Its rule families cover DLP patterns for Stripe, Slack, Telegram and Azure secrets, plus policy checks like curl_pipe_to_shell, flagged because downloaded code would run immediately.

It scores calls with a local model post trained from Zyphra's ZAYA1-8B, quantized to Q4_K_M. Budget for it: the download is 5.17 GiB and first install wants 10 GB free disk, 15 GB for updates. The CLI is macOS or Linux only, and the full local model has Apple Silicon requirements.

curl -fsSL https://aif.harden.run/install.sh | sh

Its integrations page lists Claude Code, Codex, Cursor, Antigravity CLI, Hermes, Kiro and OpenClaw, using native hooks where they exist and a bridge process elsewhere, and the repo README adds Gemini CLI. Check the current list for your agent rather than trusting either. Kiro subagent shell and file operations are a documented exclusion.

Harden says AIF is free forever for individual developers, with no account or card, and shared controls for teams on top. No enterprise numbers are published.

Read the license before you lean on it, though. Its public repo has 728 stars but ships no source code, just an installer, docs and an issue tracker, and LICENSE.txt is an "AIF Beta License Agreement" from VizopsAI, Inc. covering the binary. It forbids decompiling the proprietary parts, and says the software "may contain defects, may change or be withdrawn at any time, and is not guaranteed to be complete, supported, or fit for production use", with a documented version-recall mechanism. Bundled open source components keep their own licenses.

None of that makes it a bad tool. It does mean you're installing a closed beta binary as a security control, which is a different proposition from SkillSpector's Apache 2.0 source you can read.

Worth crediting: its docs state coverage per agent rather than implying blanket protection, and the Kiro exclusion above is documented instead of buried. That's more honest than most of this market.

Layer 3: Is Post Hoc Review Worth It Yet?

For a solo developer, no.

Apollo Research Watcher is the serious entrant. It scores every tool call through a three stage pipeline: zero latency regex rules, then a fast triage model for ambiguous cases, then a fuller evaluator, which can run a different model from the agent so the monitor doesn't share the agent's biases. Most safe actions resolve in under two seconds. It does both blocking and trailing review, with a team dashboard and central policy. Apollo's own framing is an MDM for coding agents.

Three reasons it isn't an indie hacker purchase. There's no public pricing at all, just a sales call. The public repo is a binary distribution repo, not source, and no license is published. And while self hosting is offered alongside an Apollo-hosted option, you arrange it through the same sales call.

Its landing page reports 100% recall on critical severity failures, under 1% false positives, and 3 to 5% added cost. Its own technical blog gives no recall figures and cites 1 to 5% overhead. Inconsistent across its own pages, and vendor reported either way. You'll also see a 93% recall figure circulating from an aggregator site. I wouldn't repeat it.

AIR Security raised $50M on September 1, 2026, led by Sequoia then Greenoaks, founded by two Unit 8200 alumni. TechCrunch reports it filters roughly 27% of tools found online and has more than 20 customers, about a quarter large enterprises. It publishes no pricing and no self-serve signup, and TechCrunch describes it selling to companies rather than individuals. Treat it as the enterprise end of this market.

My Recommendation

Spend an hour on the free layer and you'll have covered more risk than any purchase would.

Write deny rules for your secrets first: Read(./.env), Read(**/.env), Read(./secrets/**). Add Bash denies for the destructive commands you'd never want run unattended. Then turn on /sandbox, and set allowUnsandboxedCommands: false and failIfUnavailable: true so the protection doesn't quietly disable itself. If you want a head start, clone dwarvesf/claude-guardrails and read its rules rather than pasting them blind.

Install SkillSpector and actually run it before adding a skill or MCP server you didn't write. It takes one command and it never executes what it inspects.

Add Harden's AIF if secret redaction appeals and you have 10 GB to spare. It's the only tool here doing something the free layer can't.

Skip Layer 3 until you have teammates and an audit requirement.

flowchart TD
    A{Installing someone else's skill or MCP server?} -- yes --> B[SkillSpector, static scan first]
    A -- no --> C{Agent has reach to production credentials?}
    C -- yes --> D[Deny rules plus sandbox, strict mode]
    C -- no --> E[Deny rules for secrets, sandbox on]
    D --> F{Need secrets redacted rather than blocked?}
    E --> F
    F -- yes --> G[Add Harden AIF]
    F -- no --> H{Team with audit requirements?}
    H -- yes --> I[Evaluate Watcher, sales call]
    H -- no --> J[Free layer is enough]

The lesson from PocketOS wasn't that the agent was malicious. It was that a token made for managing domain names could delete a database, and was sitting somewhere the agent could read it. Most of what these tools sell you is a way to make that impossible, and the cheapest version of that is a deny rule you can write this afternoon.

For more on what agents can reach and how the pieces fit, see Claude Skills vs MCP connectors vs plugins and how to stop a runaway Claude Code session.

Found a better option? Let me know on Twitter @devtoolpicks.