Five Attacks, Five Verdicts: Inside the NemoClaw Action-Governance Recipe

Last year the interesting question about AI agents was what they could do. This year it's what they're allowed to do. And who, exactly, is deciding. This is a case study of one concrete answer: the Shrike action-governance recipe that cleared NVIDIA maintainer security review and merged into nemoclaw-community in August 2026: what it does, what the review demanded before it could land, and the five live attack cases it proves itself against on every install.

The gap the recipe fills

NemoClaw runs OpenClaw agents inside OpenShell, a sandbox that decides where an agent can act: which filesystem paths, which network destinations, which syscalls. That containment is real and necessary. And it is silent on a different question. An agent legitimately inside its sandbox, with legitimate access to a database, can still issue a destructive query. The sandbox has no opinion; every boundary was respected.

The recipe's one-line thesis, straight from its README: the sandbox is the cage, Shrike is the judgment. OpenShell contains where an agent can act. Shrike governs what a specific action is, with the decision made server-side against the operator's policy, at a point the agent's reasoning can't route around.

The architecture, in one pass

The recipe installs a before_tool_call plugin into the sandbox: the same supported interception contract NemoClaw's own secret-scanner uses. Every tool call flows:

• The plugin classifies the action: SQL, shell command, file write, web search, or general.
• The action content goes over TLS to Shrike's enforce plane, where the 9-layer policy pipeline evaluates it.
• The verdict comes back and maps to an OpenClaw decision: allow and warn proceed; block and require_approval stop the call before it executes.
• No credential configured? The plugin can't get a verdict, so it blocks: fail-closed by default, and nothing is transmitted without a key.

Five attacks, five verdicts

The recipe doesn't ask you to trust that description. It ships verify.sh, which drives five canary cases through the live installed plugin (real agent, real sandbox, real enforce plane) and exits successfully only when every verdict matches:

Note what the benign case is doing there: a governance layer that blocks everything is easy to build and useless to run. The allowed case is as much a part of the proof as the four denials. The work continues.

What the maintainer review actually demanded

The part of this story most useful to anyone evaluating agent security vendors is not the merge. It's the review. NVIDIA's maintainers held the contribution until it demonstrated the things enterprise security teams should demand of any in-path integration:

• Credential custody outside the workload. The Shrike API key is declared through an OpenShell provider profile and held gateway-side: raw credentials never enter the sandbox the agent runs in.
• Scoped egress, enforced. The provider profile scopes the plugin's network access to the two enforce endpoints on api.shrikesecurity.com, with enforcement on, not an open outbound channel with a polite comment.
• An explicit data-sharing boundary. The README states precisely what leaves the sandbox (the action content under evaluation), what comes back (a verdict and a short reason), and what never transmits. It also tells you when not to enable the recipe: workloads whose tool-call content must never leave the sandbox.
• Real lifecycle wiring. Onboard, install, verify, status, teardown scripts: an integration you can operate, not a config fragment you can admire.
• Live allowed/denied validation. The five cases above, run against the installed plugin, not a mock.
• Honest classification. The recipe is labeled community-maintained, contributed by Shrike Security, not covered by an NVIDIA support agreement. The provenance is in the SPDX header of every file.

That checklist is worth keeping even if you never touch this recipe. It's a working definition of what "production-grade" means for anything that sits in an agent's execution path.

The limit, printed

The README says something vendors rarely say about their own integration, and we want it read rather than buried: the plugin runs inside the sandbox, alongside the agent. That makes it in-sandbox defense-in-depth, not an independent security boundary. A fully compromised sandbox could tamper with it. The controls that hold even then are the ones outside: the OpenShell egress policy and the credential provider. Stronger placements of the enforcement boundary (server-plane, and hardware-isolated under Enterprise engagements that require it) exist for workloads that need them. Security claims that don't state their boundary are marketing; this one states it.

Why this composes instead of competes

Nothing in this integration argues the sandbox is insufficient at its own job. It argues the two layers answer different questions (where can the agent operate versus what is this agent allowed to do right now) and demonstrates them running together: one agent, two independent controls, five verdicts. That's the layered model we map out in the agent security stack, running as working code in a public repository.

Run it yourself

The recipe is Apache-2.0, with the plugin, provider profiles, and lifecycle scripts included.verify.sh will show you the five verdicts on your own install. A free Shrike tier (1,000 scans/month) is enough to run it. The agent decides what it wants to do; your policy (declared by you, enforced by Shrike) decides whether it executes. The design walkthrough is in the original recipe post, and the broader map in what is action governance.