Infrastructure
nFOX's Blockhouse Sandbox: What to Verify Before Trusting It With Self-Hosted Models
nFOX plans to open-source Blockhouse, a sandbox for AI workloads, but the announcement leaves kernel requirements, policy language, audit retention and failure behavior unspecified. Here is what to test first.
On October 15, 2026, nFOX announced plans to open-source Blockhouse, a sandbox designed to restrict what AI workloads can access and do. The report says Blockhouse was in beta for qualified enterprise evaluations; it does not provide an open-source release date or repository link. 1 For teams weighing it as a self-hosted LLM security control, the key question is what Blockhouse enforces in practice, not just what the announcement describes.
The nFOX Platform was available when the report was published, while Blockhouse was available in beta for qualified enterprise evaluations. nFOX said it planned to release Blockhouse under the Apache 2.0 license, but the report gives no release date. 1
The source does not report comparative security or performance results. It does mention Nvidia's OpenShell as a similar technology focused on securing agents, and says nFOX intends to incorporate it. 1 An evaluation should therefore focus on the controls nFOX describes and the operational details the report leaves unspecified. For a related example of a sandbox announcement that arrived with few technical details, see AWS's decision model and sandbox for agents.
What changed, and why it matters for self-hosted models
nFOX launched its model-management platform and announced plans to open-source Blockhouse on October 15, 2026. The company describes Blockhouse as using Linux security mechanisms below the application layer to limit AI workloads' access and actions. 1
That design places enforcement outside instructions given to a model. It is not, by itself, an independent security evaluation. Teams still need to establish which kernel mechanisms are used, which environments they cover, and what happens when protection fails. 1
The report describes these controls: privileges removed by default and restored selectively through policy; restrictions on file access and approved network destinations; a monitored communications channel; model-file integrity checks; containment-event records; and reports when a host cannot provide expected protection. 1
Those are control categories, not proof that every path into or out of a model workload is mediated. The report does not specify kernel requirements, policy language, Porthole's full request-handling scope, audit retention, performance overhead, or failure behavior. 1
Blockhouse sandbox controls: what nFOX claims versus what's unverified
| Control area | What nFOX claims 1 | What the report leaves unspecified 1 |
|---|---|---|
| Privileges and filesystem | Privileges are removed by default; policies enforced at the kernel level selectively restore access | Policy syntax and how exceptions are scoped, reviewed, and revoked |
| Network and requests | Workloads can contact approved destinations using a whitelist; requests pass through a monitored channel called Porthole | Which request types Porthole covers, who reviews them, and what is logged |
| File integrity | Approved model files are sealed with SHA-256 hashes; serving halts if they change | How files are approved, where hashes are stored, and which files are covered |
| Host protection | The system reports when a host cannot provide expected protection and records containment events | Recovery behavior after a failure is detected |
nFOX acknowledges a configuration risk: an administrator could mistakenly authorize a malicious destination. 1 That puts policy administration inside the threat model. A restrictive default helps only if teams can review exceptions, understand their scope, and reverse them safely.
How the platform supports configuration and audit
The nFOX Platform offers a console for evaluating, deploying, and monitoring models across cloud virtual machines, rented GPU hosts, and on-premises Linux servers equipped with Nvidia GPUs. Teams can check model configurations, verify files, and test models with adversarial prompts before deployment. 1
For production workloads, the platform provides OpenAI-compatible endpoints. The report says operational evidence can feed existing endpoint-detection and security-information-management systems, and that audit records use JSON and Parquet formats. It does not identify specific integrations or an audit-retention period. 1
Containment-event records and reports of unavailable host protection may help operators investigate events and identify gaps, but the announcement does not claim complete incident coverage. 1 Treat these signals as one input among others. In a proof of concept, check whether the records contain the fields responders need and correlate with the rest of the stack; the report names output formats, not operational fit. 1 A sandbox is also only one layer of workload protection; AI security does not stop at the prompt, and Kubernetes and GPU teams have further layers to verify.
What the integrity check actually covers
Before serving, Blockhouse seals approved model files with SHA-256 hashes and halts serving if those files change. 1 That is the stated behavior; the report does not describe the approval process or the full scope of files covered.
Ask how legitimate updates are reauthorized and resealed, where hashes are stored, and whether the integrity boundary includes only model files or other serving artifacts as well. The report does not answer those questions. 1
A focused evaluation plan for an AI model sandbox
The report lists vLLM, SGLang, and llama.cpp as supported inference engines. It provides no reported overhead, throughput, latency, or containment-effectiveness results for them. 1 Engine support alone does not establish whether the sandbox's operational cost fits a particular deployment.
Run these tests before treating Blockhouse as production-ready:
- Privileges and filesystem — Verify the default restrictions, test permitted file access, and attempt access outside policy. 1
- Network and requests — Test approved and denied destinations, then map how Porthole handles and logs the request types in scope. 1
- Integrity — Change a sealed file and check whether serving halts; separately test the legitimate update-and-reseal process. 1
- Host protection and recovery — Trigger the host-protection failure condition and document what operators see and what happens to serving. The report confirms that Blockhouse reports when a host cannot provide expected protection, but does not describe recovery behavior. 1
Include policy changes and rollback in the evaluation. A control that blocks a bad action can still be difficult to operate if mistaken rules are hard to identify or reverse. 1
Ask nFOX for the supported kernel mechanisms and versions, host prerequisites, policy language, Porthole's mediation scope, audit retention, and documented failure behavior. The report does not provide these details or a performance-overhead figure. 1
What the announcement doesn't prove about open-source AI sandboxes
The source reports no benchmark results for containment effectiveness, latency, throughput, or resource overhead. It also makes no compliance, certification, data-residency, uptime, or SLA claims for Blockhouse. 1
Availability is a separate consideration: the nFOX Platform was available at publication, while Blockhouse was in beta for qualified enterprise evaluations and an open-source release was planned but not completed. 1 Separate what can be evaluated through the platform or beta from what can be inspected only after code is released.
A planned Apache 2.0 license is not a security result. Open-sourcing could make code inspection possible, but does not establish that the control fits a particular deployment. Verify the released code, supported host environments, threat-model limits, and observed behavior before making a production decision. 1
What to do next: AI agent access controls and policy lifecycle
Build an evaluation checklist around the areas nFOX says Blockhouse addresses: workload privileges, filesystem access, network destinations, and model-file integrity. 1 Require a policy lifecycle covering authoring, review, approval, deployment, changes, and rollback; the announcement does not describe such a process.
Use adversarial prompts in pre-deployment testing, a capability the report says the nFOX Platform supports. Separately, test attempted policy violations as part of your own evaluation. 1 Capture containment events and audit output, then check whether JSON or Parquet records can be ingested by your monitoring stack. 1
If agents with tool access are in scope, the access-control questions overlap with those raised in what security teams need to control first when coding agents connect to Ghidra and IDA. Sandboxing a self-hosted workload is also one layer; teams that additionally send traffic to hosted models may want to compare it with controls at an enterprise AI gateway.
Ask nFOX for the release timeline and implementation specifics. The next useful evidence is the code, host requirements, policy semantics, and test results that evaluators can inspect or reproduce.
FAQ
Is Blockhouse already open source?
The report says nFOX planned an Apache 2.0 release and that Blockhouse was in beta for qualified enterprise evaluations; it does not report that the open-source release had occurred. 1
What does Blockhouse restrict?
It removes workload privileges by default, allows policy-based restoration of access, restricts file access and approved network destinations, and routes communications through a monitored channel called Porthole. 1
Which inference engines does it support?
vLLM, SGLang, and llama.cpp. 1
How does it detect model-file tampering?
It seals approved model files with SHA-256 hashes before serving and halts serving if those files change. 1
What's still unspecified for an enterprise evaluation?
The report does not provide an open-source release date or repository link, kernel requirements, policy language, Porthole's full request-handling scope, audit retention, performance overhead, or failure and recovery behavior. 1
Source
1 “Startup nFox to open-source its ‘sandbox’ for open AI models,” SiliconANGLE AI, October 15, 2026. https://siliconangle.com/2026/10/15/startup-nfox-to-open-source-its-sandbox-for-open-ai-models/
Questions
- Is Blockhouse already open source?
- No. The source says nFOX planned an Apache 2.0 release, but Blockhouse had not yet been released as open source at the time of the report, and Blockhouse was in beta for qualified enterprise evaluations. [1]
- What does Blockhouse restrict?
- It is designed to restrict workload privileges, file access and approved network destinations, with communications passing through the monitored Porthole channel. [1]
- Which inference engines does Blockhouse support?
- The source names vLLM, SGLang and llama.cpp. [1]
- How does Blockhouse detect model-file changes?
- It seals approved model files with SHA-256 hashes before serving and halts serving if those files change. [1]
- What are the main unknowns for an enterprise evaluation?
- The source does not specify the release date or repository, Linux and kernel requirements, policy language, Porthole's request-handling scope, audit retention, performance overhead or failure modes. [1]
Sources
- Startup nFox to open-source its ‘sandbox’ for open AI models · SiliconANGLE AI · Oct 15, 2026
How this article was made: an AI writer persona researched and wrote it from the sources listed above; separate AI passes edited it, checked its claims against those sources and audited it; an editor at Yelno reviewed and approved it before publication. How the Yelno blog works.