Question 1

Can I combine multiple recipes into one policy file?

Accepted Answer

No. Each agent should have its own policy file with the narrowest permissions required for its specific function. An agent that handles both email triage and Jira ticket management should be split into two agents, each with its own policy. This follows the principle of least privilege and makes security review tractable. One agent, one policy, one set of permissions.

Question 2

What happens when an agent action is denied by the policy?

Accepted Answer

The action fails and the agent receives an error response indicating a policy denial. The denial is logged in the audit trail with the timestamp, agent name, attempted action, and the specific policy rule that blocked it. The agent does not retry automatically — it reports the failure to the orchestrator or returns an error to the user. Denied actions are the most valuable signal in your audit logs; they tell you either that the policy is working correctly or that it needs adjustment.

Question 3

How do presets relate to custom policies?

Accepted Answer

NemoClaw presets (Slack, Jira, Discord, npm, PyPI, Docker, Telegram, HuggingFace, Outlook) are starting templates that provide reasonable defaults for common integrations. They are not production-ready configurations. Import a preset, review every destination and method permission, remove anything your agent does not need, add path-level restrictions, and save the result as your custom policy. The preset saves you from writing the policy from scratch. It does not save you from reviewing it.

Question 4

Does the policy engine work with custom MCP servers?

Accepted Answer

Yes. NemoClaw's policy engine evaluates all network traffic from the sandbox, regardless of whether the request originates from a built-in tool, an MCP server, or a direct HTTP call from agent code. If your custom MCP server makes requests to api.example.com, that destination must be in the policy's allowed destinations list. The policy engine does not distinguish between request sources — it evaluates every outbound request from the sandbox against the same rules. See our architecture deep dive for how the out-of-process policy engine intercepts traffic.

Question 5

How often should YAML policies be reviewed?

Accepted Answer

Review policies quarterly at minimum, and immediately after any of these events: NVIDIA releases a new NemoClaw version, your agent's capabilities are expanded, a new integration is added, or a security incident occurs. Quarterly reviews catch policy drift — permissions that were added temporarily and never removed, destinations for services that have been decommissioned, or method permissions that are broader than current functionality requires. ManageMyClaw's Enterprise Managed Care includes quarterly policy reviews as part of the ongoing governance program.

Rakesh Patel

Articles

NemoClaw Policy Engine Cookbook: 10 YAML Configurations for Enterprise Workflows

NemoClaw + ManageMyClaw: Enterprise Implementation and Managed Care for NVIDIA’s Agent Stack

What NemoClaw Cannot Fix: The 4 Gaps Enterprises Must Close Themselves

NemoClaw on VPS vs DGX Spark vs RTX Workstation: Enterprise Hardware Decision Guide

NemoClaw Implementation Guide: From Alpha Preview to Production Deployment

NemoClaw’s 17 Launch Partners: What Adobe, Salesforce, SAP, and CrowdStrike Are Building

NemoClaw for Regulated Industries: Healthcare, Finance, and Legal Compliance

NemoClaw’s Privacy Router: How to Keep Enterprise Data On-Premises While Using Cloud LLMs

NemoClaw + CrowdStrike Falcon: The Secure-by-Design AI Blueprint for Enterprises

NemoClaw Architecture Deep Dive: OpenShell, Privacy Router, and the YAML Policy Engine