{"resourceId":"lasso-openshell-policy-permitted-exfiltration-20260423","versions":[{"version":"external-8577ef66bdee1e4e2125bf294d18168086b593f5141a3161e531ce61921b7266","resource":{"id":"lasso-openshell-policy-permitted-exfiltration-20260423","title":"Lasso Security research shows data exfiltration from NVIDIA NemoClaw/OpenShell sandboxes through default policy-permitted egress (npm, node, git/gh)","organization":"Lasso Security","sector":"Security research (cross-sector)","geography":"Global","publishedAt":"2026-04-23","publicationDate":"2026-04-23","eventDate":null,"sourceName":"Lasso Security blog","sourceLabel":"Lasso Security research blog","sourceUrl":"https://www.lasso.security/blog/sandboxed-ai-agents-attack-surface","evidenceClass":"independent-research","outcomeClass":"cautionary","topics":["developers-agents","data-security"],"finding":"Lasso demonstrated two attack scenarios in which an agent inside an OpenShell sandbox, using default egress policy, installed a malicious npm package and exfiltrated credentials and files (including plaintext API keys) via allowlisted gh/git paths, with cron-based persistence in the second scenario. Lasso reports NVIDIA's disclosure program deemed the scenarios out of scope. Researchers manually adjusted some default policies (e.g., adding api.openai.com, node path, installing gh) to make the environment functional.","sledRelevance":"Newly relevant because VAST's October 21, 2026 Agent Sandbox Foundation Stack builds on NemoClaw/OpenShell; public-sector buyers evaluating that stack need to know sandbox isolation does not stop misuse of permitted egress. Not VAST-specific and not a SLED deployment.","evidence":"Proof-of-concept security research by a security vendor with described attack steps and example packages/PRs; no systematic measurement. Published April 2026, predating the VAST stack; included as independent scrutiny of a component the new stack depends on.","architectureImplications":"Data and storage layers beneath a sandbox cannot compensate for egress paths the runtime allows; persistent agent workspaces could retain poisoned configuration or cron persistence across sessions unless snapshots are inspected.","governanceImplications":"Egress allowlists need governance review equivalent to firewall change control; supply-chain controls (package allowlists, registry mirrors) are prerequisites for agent pilots.","securityPrivacyImplications":"Plaintext credentials reachable by the agent process were exfiltrated; any file the agent can read is at risk. OpenShell egress logs could be read by the attacker to refine exfiltration.","caveats":"Tested an early/alpha NemoClaw/OpenShell release in April 2026 with some manual configuration changes; later versions may differ. Lasso sells AI security products (potential interest). Findings concern NVIDIA components, not VAST software; NVIDIA-runtime coverage belongs primarily to the NVIDIA stream.","streamIds":["vast-data"],"roles":{"sales":"This research is a caution to carry into any VAST agent-sandbox conversation: a sandbox can behave exactly as configured and still leak data through allowed tools. Raising it early builds credibility with public-sector CISOs. Do not use it to disparage partners; use it to frame a joint security validation. Discovery should ask how the customer controls package installs and source-control egress for agents, and who approves allowlist changes.","engineering":"Technically, Lasso showed that binary-scoped egress rules permitting npm, node and git/gh are enough for credential exfiltration and persistence. Any VAST-based agent design must therefore pair runtime policy with package allowlisting, registry mirrors, secret brokering instead of plaintext keys, and inspection of persistent workspaces or snapshots for planted cron jobs. Re-test against current OpenShell versions, because the research used an early release with manual fixes.","delivery":"For delivery, this turns into concrete pre-pilot controls: a change-controlled egress allowlist, a mirrored package registry, scoped credentials and a recurring red-team test of agent sandboxes. Persistent agent workspaces need scanning or reset procedures so poisoned configuration does not carry across sessions. Assign ownership to the security team, and make passing the red-team test an explicit go/no-go gate before agents touch agency or university data."},"roleDetails":{"sales":{"customerProblem":"Agencies adopting sandboxed agents may assume isolation prevents data loss when permitted tools can still exfiltrate data.","stakeholders":["CISO","Application security lead","AI program owner"],"discoveryQuestions":["Which binaries and domains will agents be allowed to reach?","How are agent credentials stored and scoped?","Who approves changes to agent egress policy?"],"valueHypothesis":"Addressing egress and supply-chain risk upfront can shorten security approval for agent pilots; no measured benefit is claimed.","potentialEngagement":"A short red-team assessment of an agent sandbox configuration before a pilot.","unsupportedClaims":["That VAST software is vulnerable","That current OpenShell releases remain exploitable in the same way","Any statement of incident rates"]},"engineering":{"fit":"Applies to any NemoClaw/OpenShell deployment, including the VAST Foundation Stack.","architectureIntegration":"Controls sit at the runtime egress policy, package registry and secret-management layers above persistent storage.","prerequisites":["Inventory of allowed binaries and domains","Package registry mirror","Secret broker"],"constraints":["Early release tested with manual configuration","Proof-of-concept, not systematic testing"],"security":"Policy-permitted channels (npm, node, git/gh) enabled credential theft and persistence; plaintext keys were exposed.","proofOfValue":["Replay both attack scenarios on the current release","Verify persistent workspace scans detect planted cron jobs","Confirm secrets are not readable as plaintext by the agent"]},"delivery":{"work":"Implement and test egress, supply-chain and credential controls for agent sandboxes.","dependencies":["Security team capacity","Runtime version upgrades","Developer tooling policies"],"ownership":"Customer security engineering team.","skillsAdoption":"Teams need agent-specific threat modeling and policy-as-code skills.","governanceCheckpoints":["Egress allowlist change control","Pre-pilot red-team sign-off"],"acceptanceCriteria":["Proposed: both published attack scenarios fail on the deployed configuration","Proposed: no plaintext credentials reachable from the sandbox"],"risks":["Credential theft via allowed tools","Persistence across sessions in durable workspaces","False confidence from sandbox isolation"]}},"retrievedAt":"2026-10-29T22:06:10-05:00","enrichedAt":"2026-10-29T22:13:03-05:00","enrichmentBasis":"retrieved source","accessibilityWorkforceImplications":"Requires security staff with agent threat-modeling skills; no accessibility content.","procurementImplications":"Contracts for agent platforms should require vendor documentation of what sandboxes do and do not protect against, and support for third-party red-team testing.","operatingModelImplications":"Agent egress policy becomes an ongoing security operations responsibility, not a one-time configuration.","peerReview":"unknown","sourceVerification":{"openedUrl":"https://www.lasso.security/blog/sandboxed-ai-agents-attack-surface","referenceExcerpt":"No policy was violated; the sandbox behaved exactly as configured.","promptVersion":"sled-research-v4.0","model":null,"basis":"agent-reported inspection"}}}]}