…VIDIA#1705)

## Summary

- Removed Telegram (`api.telegram.org`) and Discord (`discord.com`,
`gateway.discord.gg`, `cdn.discordapp.com`) from the base sandbox
network policy
- These endpoints gave every sandboxed agent default access to external
messaging APIs without user opt-in — a data exfiltration vector
- Users who configure messaging tokens during onboarding already get
connectivity via the existing preset system (`presets/telegram.yaml`,
`presets/discord.yaml`), which is applied automatically when tokens are
detected

## Test plan

- [x] Full vitest suite passes (1243 tests, 0 failures)
- [x] Base policy YAML parses correctly
- [x] No telegram/discord references remain in base policy
- [ ] E2E: verify messaging preset auto-application when tokens are
present

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Chores**
* Removed Telegram API endpoint from baseline network allow-list
policies
* Removed Discord API endpoints (REST and WebSocket gateway) from
sandbox network policies
* Updated network policy documentation to reflect removed endpoint
groups

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Signed-off-by: Aaron Erickson <aerickson@nvidia.com>

…VIDIA#1705)

## Summary

- Removed Telegram (`api.telegram.org`) and Discord (`discord.com`,
`gateway.discord.gg`, `cdn.discordapp.com`) from the base sandbox
network policy
- These endpoints gave every sandboxed agent default access to external
messaging APIs without user opt-in — a data exfiltration vector
- Users who configure messaging tokens during onboarding already get
connectivity via the existing preset system (`presets/telegram.yaml`,
`presets/discord.yaml`), which is applied automatically when tokens are
detected

## Test plan

- [x] Full vitest suite passes (1243 tests, 0 failures)
- [x] Base policy YAML parses correctly
- [x] No telegram/discord references remain in base policy
- [ ] E2E: verify messaging preset auto-application when tokens are
present

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Chores**
* Removed Telegram API endpoint from baseline network allow-list
policies
* Removed Discord API endpoints (REST and WebSocket gateway) from
sandbox network policies
* Updated network policy documentation to reflect removed endpoint
groups

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Signed-off-by: Aaron Erickson <aerickson@nvidia.com>

…NVIDIA#2180)

After a fresh `nemoclaw onboard` with Balanced tier defaults, where the
user explicitly skipped messaging channels in step [5/8] and did not
tick Discord in step [8/8], `nemoclaw <name> policy-list` reports:

    ● discord — Discord API, gateway, and CDN access
      (active on gateway, missing from local state)

The sandbox can reach `discord.com`, `gateway.discord.gg`, and
`cdn.discordapp.com` without the user having opted in — the base
sandbox policy's own header says "deny by default, allow only what's
needed for core functionality," which messaging to third-party IM
platforms is not. Same story for `api.telegram.org`.

This is a regression, not a new bug:

- NVIDIA#1705 (2026-04-09, 77051cc) removed pre-allowed `telegram` and
  `discord` from `nemoclaw-blueprint/policies/openclaw-sandbox.yaml`
  for exactly this reason.
- NVIDIA#1700 (2026-04-14, 855924f), an unrelated npm_registry PR, was
  rebased on a branch that predated NVIDIA#1705 and re-added both entries
  during conflict resolution. The CodeRabbit release notes on NVIDIA#1700
  even called this out as "Added network policy entries to enable
  controlled Telegram and Discord messaging access" — it landed along
  with the legitimate npm_registry tightening and has been in the
  baseline since.

Once a key like `discord` exists in the gateway's loaded policy,
`policies.getGatewayPresets()` detects the Discord preset as active
(it matches on key presence), and `policy-list` then renders the
misleading "active on gateway, missing from local state" line.

- Re-remove `telegram` and `discord` entries from
  `nemoclaw-blueprint/policies/openclaw-sandbox.yaml`. Messaging
  endpoints are only reachable if the user selects the matching
  channel in step [5/8] and the corresponding preset is applied on
  top of the baseline in step [8/8]. Leave a comment block at the
  removed location referencing NVIDIA#1705, NVIDIA#2180, and the preset path so
  the next merge-conflict resolution does not casually re-add them.
- Add three regression tests in `test/validate-blueprint.test.ts`
  mirroring the existing `NVIDIA#1583` GitHub pattern:
  - `regression NVIDIA#2180: base policy does not silently grant Telegram access`
  - `regression NVIDIA#2180: base policy does not silently grant Discord access`
  - `regression NVIDIA#2180: base policy does not silently grant Slack access`
    (guard against the same merge pattern re-adding Slack even though
    it was never in the baseline historically)
  Each asserts both the key absence in `network_policies` and the
  absence of any host-matching endpoint anywhere in the base policy,
  so a rename can't smuggle the grant back in.

- `npx vitest run test/validate-blueprint.test.ts test/policies.test.ts`
  — 124 tests pass including the 3 new regressions.
- `npx vitest run test/validate-configs-dangerous-hosts.test.ts test/onboard.test.ts`
  — 160 tests pass, no onboard flow regressions.

Touches only the base policy YAML and the blueprint validator. Does
not modify any preset (presets/telegram.yaml, presets/discord.yaml,
presets/slack.yaml) — users who enabled messaging via onboard still
get the same preset applied on top of baseline and retain the same
endpoint access. The permissive variant
(openclaw-sandbox-permissive.yaml), used for
`--dangerously-skip-permissions`, is intentionally unchanged.

Fixes NVIDIA#2180.

Signed-off-by: latenighthackathon <latenighthackathon@users.noreply.github.com>

…NVIDIA#2180)

After a fresh `nemoclaw onboard` with Balanced tier defaults, where the
user explicitly skipped messaging channels in step [5/8] and did not
tick Discord in step [8/8], `nemoclaw <name> policy-list` reports:

    ● discord — Discord API, gateway, and CDN access
      (active on gateway, missing from local state)

The sandbox can reach `discord.com`, `gateway.discord.gg`, and
`cdn.discordapp.com` without the user having opted in — the base
sandbox policy's own header says "deny by default, allow only what's
needed for core functionality," which messaging to third-party IM
platforms is not. Same story for `api.telegram.org`.

This is a regression, not a new bug:

- NVIDIA#1705 (2026-04-09, 77051cc) removed pre-allowed `telegram` and
  `discord` from `nemoclaw-blueprint/policies/openclaw-sandbox.yaml`
  for exactly this reason.
- NVIDIA#1700 (2026-04-14, 855924f), an unrelated npm_registry PR, was
  rebased on a branch that predated NVIDIA#1705 and re-added both entries
  during conflict resolution. The CodeRabbit release notes on NVIDIA#1700
  even called this out as "Added network policy entries to enable
  controlled Telegram and Discord messaging access" — it landed along
  with the legitimate npm_registry tightening and has been in the
  baseline since.

Once a key like `discord` exists in the gateway's loaded policy,
`policies.getGatewayPresets()` detects the Discord preset as active
(it matches on key presence), and `policy-list` then renders the
misleading "active on gateway, missing from local state" line.

- Re-remove `telegram` and `discord` entries from
  `nemoclaw-blueprint/policies/openclaw-sandbox.yaml`. Messaging
  endpoints are only reachable if the user selects the matching
  channel in step [5/8] and the corresponding preset is applied on
  top of the baseline in step [8/8]. Leave a comment block at the
  removed location referencing NVIDIA#1705, NVIDIA#2180, and the preset path so
  the next merge-conflict resolution does not casually re-add them.
- Add three regression tests in `test/validate-blueprint.test.ts`
  mirroring the existing `NVIDIA#1583` GitHub pattern:
  - `regression NVIDIA#2180: base policy does not silently grant Telegram access`
  - `regression NVIDIA#2180: base policy does not silently grant Discord access`
  - `regression NVIDIA#2180: base policy does not silently grant Slack access`
    (guard against the same merge pattern re-adding Slack even though
    it was never in the baseline historically)
  Each asserts both the key absence in `network_policies` and the
  absence of any host-matching endpoint anywhere in the base policy,
  so a rename can't smuggle the grant back in.

- `npx vitest run test/validate-blueprint.test.ts test/policies.test.ts`
  — 124 tests pass including the 3 new regressions.
- `npx vitest run test/validate-configs-dangerous-hosts.test.ts test/onboard.test.ts`
  — 160 tests pass, no onboard flow regressions.

Touches only the base policy YAML and the blueprint validator. Does
not modify any preset (presets/telegram.yaml, presets/discord.yaml,
presets/slack.yaml) — users who enabled messaging via onboard still
get the same preset applied on top of baseline and retain the same
endpoint access. The permissive variant
(openclaw-sandbox-permissive.yaml), used for
`--dangerously-skip-permissions`, is intentionally unchanged.

Fixes NVIDIA#2180.

Signed-off-by: latenighthackathon <latenighthackathon@users.noreply.github.com>

…NVIDIA#2180)

After a fresh `nemoclaw onboard` with Balanced tier defaults, where the
user explicitly skipped messaging channels in step [5/8] and did not
tick Discord in step [8/8], `nemoclaw <name> policy-list` reports:

    ● discord — Discord API, gateway, and CDN access
      (active on gateway, missing from local state)

The sandbox can reach `discord.com`, `gateway.discord.gg`, and
`cdn.discordapp.com` without the user having opted in — the base
sandbox policy's own header says "deny by default, allow only what's
needed for core functionality," which messaging to third-party IM
platforms is not. Same story for `api.telegram.org`.

This is a regression, not a new bug:

- NVIDIA#1705 (2026-04-09, 77051cc) removed pre-allowed `telegram` and
  `discord` from `nemoclaw-blueprint/policies/openclaw-sandbox.yaml`
  for exactly this reason.
- NVIDIA#1700 (2026-04-14, 855924f), an unrelated npm_registry PR, was
  rebased on a branch that predated NVIDIA#1705 and re-added both entries
  during conflict resolution. The CodeRabbit release notes on NVIDIA#1700
  even called this out as "Added network policy entries to enable
  controlled Telegram and Discord messaging access" — it landed along
  with the legitimate npm_registry tightening and has been in the
  baseline since.

Once a key like `discord` exists in the gateway's loaded policy,
`policies.getGatewayPresets()` detects the Discord preset as active
(it matches on key presence), and `policy-list` then renders the
misleading "active on gateway, missing from local state" line.

- Re-remove `telegram` and `discord` entries from
  `nemoclaw-blueprint/policies/openclaw-sandbox.yaml`. Messaging
  endpoints are only reachable if the user selects the matching
  channel in step [5/8] and the corresponding preset is applied on
  top of the baseline in step [8/8]. Leave a comment block at the
  removed location referencing NVIDIA#1705, NVIDIA#2180, and the preset path so
  the next merge-conflict resolution does not casually re-add them.
- Add three regression tests in `test/validate-blueprint.test.ts`
  mirroring the existing `NVIDIA#1583` GitHub pattern:
  - `regression NVIDIA#2180: base policy does not silently grant Telegram access`
  - `regression NVIDIA#2180: base policy does not silently grant Discord access`
  - `regression NVIDIA#2180: base policy does not silently grant Slack access`
    (guard against the same merge pattern re-adding Slack even though
    it was never in the baseline historically)
  Each asserts both the key absence in `network_policies` and the
  absence of any host-matching endpoint anywhere in the base policy,
  so a rename can't smuggle the grant back in.

- `npx vitest run test/validate-blueprint.test.ts test/policies.test.ts`
  — 124 tests pass including the 3 new regressions.
- `npx vitest run test/validate-configs-dangerous-hosts.test.ts test/onboard.test.ts`
  — 160 tests pass, no onboard flow regressions.

Touches only the base policy YAML and the blueprint validator. Does
not modify any preset (presets/telegram.yaml, presets/discord.yaml,
presets/slack.yaml) — users who enabled messaging via onboard still
get the same preset applied on top of baseline and retain the same
endpoint access. The permissive variant
(openclaw-sandbox-permissive.yaml), used for
`--dangerously-skip-permissions`, is intentionally unchanged.

Fixes NVIDIA#2180.

Signed-off-by: latenighthackathon <latenighthackathon@users.noreply.github.com>

## Summary

The base sandbox policy
(`nemoclaw-blueprint/policies/openclaw-sandbox.yaml`) was silently
granting every sandbox egress to `api.telegram.org`, `discord.com`,
`gateway.discord.gg`, and `cdn.discordapp.com` — regardless of whether
the user enabled the telegram/discord messaging channel in step [5/8] or
ticked the preset in step [8/8] of onboard. This is a regression of a
previously-fixed behavior.

After a fresh onboard that explicitly skipped messaging channels and did
not tick Discord in the Balanced-tier preset picker, `nemoclaw <name>
policy-list` reports:

```
● discord — Discord API, gateway, and CDN access (active on gateway, missing from local state)
```

## Problem

Regression history:

- [#1705](#1705) (2026-04-09,
[`77051cc8`](77051cc8)) —
removed `telegram` and `discord` from baseline "for exactly this
reason." Explicitly called it a data exfiltration vector.
- [#1700](#1700) (2026-04-14,
[`855924fd`](855924fd)) — an
unrelated npm_registry PR that was rebased on a branch predating #1705.
The CodeRabbit release notes on #1700 even flagged it: *"Added network
policy entries to enable controlled Telegram and Discord messaging
access."* The messaging entries came back as part of that PR's
conflict-resolution and have been in the baseline since.

Once `discord` exists as a key in the gateway's loaded policy,
`policies.getGatewayPresets()` detects the Discord preset as active (it
matches on key presence). `nemoclaw policy-list` then renders the
misleading "active on gateway, missing from local state" line for a
preset the user never selected — and the egress is actually enforced, so
it's a real capability grant, not just a display bug.

## Test plan

- [x] `npx vitest run test/validate-blueprint.test.ts
test/policies.test.ts` — 124 tests pass, including the three new
regression tests that guard against this specific re-add pattern for
telegram, discord, and slack.
- [x] `npx vitest run test/validate-configs-dangerous-hosts.test.ts
test/onboard.test.ts` — 160 tests pass. No onboard-flow regressions.
- [x] Manually verified that users who enable a messaging channel in
step [5/8] and apply the corresponding preset in step [8/8] still get
identical endpoint access via `presets/{telegram,discord}.yaml` (no
preset YAML changes in this PR).
- [x] `openclaw-sandbox-permissive.yaml` (used for
`--dangerously-skip-permissions`) unchanged — permissive users still get
pre-allowed messaging as before.

Fixes #2180.

Signed-off-by: latenighthackathon
<latenighthackathon@users.noreply.github.com>

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Bug Fixes**
* Removed default network permissions for Telegram and Discord from the
sandbox baseline; messaging endpoints (Telegram, Discord, Slack) are no
longer enabled by default and must be added via opt-in presets during
onboarding.

* **Tests**
* Added regression tests to ensure messaging provider access (Telegram,
Discord, Slack) remains restricted in the baseline policy and cannot be
reintroduced inadvertently.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Signed-off-by: latenighthackathon <latenighthackathon@users.noreply.github.com>
Co-authored-by: latenighthackathon <latenighthackathon@users.noreply.github.com>
Co-authored-by: J. Yaunches <jyaunches@nvidia.com>