NVIDIANVIDIA-Certified Professional: Agentic AI2026-109.1 Design and enforce system security and audit trails.
Confine code, files, and outbound traffic
Completed by the knowledge check
Learning objective
Sandbox code execution, filesystem access, and network egress.
Core idea
Generated code is an executable proposal from an untrusted source. Giving it a working directory or a warning prompt does not constrain the system calls, files, and destinations it can reach. Put enforcement outside that code, then test each resource boundary independently.
A NeMo Agent Toolkit agent sends generated code through the code_execution function to the execution server configured by its uri field; see 1.8.2 for timeouts and capacity. The documented timeout and output limits bound execution duration and returned text; apply filesystem and egress controls to the execution server itself.
NVIDIA OpenShell applies network, filesystem, process, and provider-credential controls around a sandbox workload. This lesson uses its Linux sandbox mechanisms to make the boundaries concrete. Tool permissions remain a separate control: see 9.1.1. A sandbox limits what executable code can do even after a tool call has been admitted.
Choose restrictions from the workload’s required capabilities. A data-analysis task that needs a temporary output directory and one internal API should not inherit the developer’s home directory and unrestricted internet access merely because that environment makes dependencies easier to install.
How it works
Constrain the process that executes code
OpenShell’s sandbox supervisor drops privileges and applies seccomp filters during startup. The policy’s process.run_as_user and process.run_as_group select workload identities; numeric selectors must be non-root. Driver behavior matters: Docker and Podman can use the image’s OCI USER as a fallback, whereas Kubernetes uses the identity configured for its driver. Inspect the selected driver rather than assuming one identity-setting path fits every deployment.
Seccomp constrains operations at the system-call layer. OpenShell documents restrictions on operations including mount manipulation, cross-process observation, and filter evasion. The supervisor also disables core dumps with RLIMIT_CORE=0 and applies Linux dumpability hardening with PR_SET_DUMPABLE=0. These controls reduce capabilities and exposure; application argument validation addresses a different boundary.
Process and filesystem controls are fixed at sandbox creation. Changing them requires recreating the sandbox. Treat a request for broader filesystem access as a deployment change with a fresh validation run, rather than assuming a live network-policy update changes the execution environment too.
Give files explicit access modes
OpenShell uses Landlock to restrict filesystem access. In a policy document, filesystem_policy.read_only identifies readable inputs, and filesystem_policy.read_write identifies writable locations. Keep source inputs read-only and allocate a specific output directory. Paths must be absolute; parent traversal and a read-write entry for / are rejected.
The include_workdir default deserves attention. When filesystem_policy is omitted, it is true; when that section is present, it defaults to false. Define it explicitly when the working directory’s visibility matters. When the effective policy has at least one network rule, OpenShell also adds baseline filesystem paths; review the effective policy rather than treating your two lists as the entire filesystem configuration.
The mandatory baseline requires Landlock ABI v3 or later, introduced in Linux 6.2, or a qualifying backport. Startup fails when that baseline cannot be enforced. The additional policy has its own landlock.compatibility setting: best_effort can run without its filesystem rules when enforcement fails, with a high-severity finding; hard_requirement fails startup instead.
Even hard_requirement skips individual missing or inaccessible paths. Inspect the Landlock ruleset built event’s applied and skipped path counts, and verify access against real inputs and outputs. Selecting the stricter setting does not prove that every intended path existed when the rules were built.
Restrict destinations and requests
OpenShell’s CONNECT proxy and OPA policy engine evaluate network_policies. A named rule pairs binaries with endpoints; the destination host, port, and executable identity determine whether a connection is admitted. Unmatched destinations are denied. The Linux network boundary prevents a process from bypassing the proxy merely by ignoring proxy environment variables.
Destination admission and request authorization are different decisions. An endpoint without request rules can permit any HTTP method and path once admitted. For a REST API, set protocol: rest and narrow rules or an appropriate access preset. Use enforcement: enforce to block violating requests. The documented default is audit: it records violations and forwards them.
An admitted destination still reaches request authorization, where only enforce blocks a violating request.
This illustrative policy fragment permits read-only REST requests from the analysis job’s Python interpreter to one service:
network_policies:
reference_api:
binaries:
- path: /usr/bin/python3
endpoints:
- host: reference.example.com
port: 443
protocol: rest
access: read-only
enforcement: enforceThe host and executable are illustrative and must match the deployed workload. access: read-only constrains REST methods, but does not make every read harmless: an allowed URL can still carry sensitive data. Narrow paths where the task permits it, and retain resource-server authorization. If a denial breaks legitimate work, inspect the denied host, port, binary, or request rule and repair that specific mismatch. Opening all egress removes the boundary that produced the useful diagnosis.
Key distinctions and trade-offs
Choose each control for the resource it mediates:
| Boundary | Mechanism | Deciding condition | Operational cost |
|---|---|---|---|
| Code execution | Non-root process identity and seccomp filters | Generated code must not inherit privileged operations | Dependencies can fail when they require restricted operations; validate the workload image |
| Filesystem | filesystem_policy, Landlock, and landlock.compatibility | Inputs and outputs need different permissions | Missing paths and kernel support can prevent the intended policy; recreation is required for changes |
| Network connection | network_policies.binaries and endpoints | Only task-specific clients and destinations should be reachable | Dependency downloads and redirected endpoints need deliberate policy decisions |
| API request | protocol: rest, rules or access, and enforcement: enforce | A reachable service exposes both allowed reads and dangerous writes | Request inspection and policy maintenance add work; audit only observes violations |
Network rules can change dynamically through openshell policy update or openshell policy set. That flexibility helps repair a specific missing endpoint, but it also means policy-change authority must remain outside the agent’s unrestricted control. A sandbox that can grant itself arbitrary egress defeats its intended restriction.
Architecture / decision scenario
A manufacturing analytics assistant generates Python reports from supplier measurements. Each job reads a 200 MB input set, writes a report, and queries one approved reference API. The factory permits no internet data export. The platform team proposes a general development container with the shared project directory writable and outbound access allowed for package installation.
The platform security owner chooses a prepared workload image and OpenShell policy instead. Generated code runs as a non-root identity under the documented seccomp restrictions. The measurements directory is read-only; only the job’s output directory and required temporary paths are writable. landlock.compatibility: hard_requirement prevents starting with an unenforced additional filesystem policy, while startup checks confirm that the intended paths were applied.
Network rules admit only the deployed client and reference endpoint. REST request inspection uses enforcement: enforce, so allowing reads does not also admit update requests. The prepared image removes the job’s need to fetch packages. Keeping the API in audit mode would preserve compatibility but violate the no-export constraint if a prohibited request were forwarded.
The release test attempts an input overwrite, access to an unapproved file, a privileged operation, an unlisted destination, and a disallowed REST write. Each must fail at its corresponding boundary. If a legitimate reference lookup fails, the integration owner repairs the exact rule; the platform owner recreates the sandbox only when the static controls need changing.
Common exam traps
- A container name proves confinement: Inspect process, filesystem, and network enforcement separately.
- An allowed hostname permits only safe operations: Host admission does not impose REST method or path restrictions.
auditblocks violations: It forwards traffic; selectenforceafter validating the rules.hard_requirementguarantees every listed path was applied: Missing or inaccessible individual paths are still skipped; inspect startup results.- A live policy update changes every control: Filesystem and process changes require sandbox recreation.
What to remember
Constrain generated code outside the model through non-root execution, syscall restrictions, explicit file access, and controlled egress. Verify the effective filesystem rules and distinguish destination admission from request inspection. In OpenShell, audit observes request violations while enforce blocks them.
Knowledge check
An OpenShell policy admits a reporting job’s Python interpreter to api.internal.example:443 with protocol: rest and access: read-only, and sets nothing else on that endpoint. A release test sends a DELETE request from the job: the sandbox log records a violation, and the API deletes the record. Which change makes the sandbox block that request?
binaries to the exact interpreter pathenforcement: enforce on the endpointlandlock.compatibility: hard_requirement in the policyenforcement defaults to audit , which logs a request that breaks the endpoint’s rules and forwards it; enforce blocks it. The logged violation shows the rule is loaded, so recreation changes nothing, the binary match governs whether the connection is admitted rather than which methods pass, and Landlock governs files, not HTTP requests.Generated code ran in an OpenShell sandbox whose policy had no filesystem_policy section. To protect inputs, the team adds one, with /data/measurements under read_only and /data/out under read_write. Startup succeeds and the Landlock ruleset built event shows no skipped paths, but scripts can no longer write scratch files in the sandbox’s working directory. What explains the change?
best_effort compatibility skipped the working directory as unavailableinclude_workdir now defaults to false because the section is presentfilesystem_policy is omitted, include_workdir is true ; once the section is present it defaults to false , so the working directory is no longer writable unless listed or the flag is set. An unsupported kernel makes startup fail rather than fall back, nothing was skipped, and the working directory was never a listed path; seccomp restricts operations such as mount manipulation, not ordinary file paths.A running OpenShell sandbox needs read access to a new /data/reference directory and one new HTTPS endpoint. The operator applies both changes with openshell policy update. The endpoint now works, but the directory remains unreadable. What must the operator do to grant the directory access?
filesystem_policy.read_onlyopenshell policy set instead of an updateread_write instead of read_only and update againlandlock.compatibility: hard_requirement and update againpolicy update or policy set changes on a running sandbox; filesystem and process controls are locked at creation and change only when the sandbox is recreated. Replacing the full policy, changing the access mode or the compatibility setting are all still live updates, so none of them reaches the Landlock rules already in force.After a dependency upgrade, a sandboxed report job’s lookups to its one approved reference API are denied. The denial names the expected host and port and the binary /opt/venv/bin/python3.12; the policy rule lists /usr/bin/python3. Egress must stay limited to that one client and endpoint. What is the appropriate fix?
enforcement: audit on the endpoint until lookups succeedaudit relaxes request rules on an admitted connection rather than fixing admission itself.An OpenShell policy sets landlock.compatibility: hard_requirement and lists four filesystem paths. The sandbox starts on Linux 6.8 while one listed read-only path, a mount, is absent; the other three exist. What happens?
best_effort runs without the filesystem rules and hard_requirement refuses to start. The stricter setting therefore does not prove every intended path was applied, which is why the Landlock ruleset built event’s applied and skipped counts belong in the release check.