Back to skill

Security audit

Nemoclaw Email Policy

Security checks for vulnerabilities and agentic risk

Overview

This documentation-only skill is mostly coherent, but its default Outlook policy leaves Microsoft Graph send-capable POST access open despite being advertised as an email send guardrail.

Review the Outlook preset before relying on it for send prevention. Use least-privilege Graph scopes, avoid Mail.Send for read/draft agents, enforce recipient approval in a component that direct Graph clients cannot bypass, and pin or verify the NemoClaw installation source.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:35
Finding

Unpinned Global Installation of a Third-Party Package

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 35-40
Vulnerability Type: Unverified and unpinned third-party dependency installation
Risk Level: Medium

Vulnerable Code Snippet:

markdown
## Prerequisites

- **macOS** (NemoClaw uses the macOS sandbox)
- **NemoClaw installed**: `npm install -g nemoclaw` or clone from GitHub
- **Email MCP server configured**: e.g., `email-agent-mcp` with Microsoft 365 OAuth completed

Technical Analysis

The Skill directs users to install nemoclaw globally without specifying an audited version, package integrity value, or canonical source repository. The alternative instruction to “clone from GitHub” also omits a repository URL, commit hash, signed release, or verification process.

A global npm installation can run package lifecycle scripts, including preinstall, install, and postinstall, under the installing user's privileges. Because the requested package version is not pinned, its effective contents can change after this Skill has been reviewed. An npm account compromise, malicious future release, package-name confusion, or selection of an unofficial GitHub repository could therefore introduce attacker-controlled code.

This is a supply-chain weakness rather than evidence that the current nemoclaw package is malicious.

Attack Path

  1. An attacker compromises the package publisher, publishes a malicious future version, or distributes an unofficial repository matching the ambiguous GitHub instruction.
  2. The malicious package includes attacker-controlled npm lifecycle code.
  3. A user follows the Skill and runs npm install -g nemoclaw, or clones the attacker's repository.
  4. npm executes the package lifecycle scripts during installation.
  5. The malicious code runs with the privileges of the installing account and can modify user-accessible files, steal credentials available to that account, or alter globally installed tooling.

Im

...[truncated 494 chars]

Remediation
View remediation

Remediation Suggestions

  • Pin the dependency to a specifically reviewed version, for example nemoclaw@X.Y.Z.
  • Publish the canonical npm package URL and canonical source repository URL.
  • Provide a release integrity hash, signed tag, or other reproducible verification mechanism.
  • Recommend installing in an isolated, project-local environment rather than globally where feasible.
  • Use --ignore-scripts when lifecycle scripts are unnecessary; otherwise document and audit every required lifecycle script.
  • Replace “clone from GitHub” with a specific repository and immutable commit hash.
  • Document a controlled upgrade process so later versions are reviewed before deployment.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:88
Finding

Outlook Preset Permits Email Sending Despite Network-Level Safety Framing

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 88-99
Vulnerability Type: Overly broad network policy configuration
Risk Level: High

Vulnerable Code Snippet:

markdown
### Controlled: Send Operations

The Outlook preset allows POST to Graph API endpoints, which includes the send endpoint (`/me/sendMail`). To restrict sending further:

1. **email-agent-mcp send allowlist** — configure which recipients the MCP server allows (empty by default — blocks all sends)
2. **Custom NemoClaw policy** — create a custom policy that blocks the send endpoint entirely:
   ```yaml
   - host: graph.microsoft.com
     port: 443
     tls: true
     methods: [GET, PATCH]  # POST removed — blocks send, create draft, move
   ```

For most deployments, the MCP allowlist is sufficient. The custom policy is for high-security environments where you want belt-and-suspenders.

Technical Analysis

The standard Outlook preset permits POST requests to graph.microsoft.com, including the Microsoft Graph /me/sendMail endpoint. Consequently, the preset does not itself enforce send prevention at the network layer.

The recipient allowlist is implemented by email-agent-mcp, not by NemoClaw's network policy. A direct Graph API client, a compromised MCP component, or another process operating within the same permitted policy boundary may call /me/sendMail without passing through that application-level allowlist.

The proposed custom policy removes all POST access to Microsoft Graph. While this blocks sending, it also blocks legitimate POST-dependent functions identified by the document, including draft creation and message moves. It therefore does not provide fine-grained separation between approved draft operations and prohibited send operations.

Attack Path

  1. A production deployment applies the documented Outlook preset and assumes email actions are protected at the network layer.
  2. The agent encou ...[truncated 1189 chars]
Remediation
View remediation

Remediation Suggestions

  • Explicitly state that the default Outlook preset allows sending and does not independently enforce recipient restrictions.
  • Implement and document a verified path-aware deny rule for /me/sendMail and other send actions while retaining only the POST paths required for approved draft operations.
  • If NemoClaw cannot filter by request path, separate send-capable operations into a distinct process or policy boundary and deny POST by default in the read-and-draft agent.
  • Apply least-privilege Microsoft Graph OAuth scopes. Do not grant Mail.Send to agents that only read or create drafts.
  • Require explicit user approval in a trusted component before any send operation.
  • Enforce recipient allowlists in a mandatory gateway that direct Graph clients cannot bypass.
  • Add negative integration tests proving that /me/sendMail is blocked while approved draft and move operations continue to work.
  • Treat the broad POST policy as send-capable in documentation, deployment checklists, and security claims.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

External Transmission

Medium
Category
Data Exfiltration
Confidence
50% confidence
Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · SKILL.md (reported line 138)May include surrounding context.

curl -s -o /dev/null -w "%{http_code}" https://graph.microsoft.com/v1.0/me

This should fail (blocked endpoint)

curl -s -o /dev/null -w "%{http_code}" https://api.example.com/exfiltrate

text

## Troubleshooting

Static analysis

No suspicious patterns detected.