NemoClaw Got Us Here. Here's What's Still Missing.

When NVIDIA launched NemoClaw at GTC 2026, something shifted in the enterprise AI conversation. For the first time, security and platform teams had a credible, production-ready answer to the question that had been killing AI agent pilots for months: how do we actually deploy this without our compliance team shutting it down?

That's not a small thing. I've spoken with enough IAM architects and CISOs to know that the gap between "the demo worked" and "we can run this in production" has been the graveyard of more AI initiatives than most vendors want to admit. NemoClaw built a real bridge across that gap. As someone who thinks about agent security architecture every day, I have a lot of respect for what the team built.

But I also think about what comes next. And as a partner to NemoClaw, I want to be direct about where the architecture ends and where a new layer needs to begin, because understanding that boundary is what lets enterprises actually unlock the value of agentic AI at scale.

What I Think NemoClaw Gets Right#

Let me be specific, because this is important.

NemoClaw solves the infrastructure problem. It wraps OpenClaw's multi-agent orchestration with a hardened security layer, privacy routing that keeps sensitive data from leaking to cloud APIs, local Nemotron model support for air-gapped or high-compliance environments, OpenShell isolation for sandboxing agent execution, role-based access controls, and structured audit logging that your SOC team can actually work with.

Crucially, it integrates with existing enterprise identity infrastructure like Active Directory and SSO providers, so agents inherit the access permissions of the employee using them. That's the right instinct, and it's a meaningful step forward from the raw OpenClaw model, where agents could touch systems with essentially no governance layer in place.

From a practitioner standpoint, NemoClaw answered three questions that had been blocking enterprise adoption:

• Can I run agents without my data leaving my perimeter? Yes.
• Can I enforce policy on what agents can and can't do? Yes.
• Can I produce an audit trail that satisfies compliance? Yes.

These were hard problems. They're solved. So what's missing?

The Static Policy Problem#

NemoClaw's security model is fundamentally policy-based, and policies are defined at deployment time. That's the right architecture for infrastructure-layer security. But enterprise AI agents don't operate in the controlled conditions that were true when the policy was written.

Consider a finance automation agent. At provisioning time, you define its access scope: it can read accounts payable data, write to the ERP, and query the vendor database. You set its RBAC, log its actions, route its sensitive queries locally. NemoClaw handles all of that correctly.

Now consider what happens six weeks later. The agent is three hops into a workflow it was never explicitly designed for. A supervisor agent delegated a task that falls just within the letter of the policy but well outside the spirit of what anyone intended when they provisioned it. The action it's about to take is technically permissible under its static entitlements. It is also deeply wrong for the context.

Static policy cannot see context. It can tell you whether an action is permitted. It cannot tell you whether a permitted action is appropriate - right now, in this workflow, for this data, at this moment in the chain.

That gap is not a failure of NemoClaw. It's a structural limitation of policy-based security applied to systems that reason and adapt. Runtime behavioral observation is a different layer, and it requires a different approach.

The Multi-Agent Chain Problem#

NemoClaw's security model was largely designed around individual agents. An agent has an identity, inherits permissions, gets sandboxed, produces logs. That works well for single-agent deployments.

Enterprise AI deployments are almost never single-agent.

In practice, you have supervisor agents delegating tasks to worker agents, which may invoke sub-agents or external tool calls, which pass context through multiple hops before anything touches a sensitive system. By the time an action reaches the point of execution, the original human actor may be entirely abstracted from the transaction.

This creates a specific problem that neither infrastructure-layer security nor traditional IAM is designed to handle: identity in a chain degrades. At hop one, you know who initiated the workflow and why. At hop three, that context has been filtered, summarized, and reinterpreted by intermediate agents. The action being taken at hop three may be authorized by the permissions of the agent executing it, while being completely inconsistent with the intent of the human who started the chain.

Audit logs tell you what happened at each hop. They do not tell you whether what happened at hop three was consistent with what the human at hop one intended to authorize. That is an identity and intent problem, not an infrastructure problem.

The Accountability Gap#

Here is the question I ask teams when I'm reviewing their agentic AI architecture: when something goes wrong in a multi-agent workflow, who is responsible?

NemoClaw gives you logs. Logs tell you which agent took which action, which model was called, which data was accessed. That's essential, and it's more than most teams have today.

But accountability in a multi-agent system isn't just about logging, it's about being able to trace an outcome back to an authorizing intent and an accountable principle. When a chain of agents produces a result that no single agent was explicitly authorized to produce alone, the question isn't just what happened - it's who should have caught this, and at what point in the chain?

Traditional governance models assign accountability at provisioning time: this agent is owned by this team, governed by this policy. That's necessary. It's not sufficient for the accountability questions that arise when agents operate autonomously across organizational boundaries in ways that compound into outcomes nobody explicitly authorized.

What NemoClaw Intentionally Leaves Open#

NemoClaw built the runway. But a runway without a control tower is just a long strip of concrete. I want to be clear about something, because I think it reflects well on NVIDIA's architectural thinking: NemoClaw was not designed to solve the runtime behavioral and identity governance problem. It was designed to solve the infrastructure and deployment problem, and it does that well.

The identity security layer, runtime observation, intent-aware controls, behavioral analysis, cross-chain accountability, is explicitly the domain of the identity industry. NemoClaw creates a secure surface for agents to operate on. What governs how they operate on that surface, in real time, across complex chains, is a separate and complementary concern.

That's the boundary our partnership is built around. aizome operates at the layer above the infrastructure, observing agent behavior at the point of operation, maintaining a hybrid identity model that evolves with the context of each workflow, and enforcing dynamic controls that respond to behavioral drift rather than just policy violations.

Together, the architecture looks like this: NemoClaw provides a hardened execution environment. aizome provides the runtime identity and behavioral governance layer that understands why an agent is doing what it's doing, not just whether it's permitted to do it.

At ServiceNow Knowledge 2026, Jensen Huang put it simply: the next frontier isn't building more powerful agents, it's connecting them safely to the enterprise. Think of it like the early days of the automobile. The engine existed. The roads were being built. What unlocked mass adoption wasn't more horsepower, it was the gas stations. The connective infrastructure that made the whole system usable at scale. NemoClaw built the engine and hardened the chassis. What enterprises still need is the layer that connects agents safely and accountably to their most sensitive systems, their ERP, their HR platform, and their financial data without exposing the underlying infrastructure to risk. That's the layer aizome is built to provide. Not replacing what NemoClaw does, but completing what it deliberately left open.

What the Full Picture Requires#

For practitioners building production agentic AI architectures, I'd suggest thinking in three layers:

Infrastructure security - sandboxing, privacy routing, data perimeter controls, RBAC, audit logging. NemoClaw. This is the foundation without which none of the rest matters.

Identity governance - agent lifecycle management, ownership mapping, entitlement controls, least-privilege enforcement. Your existing IAM and NHI tooling, extended to agents. Necessary but insufficient on its own.

Runtime behavioral governance - real-time observation at the point of operation, intent-aware dynamic controls, cross-chain accountability, behavioral drift detection. This is the layer that doesn't exist yet in most enterprise stacks. It's what aizome is built to provide.

The enterprises that get agentic AI right won't be the ones that pick the best tool in any single layer. They'll be the ones that understand how the layers fit together and close the gaps between them deliberately.

See You at Identiverse#

I'll be at Identiverse in Las Vegas June 15-18, in the NHI + AI Pavilion at Kiosk 08. If you're an architect or security practitioner working through how to build a production-grade agentic AI stack, I'd genuinely like to compare notes.

The infrastructure problem is largely solved. The runtime identity and behavioral governance problem is wide open. That's the conversation I'm most interested in having.

Chen Pipek is CPO and Co-founder of aizome.