Securing NemoClaw Agents with Shrike
NemoClaw makes it straightforward to run agents — Hermes, LangChain Deep Agents, OpenClaw — inside a managed runtime with inference handled for you. What it doesn't decide for you is whether any given action an agent takes should actually happen.
That's the gap we kept running into. Once an agent is live, it's calling tools, reaching MCP servers, and moving data around. The runtime launches and supervises it, but there's usually nothing sitting between "the model decided to do X" and X executing. For a demo that's fine. For anything touching a database, a filesystem, or a customer's data, it isn't.
So we built a recipe that adds the missing layer. It wires Shrike, a runtime governance layer for AI agents, into NemoClaw as a plugin — and it's now merged into NVIDIA's nemoclaw-community after going through the maintainers' review.
What it governs
The recipe puts a policy checkpoint at the moment an action is about to run — not in a log you read afterward:
- Tool and MCP calls, before they execute. The call is evaluated against policy first; only then does it run.
- Prompt injection. Instructions smuggled in through retrieved content or a tool result get caught before they steer the agent.
- Secrets and PII on the way out. An API key or a customer record leaving in a tool argument or a response is flagged, not shipped.
- A verdict, not just a score — allow, warn, require-approval, or block. A consequential action can pause for a human instead of failing silently.
It works with the agents you're already running under NemoClaw. There's no change to the agent's own code — the plugin sits in the path the framework already controls.
Why the checkpoint sits outside the agent
The evaluation runs server-side, outside the agent's context window, its tool calls, and its reasoning chain. The agent can request an action; it can't approve its own. That independence is the whole point — we've written before about why an agent's own instructions aren't security, and it's why the recipe enforces at the boundary rather than trusting the agent to behave.
In practice that means a research agent can't reason its way into a production deployment, a compromised tool result can't quietly redirect where data goes, and a multi-turn attack that looks harmless one prompt at a time still gets caught when the pattern adds up.
Trying it
The recipe ships with the plugin, the providers, and a README that walks through wiring it into your agents.yaml. There's a free tier — 1,000 scans a month — so you can point it at a real agent and see what it flags before committing to anything.
If you're running agents on NemoClaw and want a second opinion on what they're about to do, that's exactly what this is for. The docs cover policy setup, and pricing has the tier breakdown if you outgrow the free one.
We'd genuinely like feedback on where it's too strict or too quiet — the recipe is public, and so is the issue tracker it lives next to.