Red-Teaming NemoClaw Agents Finds the Holes. Governance Holds the Line.

Red-teaming agentic AI has arrived in the NVIDIA ecosystem: tooling now exists to probe NemoClaw agents with adversarial inputs and see what breaks. That is genuinely good news, and if you run NemoClaw agents you should be doing it. This post is about the question that comes the morning after the red-team exercise: the report found four ways your agent can be steered off task. Now what holds the line at 2 a.m. on a Tuesday, six deploys later?

What red-teaming an agent gives you, and what it cannot

A red-team pass is a snapshot with a date on it. It tells you how this version of the agent, with this system prompt, these tools, and this model, responded to the attacks the exercise tried. That snapshot is valuable precisely because it is concrete: real payloads, real transcripts, real failures you can reproduce.

But agents are the fastest-changing software most teams have ever shipped. The system prompt gets tuned weekly. Tools get added. The model gets upgraded and behaves differently under the same prompt. A new MCP server joins the stack. Each change quietly re-opens questions the red-team exercise closed, and no team re-runs a full adversarial campaign on every deploy. The result is a familiar security shape: point-in-time assurance protecting a continuously changing system.

There is also a structural limit. Red-teaming tells you the agent can be compromised in certain ways. It does not sit between a compromised agent and the systems it touches. When the failure eventually happens in production, the red-team report explains it; it does not stop it.

Governance is the standing half of the same discipline

Runtime governance answers the complementary question: whatever state the agent is in today, compromised or healthy, tuned or drifted, what is it actually allowed to do? Every command, query, file write, and tool call is evaluated against the operator's policy before it executes, with graduated verdicts: allow, warn, require approval, block. The operator declares intent; the governance layer enforces what was declared.

The two halves compose naturally, and the composition is the point:

• Red-team findings become standing policy. The exercise showed your agent can be talked into calling the shell tool during a document-summarization task? Declare a scope without the shell tool, and that class of steering becomes an approval event instead of an incident, on every future version of the agent.
• Governance catches what the exercise did not try. An inline policy check does not need to have anticipated the specific payload; it evaluates the resulting action. A novel injection that produces an out-of-scope tool call is held at the same gate as a known one.
• Evidence accumulates continuously. A red-team engagement produces a report; a governance layer produces a per-action record of what was attempted and decided, every day, which is what an auditor or an incident review actually asks for.

What this looks like in NemoClaw specifically

We maintain a NemoClaw recipe that wires runtime governance into an agent's execution path: tool calls, MCP calls, and responses are checked against policy before they run. The recipe cleared NVIDIA maintainer security review before merging into the NemoClaw community repository, and it ships with five live validation cases so you can watch five distinct attack classes produce five distinct verdicts before trusting it with your own agents. The case study walks through all five, and the integration guide covers setup.

The declaration step matters more than any single check. A NemoClaw agent that registers what it is for and which tools it may use gets two things at once: a boundary that turns out-of-scope actions into approval events, and context that keeps the security layer from second-guessing legitimate work. We measured what that context is worth on our production system, and the answer is: a lot. As of this week the same declaration can also carry an action ceiling, so a red-team finding like "the agent can be driven into a resource-burning loop" has a standing answer too.

A practical sequence for NemoClaw teams

1. Red-team first. Probe your agent with the adversarial tooling available in the ecosystem. Keep the transcripts.
2. Translate findings into declarations. Every steering the exercise achieved maps to a scope rule: tools the task never needed, durations it should not exceed, action counts beyond which a human should look.
3. Put governance inline. The recipe adds the checks to the execution path; out-of-policy actions are held before they run, whether or not anyone predicted the payload that caused them.
4. Re-run the red team against the governed agent. The findings that survive are your real residual risk, and they arrive with per-action evidence attached.

Point-in-time testing and standing enforcement are not rivals; they are the two halves security has always needed. The teams that get agentic AI right will run both. Where the standing half fits the broader control picture is in the agent security stack, and the full technique coverage is on the coverage map.