From 04d65e636c447577ad4730bfa61fb471d154b476 Mon Sep 17 00:00:00 2001 From: Miyoung Choi Date: Tue, 31 Mar 2026 14:28:57 -0700 Subject: [PATCH 1/3] docs: add security best practices --- docs/index.md | 17 ++ docs/security/best-practices.md | 316 ++++++++++++++++++++++++++++++++ 2 files changed, 333 insertions(+) create mode 100644 docs/security/best-practices.md diff --git a/docs/index.md b/docs/index.md index 37d49047b..4cf35bc2e 100644 --- a/docs/index.md +++ b/docs/index.md @@ -174,6 +174,16 @@ Policy schema, environment variables, and system architecture. {bdg-secondary}`Reference` ::: +:::{grid-item-card} Security Best Practices +:link: security/best-practices +:link-type: doc + +Every configurable security control, its default, and the risk of changing it. + ++++ +{bdg-secondary}`Concept` +::: + :::: ```{toctree} @@ -230,6 +240,13 @@ reference/policy-schema reference/support-matrix ``` +```{toctree} +:caption: Security +:hidden: + +security/best-practices +``` + ```{toctree} :caption: Resources :hidden: diff --git a/docs/security/best-practices.md b/docs/security/best-practices.md new file mode 100644 index 000000000..16697abd5 --- /dev/null +++ b/docs/security/best-practices.md @@ -0,0 +1,316 @@ +--- +title: + page: "OpenShell Security Best Practices — Controls, Risks, and Configuration Guidance" + nav: "Security Best Practices" +description: "A guide to every configurable security control in OpenShell: defaults, what you can change, and the risks of each choice." +topics: +- Generative AI +- Cybersecurity +tags: +- Security +- Policy +- Sandbox +- Landlock +- Seccomp +content: + type: concept + difficulty: intermediate + audience: + - engineer + - security_engineer +status: published +--- + + + +# Security Best Practices + +OpenShell enforces sandbox security across four layers: network, filesystem, process, and inference. +This page documents every configurable control, its default, what it protects, and the risk of relaxing it. + +For the full policy YAML schema, refer to the {doc}`../reference/policy-schema`. +For the architecture of each enforcement layer, refer to {doc}`../about/architecture`. + +## Enforcement Layers + +OpenShell applies security controls at two enforcement points. +OpenShell locks static controls at sandbox creation and requires destroying and recreating the sandbox to change them. +You can update dynamic controls on a running sandbox with `openshell policy set`. + +:::{list-table} +:header-rows: 1 +:widths: 20 30 20 30 + +* - Layer + - What it protects + - Enforcement point + - Changeable at runtime + +* - Network + - Unauthorized outbound connections and data exfiltration. + - CONNECT proxy + OPA policy engine + - Yes. Use `openshell policy set` or operator approval in the TUI. + +* - Filesystem + - System binary tampering, credential theft, config manipulation. + - Landlock LSM (kernel level) + - No. Requires sandbox re-creation. + +* - Process + - Privilege escalation, fork bombs, dangerous syscalls. + - Seccomp BPF + privilege drop (`setuid`/`setgid`) + - No. Requires sandbox re-creation. + +* - Inference + - Credential exposure, unauthorized model access. + - Proxy intercept of `inference.local` + - Yes. Use `openshell inference set`. + +::: + +## Network Controls + +### Deny-by-Default Egress + +Every outbound connection from the sandbox goes through the CONNECT proxy. +The proxy evaluates each connection against the OPA policy engine. +If no `network_policies` entry matches the destination host, port, and calling binary, the proxy denies the connection. + +| Aspect | Detail | +|---|---| +| Default | All egress denied. Only endpoints listed in `network_policies` can receive traffic. | +| What you can change | Add entries to `network_policies` in the policy YAML. Apply statically at creation (`--policy`) or dynamically (`openshell policy set`). | +| Risk if relaxed | Each allowed endpoint is a potential data exfiltration path. The agent can send workspace content, credentials, or conversation history to any reachable host. | +| Recommendation | Add only endpoints the agent needs for its task. Start with a minimal policy and use denied-request logs (`openshell logs --source sandbox`) to identify missing endpoints. | + +### Network Namespace Isolation + +The sandbox runs in a dedicated Linux network namespace with a veth pair. +All traffic routes through the host-side veth IP (`10.200.0.1`) where the proxy listens. +Even if a process ignores proxy environment variables, it can only reach the proxy. + +| Aspect | Detail | +|---|---| +| Default | Always active. The sandbox cannot bypass the proxy at the network level. | +| What you can change | This is not a user-facing knob. OpenShell always enforces it in proxy mode. | +| Risk if bypassed | Without network namespace isolation, a process could connect directly to the internet, bypassing all policy enforcement. | +| Recommendation | No action needed. OpenShell enforces this automatically. | + +### Binary Identity Binding + +The proxy identifies which binary initiated each connection by reading `/proc//exe` (the kernel-trusted executable path). +It walks the process tree for ancestor binaries and parses `/proc//cmdline` for script interpreters. +The proxy SHA256-hashes each binary on first use (trust-on-first-use). If someone replaces a binary mid-session, the hash mismatch triggers an immediate deny. + +| Aspect | Detail | +|---|---| +| Default | Every `network_policies` entry requires a `binaries` list. Only listed binaries can reach the associated endpoints. Binary paths support glob patterns (`*` for one path component, `**` for recursive). | +| What you can change | Add binaries to an endpoint entry. Use glob patterns for directory-scoped access (for example, `/sandbox/.vscode-server/**`). | +| Risk if relaxed | Broad glob patterns (like `/**`) allow any binary to reach the endpoint, defeating the purpose of binary-scoped enforcement. | +| Recommendation | Scope binaries to the specific executables that need each endpoint. Use narrow globs when the exact path varies (for example, across Python virtual environments). | + +### L4-Only vs L7 Inspection + +The `protocol` field on an endpoint controls whether the proxy inspects individual HTTP requests inside the tunnel. + +| Aspect | Detail | +|---|---| +| Default | Endpoints without a `protocol` field use L4-only enforcement: the proxy checks host, port, and binary, then relays the TCP stream without inspecting payloads. | +| What you can change | Add `protocol: rest` to enable per-request HTTP inspection. Pair it with `rules` (fine-grained method and path control) or `access` presets (`full`, `read-only`, `read-write`). | +| Risk if relaxed | L4-only endpoints allow the agent to send any data through the tunnel after the initial connection is permitted. The proxy cannot see HTTP methods, paths, or bodies. Adding `access: full` with `protocol: rest` enables inspection but permits all methods and paths, providing observability without restriction. | +| Recommendation | Use `protocol: rest` with specific `rules` for APIs where you want method and path control. Use `access: read-only` for read-only endpoints. Omit `protocol` for non-HTTP protocols (WebSocket, gRPC streaming). | + +### Enforcement Mode (`audit` vs `enforce`) + +When `protocol: rest` is active, the `enforcement` field controls whether the proxy blocks or logs rule violations. + +| Aspect | Detail | +|---|---| +| Default | `audit`. The proxy logs violations but forwards traffic. | +| What you can change | Set `enforcement: enforce` to block requests that do not match any `rules` entry. Denied requests receive a `403 Forbidden` response with a JSON body describing the violation. | +| Risk if relaxed | `audit` mode provides visibility but does not prevent unauthorized actions. An agent can still perform write or delete operations on an API even if the rules would deny them. | +| Recommendation | Start with `audit` to understand traffic patterns and verify that rules are correct. Switch to `enforce` once you have validated that the rules match the intended access pattern. | + +### TLS Handling + +The proxy auto-detects TLS on every tunnel by peeking the first bytes. +When a TLS ClientHello is detected, the proxy terminates TLS transparently using a per-sandbox ephemeral CA. +This enables credential injection and L7 inspection without explicit configuration. + +| Aspect | Detail | +|---|---| +| Default | Auto-detect and terminate. OpenShell generates the sandbox CA at startup and injects it into the process trust stores (`NODE_EXTRA_CA_CERTS`, `SSL_CERT_FILE`, `REQUESTS_CA_BUNDLE`, `CURL_CA_BUNDLE`). | +| What you can change | Set `tls: skip` on an endpoint to disable TLS detection and termination for that endpoint. Use this for client-certificate mTLS to upstream or non-standard binary protocols. | +| Risk if relaxed | `tls: skip` disables credential injection and L7 inspection for that endpoint. The proxy relays encrypted traffic without seeing the contents. | +| Recommendation | Use auto-detect (the default) for most endpoints. Use `tls: skip` only when the upstream requires the client's own TLS certificate (mTLS) or uses a non-HTTP protocol. | + +### SSRF Protection + +After OPA policy allows a connection, the proxy resolves DNS and rejects connections where the resolved IP is internal (loopback, link-local, or RFC 1918 private). + +| Aspect | Detail | +|---|---| +| Default | The proxy blocks all private IPs. Loopback (`127.0.0.0/8`) and link-local (`169.254.0.0/16`) remain blocked even with `allowed_ips`. | +| What you can change | Add `allowed_ips` (CIDR notation) to an endpoint to permit connections to specific private IP ranges. | +| Risk if relaxed | Without SSRF protection, a misconfigured policy could allow the agent to reach cloud metadata services (`169.254.169.254`), internal databases, or other infrastructure endpoints through DNS rebinding. | +| Recommendation | Use `allowed_ips` only for known internal services. Scope the CIDR as narrowly as possible (for example, `10.0.5.20/32` for a single host). Loopback and link-local are always blocked regardless of `allowed_ips`. | + +### Operator Approval + +When the agent requests an endpoint not in the policy, OpenShell blocks it and surfaces the request in the TUI for operator review. +The system merges approved endpoints into the sandbox's policy as a new durable revision. + +| Aspect | Detail | +|---|---| +| Default | Enabled. The proxy blocks unlisted endpoints and requires approval. | +| What you can change | Approved endpoints persist across sandbox restarts within the same sandbox instance. They reset when the sandbox is destroyed and recreated. | +| Risk if relaxed | Approving an endpoint permanently widens the running sandbox's policy. Review each request before approving. | +| Recommendation | Use operator approval for exploratory work. For recurring endpoints, add them to the policy YAML with appropriate binary and path restrictions. To reset all approved endpoints, destroy and recreate the sandbox. | + +## Filesystem Controls + +### Landlock LSM + +Landlock enforces filesystem access at the kernel level. +Paths listed in `read_only` receive read-only access. +Paths listed in `read_write` receive full access. +All other paths are inaccessible. + +| Aspect | Detail | +|---|---| +| Default | `compatibility: best_effort`. Uses the highest kernel ABI available. The system skips missing paths with a warning. If the kernel does not support Landlock, the sandbox continues without filesystem restrictions. | +| What you can change | Set `compatibility: hard_requirement` to abort sandbox startup if Landlock is unavailable or any configured path cannot be opened. | +| Risk if relaxed | On kernels without Landlock (pre-5.13), or when all paths fail to open, the sandbox runs without kernel-level filesystem restrictions. The agent can access any file the process user can access. | +| Recommendation | Use `best_effort` for development. Use `hard_requirement` in environments where any gap in filesystem isolation is unacceptable. Run on Ubuntu 22.04+ or any kernel 5.13+ for Landlock support. | + +### Read-Only vs Read-Write Paths + +| Aspect | Detail | +|---|---| +| Default | System paths (`/usr`, `/lib`, `/etc`, `/var/log`) are read-only. Working paths (`/sandbox`, `/tmp`) are read-write. `/app` is conditionally included if it exists. | +| What you can change | Add or remove paths in `filesystem_policy.read_only` and `filesystem_policy.read_write`. | +| Risk if relaxed | Making system paths writable lets the agent replace binaries, modify TLS trust stores, or change DNS resolution. Validation rejects broad read-write paths (like `/`). | +| Recommendation | Keep system paths read-only. If the agent needs additional writable space, add a specific subdirectory. | + +### Path Validation + +OpenShell validates policies before they take effect. + +| Constraint | Behavior | +|---|---| +| Paths must be absolute (start with `/`). | Rejected with `INVALID_ARGUMENT`. | +| Paths must not contain `..` traversal. | Rejected with `INVALID_ARGUMENT`. | +| Read-write paths must not be overly broad (for example, `/` alone). | Rejected with `INVALID_ARGUMENT`. | +| Each path must not exceed 4096 characters. | Rejected with `INVALID_ARGUMENT`. | +| Combined `read_only` + `read_write` paths must not exceed 256. | Rejected with `INVALID_ARGUMENT`. | + +## Process Controls + +### Privilege Drop + +The sandbox process runs as a non-root user after explicit privilege dropping. + +| Aspect | Detail | +|---|---| +| Default | `run_as_user: sandbox`, `run_as_group: sandbox`. The supervisor calls `setuid()`/`setgid()` with post-condition verification: confirms the effective UID/GID match the target and that `setuid(0)` fails (root cannot be re-acquired). | +| What you can change | Set `run_as_user` and `run_as_group` in the `process` section. Validation rejects root (`root` or `0`). | +| Risk if relaxed | Running as a higher-privilege user increases the impact of container escape vulnerabilities. | +| Recommendation | Keep the `sandbox` user. Do not attempt to set root. | + +### Seccomp Filters + +A BPF seccomp filter restricts which socket domains the sandbox process can use. + +| Aspect | Detail | +|---|---| +| Default | The filter allows `AF_INET` and `AF_INET6` (for proxy communication) and blocks `AF_NETLINK`, `AF_PACKET`, `AF_BLUETOOTH`, and `AF_VSOCK` with `EPERM`. The sandbox sets `PR_SET_NO_NEW_PRIVS` before applying the filter. | +| What you can change | This is not a user-facing knob. OpenShell enforces it automatically. | +| Risk if relaxed | `AF_NETLINK` allows manipulation of routing tables and firewall rules. `AF_PACKET` enables raw packet capture. `AF_VSOCK` enables VM socket communication. | +| Recommendation | No action needed. OpenShell enforces this automatically. | + +### Enforcement Application Order + +The sandbox supervisor applies enforcement in a specific order during process startup. +This ordering is intentional: privilege dropping needs `/etc/group` and `/etc/passwd`, which Landlock subsequently restricts. + +1. Network namespace entry (`setns`). +2. Privilege drop (`initgroups` + `setgid` + `setuid`). +3. Landlock filesystem restrictions. +4. Seccomp socket domain filters. + +## Inference Controls + +### Routed Inference through `inference.local` + +The proxy intercepts HTTPS CONNECT requests to `inference.local` and routes matching inference API requests through the sandbox-local router. +The agent never receives the provider API key. + +| Aspect | Detail | +|---|---| +| Default | Always active. The proxy handles `inference.local` before OPA policy evaluation. The gateway injects credentials on the host side. | +| What you can change | Configure inference routes with `openshell inference set`. | +| Risk if bypassed | If an inference provider's host is added directly to `network_policies`, the agent could reach it with a stolen or hardcoded key, bypassing credential isolation. | +| Recommendation | Do not add inference provider hosts to `network_policies`. Use OpenShell inference routing instead. | + +## Gateway Security + +### mTLS + +Communication between the CLI, sandbox pods, and the gateway is secured by mutual TLS. +OpenShell generates a cluster CA at bootstrap and distributes it through Kubernetes secrets. + +| Aspect | Detail | +|---|---| +| Default | mTLS required. Both client and server present certificates that the cluster CA signed. | +| What you can change | Enable dual-auth mode (`allow_unauthenticated=true`) for Cloudflare Tunnel deployments, or disable TLS entirely for trusted reverse-proxy setups. | +| Risk if relaxed | Dual-auth mode accepts clients without certificates and defers authentication to the HTTP layer (Cloudflare JWT). Disabling TLS removes transport-level authentication entirely. | +| Recommendation | Use mTLS (the default) unless deploying behind Cloudflare or a trusted reverse proxy. | + +### SSH Tunnel Authentication + +SSH connections to sandboxes pass through the gateway's HTTP CONNECT tunnel with token-based authentication and HMAC-SHA256 handshake verification (NSSH1 protocol). + +| Aspect | Detail | +|---|---| +| Default | Session tokens expire after 24 hours. Concurrent connections are limited to 10 per token and 20 per sandbox. | +| What you can change | Configure `ssh_session_ttl_secs`. Set to 0 for no expiry. | +| Risk if relaxed | Longer TTLs or no expiry increase the window for stolen token reuse. Higher connection limits increase the blast radius of a compromised token. | +| Recommendation | Keep the 24-hour default. Monitor connection counts through the TUI. | + +## Common Mistakes + +**Omitting `protocol: rest` on REST API endpoints.** +Without `protocol: rest`, the proxy uses L4-only enforcement. +It allows the TCP stream through after checking host, port, and binary, but cannot inspect individual HTTP requests. +Add `protocol: rest` with specific `rules` to enable per-request method and path control. + +**Using `access: full` when finer rules would suffice.** +`access: full` with `protocol: rest` enables inspection but allows all HTTP methods and paths. +Use `access: read-only` or explicit `rules` to restrict what the agent can do at the HTTP level. + +**Adding endpoints permanently when operator approval would suffice.** +Operator-approved endpoints persist within the sandbox instance but reset on re-creation. +Adding endpoints to the policy YAML makes them permanently reachable across all instances. + +**Using broad binary globs.** +A glob like `/**` allows any binary to reach the endpoint, defeating binary-scoped enforcement. +Scope globs to specific directories (for example, `/sandbox/.vscode-server/**`). + +**Skipping TLS termination on HTTPS APIs.** +Setting `tls: skip` disables credential injection and L7 inspection. +Use the default auto-detect behavior unless the upstream requires client-certificate mTLS. + +**Setting `enforcement: enforce` before auditing.** +Jumping to `enforce` without first running in `audit` mode risks breaking the agent's workflow. +Start with `audit`, review the logs, and switch to `enforce` once you have validated the rules. + +## Related Topics + +- {doc}`../sandboxes/policies` for applying and iterating on sandbox policies. +- {doc}`../reference/policy-schema` for the full field-by-field YAML reference. +- {doc}`../reference/default-policy` for the built-in default policy breakdown. +- {doc}`../reference/gateway-auth` for gateway authentication details. +- {doc}`../about/architecture` for the system architecture. From 6e4d5599cb38b5e839944f3e1bdb9805675b4f16 Mon Sep 17 00:00:00 2001 From: Miyoung Choi Date: Tue, 31 Mar 2026 14:36:38 -0700 Subject: [PATCH 2/3] docs: improve per style guide --- docs/security/best-practices.md | 44 ++++++++++++++++----------------- 1 file changed, 21 insertions(+), 23 deletions(-) diff --git a/docs/security/best-practices.md b/docs/security/best-practices.md index 16697abd5..b7b82a5e2 100644 --- a/docs/security/best-practices.md +++ b/docs/security/best-practices.md @@ -73,6 +73,8 @@ You can update dynamic controls on a running sandbox with `openshell policy set` ## Network Controls +The CONNECT proxy and OPA policy engine enforce all network controls at the gateway level. + ### Deny-by-Default Egress Every outbound connection from the sandbox goes through the CONNECT proxy. @@ -172,6 +174,8 @@ The system merges approved endpoints into the sandbox's policy as a new durable ## Filesystem Controls +Landlock LSM restricts which paths the sandbox process can read or write at the kernel level. + ### Landlock LSM Landlock enforces filesystem access at the kernel level. @@ -188,6 +192,8 @@ All other paths are inaccessible. ### Read-Only vs Read-Write Paths +The policy separates filesystem paths into read-only and read-write groups. + | Aspect | Detail | |---|---| | Default | System paths (`/usr`, `/lib`, `/etc`, `/var/log`) are read-only. Working paths (`/sandbox`, `/tmp`) are read-write. `/app` is conditionally included if it exists. | @@ -209,6 +215,8 @@ OpenShell validates policies before they take effect. ## Process Controls +The sandbox supervisor drops privileges, applies seccomp filters, and enforces process-level restrictions during startup. + ### Privilege Drop The sandbox process runs as a non-root user after explicit privilege dropping. @@ -243,6 +251,8 @@ This ordering is intentional: privilege dropping needs `/etc/group` and `/etc/pa ## Inference Controls +OpenShell routes all inference traffic through the gateway to isolate provider credentials from the sandbox. + ### Routed Inference through `inference.local` The proxy intercepts HTTPS CONNECT requests to `inference.local` and routes matching inference API requests through the sandbox-local router. @@ -257,6 +267,8 @@ The agent never receives the provider API key. ## Gateway Security +The gateway secures communication between the CLI, sandbox pods, and external clients with mutual TLS and token-based authentication. + ### mTLS Communication between the CLI, sandbox pods, and the gateway is secured by mutual TLS. @@ -282,30 +294,16 @@ SSH connections to sandboxes pass through the gateway's HTTP CONNECT tunnel with ## Common Mistakes -**Omitting `protocol: rest` on REST API endpoints.** -Without `protocol: rest`, the proxy uses L4-only enforcement. -It allows the TCP stream through after checking host, port, and binary, but cannot inspect individual HTTP requests. -Add `protocol: rest` with specific `rules` to enable per-request method and path control. - -**Using `access: full` when finer rules would suffice.** -`access: full` with `protocol: rest` enables inspection but allows all HTTP methods and paths. -Use `access: read-only` or explicit `rules` to restrict what the agent can do at the HTTP level. - -**Adding endpoints permanently when operator approval would suffice.** -Operator-approved endpoints persist within the sandbox instance but reset on re-creation. -Adding endpoints to the policy YAML makes them permanently reachable across all instances. - -**Using broad binary globs.** -A glob like `/**` allows any binary to reach the endpoint, defeating binary-scoped enforcement. -Scope globs to specific directories (for example, `/sandbox/.vscode-server/**`). - -**Skipping TLS termination on HTTPS APIs.** -Setting `tls: skip` disables credential injection and L7 inspection. -Use the default auto-detect behavior unless the upstream requires client-certificate mTLS. +The following patterns weaken security without providing meaningful benefit. -**Setting `enforcement: enforce` before auditing.** -Jumping to `enforce` without first running in `audit` mode risks breaking the agent's workflow. -Start with `audit`, review the logs, and switch to `enforce` once you have validated the rules. +| Mistake | Why it matters | What to do instead | +|---------|---------------|-------------------| +| Omitting `protocol: rest` on REST API endpoints | Without `protocol: rest`, the proxy uses L4-only enforcement. It allows the TCP stream through after checking host, port, and binary, but cannot inspect individual HTTP requests. | Add `protocol: rest` with specific `rules` to enable per-request method and path control. | +| Using `access: full` when finer rules would suffice | `access: full` with `protocol: rest` enables inspection but allows all HTTP methods and paths. | Use `access: read-only` or explicit `rules` to restrict what the agent can do at the HTTP level. | +| Adding endpoints permanently when operator approval would suffice | Adding endpoints to the policy YAML makes them permanently reachable across all instances. | Use operator approval. Approved endpoints persist within the sandbox instance but reset on re-creation. | +| Using broad binary globs | A glob like `/**` allows any binary to reach the endpoint, defeating binary-scoped enforcement. | Scope globs to specific directories (for example, `/sandbox/.vscode-server/**`). | +| Skipping TLS termination on HTTPS APIs | Setting `tls: skip` disables credential injection and L7 inspection. | Use the default auto-detect behavior unless the upstream requires client-certificate mTLS. | +| Setting `enforcement: enforce` before auditing | Jumping to `enforce` without first running in `audit` mode risks breaking the agent's workflow. | Start with `audit`, review the logs, and switch to `enforce` once you have validated the rules. | ## Related Topics From a3966013304d7665f4d4ce97756842d91c7bf87e Mon Sep 17 00:00:00 2001 From: Miyoung Choi Date: Tue, 31 Mar 2026 14:49:23 -0700 Subject: [PATCH 3/3] docs: add xref to nemoclaw --- docs/security/best-practices.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/security/best-practices.md b/docs/security/best-practices.md index b7b82a5e2..a54896f5a 100644 --- a/docs/security/best-practices.md +++ b/docs/security/best-practices.md @@ -34,6 +34,10 @@ This page documents every configurable control, its default, what it protects, a For the full policy YAML schema, refer to the {doc}`../reference/policy-schema`. For the architecture of each enforcement layer, refer to {doc}`../about/architecture`. +:::{seealso} +If you use [NemoClaw](https://github.com/NVIDIA/NemoClaw) to run OpenClaw assistants, its [Security Best Practices](https://docs.nvidia.com/nemoclaw/latest/security/best-practices.html) guide covers additional entrypoint-level controls, policy presets, provider trust tiers, and posture profiles specific to the NemoClaw blueprint. +::: + ## Enforcement Layers OpenShell applies security controls at two enforcement points. @@ -312,3 +316,4 @@ The following patterns weaken security without providing meaningful benefit. - {doc}`../reference/default-policy` for the built-in default policy breakdown. - {doc}`../reference/gateway-auth` for gateway authentication details. - {doc}`../about/architecture` for the system architecture. +- NemoClaw [Security Best Practices](https://docs.nvidia.com/nemoclaw/latest/security/best-practices.html) for entrypoint-level controls (capability drops, PATH hardening, build toolchain removal), policy presets, provider trust tiers, and posture profiles.