Intent-layer governance as a composable extension to NemoClaw's defense-in-depth model

[dacoldest]

Background

NemoClaw's hardened blueprint addresses infrastructure-level enforcement: container isolation, network policy, process limits. That covers what an agent can do at the OS and network layer. There is a complementary enforcement layer not yet addressed: what an agent is authorized to attempt semantically — evaluated at intent declaration time, before the action reaches the execution environment.

This is the distinction between "the agent cannot make outbound connections to unapproved hosts" (NemoClaw's domain) and "the agent is not authorized to initiate a treasury disbursement above $50k without human review" (intent governance). Both are necessary in regulated deployments. Neither replaces the other.

The proposal

A composable intent governance extension for NemoClaw — a sidecar that evaluates structured intent declarations against an operator-defined policy file before execution proceeds.

The enforcement pipeline:

1. Agent submits a structured intent declaration before executing a consequential action
2. Policy evaluator reads the operator's policy at runtime — no restarts required to update rules
3. Returns one of three decisions:
   • APPROVED — signed attestation issued, execution proceeds
   • DENIED — hard policy violation, execution blocked, operator notified
   • PENDING — soft-limit threshold crossed, 24-hour consensus hold queued for human review
4. Executor gates on the attestation — unsigned actions are rejected

Policy is expressed in four typed blocks:

• evm — hard limits on financial transactions and chain access
• tool_calls — blocked tool names and outbound domain rules
• custom — operator-defined deny expressions
• soft_limits — daily aggregate caps that trigger holds rather than hard denials

How this fits NemoClaw's architecture

Enforcement layer	Mechanism	Prevents
OS / container	NemoClaw (Landlock, seccomp, netns)	Agent breaking out of sandbox
Network egress	NemoClaw (network policy presets)	Unauthorized external communication
Intent / semantic	Policy sidecar (this proposal)	Agent attempting actions outside authorized scope
Audit trail	Signed attestations	Post-hoc repudiation of authorized actions

The sidecar would integrate with NemoClaw's blueprint lifecycle hooks as a managed process — starting alongside the agent, accessible via a local endpoint, with its policy file mounted alongside the blueprint config.

Design questions for maintainers

1. Is there a preferred pattern for managed sidecars in the blueprint system, or would this be the first? The CLI extension architecture looks like the natural home but I want to confirm before writing code.
2. The policy file is operator-defined YAML/Markdown. Should this live adjacent to the blueprint config, or does NemoClaw have a conventions doc for operator-supplied runtime files?
3. Is there appetite for a governance: block in the blueprint schema, or would a standalone sidecar config be preferred to keep blueprint scope contained?

Happy to produce a full spec or prototype based on maintainer guidance.