comparison
OpenShell vs Faramesh: Deep Technical Comparison
If you are building or operating agent systems, you need two answers: what the runtime can touch, and what actions the agent is allowed to execute. This comparison is written to answer both, fast.
OpenShell is primarily runtime containment (filesystem, process, network). Faramesh is primarily deterministic action governance before side effects. Most teams with serious risk controls end up using both layers together.
This is written for one thing: helping you decide how to run agents safely in production without slowing your team down. If you need a quick takeaway, read the first comparison table and the bottom-line section.
DIMENSIONOPENSHELLFARAMESH
Primary control pointSandbox boundary and egress mediation. Static domains at sandbox creation, dynamic network policy at runtime.Pre-execution authorization boundary for agent actions, with deterministic policy verdict before effectful execution.
Policy modelYAML policy sections with OPA/Rego evaluation for network decisions.FPL semantics for agent actions, including deny and defer flows tied to governance lifecycle.
Hot updatesLive update of network policies on running sandboxes via policy set with wait/timeout controls.Policy updates are treated as governance artifacts; decisions are deterministic and bound to policy state during evaluation.
L7 granularityHTTP method and path controls when protocol is rest and TLS termination is enabled.Action-level allow, deny, defer decisions at the normalized action boundary, independent of transport protocol details.
Evidence surfaceSandbox logs and policy revision workflow for runtime controls.Decision-centric provenance model (DPR) and replayable deterministic decision artifacts.
Structural Deep Dive: Where The Edge Actually Comes From
This is the part that matters when things break at 2 AM: how policies are expressed, where enforcement happens, what evidence is produced, and how fast you can change controls without creating blind spots.
DIMENSIONFARAMESHOPENSHELL
Policy LanguageAgent-native FPL with deterministic semantics, structural deny constraints, and compile pipeline support.Declarative YAML policy model with strong sandbox network policy controls and hot updates.
Enforcement GranularityPer tool-call, pre-execution action governance before side effects, integrated with decision lifecycle.Sandbox and network boundary enforcement at runtime with L4 and optional L7 method/path checks.
Audit And ProvenanceDecision-provenance model with deterministic replay and hash-linked audit semantics.Sandbox logs, policy revision states, and deny reasons from network policy evaluation.
Credential HandlingBrokered credential issuance tied to policy verdict and action context.Sandbox and proxy model that avoids broad ambient credential exposure in runtime flows.
Sandbox IsolationCross-platform governance path with strongest kernel-level controls on Linux.Heavy sandbox isolation model with strong containerized boundary posture and GPU-oriented ecosystem support.
Human In The LoopNative defer and approval workflow integrated into policy decision lifecycle.Primary docs focus on sandbox policy enforcement rather than approval workflow primitives.
Sessions And DelegationFirst-class policy primitives for sessions, budgets, and delegation governance.Not a primary abstraction in current policy model docs.
Framework CoverageFramework-agnostic auto patch approach across broad agent stacks.Strong integrated experience around NVIDIA ecosystem and OpenShell runtime path.
Operational WeightLighter startup and rollout path for action governance.Heavier sandbox infrastructure model with stronger isolation posture.
Ecosystem GravityOpen-core governance stack with SDK and integration focus.Major NVIDIA platform backing, toolkit visibility, and enterprise hardware alignment.
Control Boundary Analysis (What Actually Fails Closed)
Most comparison pages stop at feature lists. Real production behavior depends on which boundary is authoritative when systems degrade, misconfigure, or get attacked.
FAILURE SCENARIOOPENSHELL POSTUREFARAMESH POSTURE
Unexpected outbound destinationDenied by sandbox network policy when endpoint and binary do not match allowed rules.Denied at action authorization boundary before execution when policy does not permit target action.
High-risk action under normal runtimeRuntime can still be tightly isolated, but policy model is network and sandbox centered.Can be blocked or deferred via action-centric policy semantics and approval workflow path.
Policy iteration in active incidentStrong live network policy update workflow for active sandbox response.Strong policy-level action governance updates tied to deterministic decision path.
Audit reconstruction after incidentLogs and policy revision history from runtime containment layer.Decision-provenance-centric replay model for action-level governance traceability.
Verification note: OpenShell claims above are based on NVIDIA OpenShell architecture and policy docs plus sandbox tests (policy hot reload, static vs dynamic domains, L7 method/path enforcement via protocol rest plus tls terminate, and policy set wait flow). Faramesh model references: arXiv:2601.17744 and Core Specification v1.0.
What you should care about first
Start with these two questions: "Can this runtime reach only approved resources?" and "Can this agent execute only approved actions?" OpenShell and Faramesh answer different parts of that equation.
01OpenShell gives strong sandbox controls: immutable filesystem, process, and Landlock settings at creation, with network policies as the runtime mutable domain.
02OpenShell network policy supports both coarse host and port control and fine-grained method and path inspection for REST endpoints under TLS termination mode.
03Faramesh governs actions before execution with deterministic policy semantics so actions can be halted or deferred before side effects occur.
04Faramesh policy language is built around autonomous agent workflows (for example deny and human routing patterns) rather than only network transport semantics.
05The practical architecture in high-assurance environments is often layered: OpenShell for runtime containment and Faramesh for decision governance.
How To Choose In Practice
The practical split is containment, change velocity, governance semantics, and evidence quality.
ContainmentIf you own runtime hardening, OpenShell gives strong host-level containment. Static policy domains are locked at sandbox creation, which reduces accidental drift in process and filesystem boundaries.
AgilityIf you own operations, OpenShell allows live network policy iteration on running sandboxes. This supports emergency response and staged tightening without restarts.
GovernanceIf you own control objectives, Faramesh is designed for deterministic action governance and approval routing at the decision boundary, not only traffic control.
EvidenceIf you own audit and response, Faramesh emphasizes decision provenance and deterministic replay, while OpenShell contributes runtime logs and policy revision visibility.
PracticalIf you are making an architecture decision, do not force a false choice. They solve different classes of control and can be deployed together.
Decision Framework (Not Just Features)
Use this as an architecture decision shortcut. Pick the row that matches your current bottleneck, not your long-term aspiration.
IF YOUR BIGGEST PROBLEM ISSTART HERE
Runtime escape and egress riskStart with OpenShell-style sandbox isolation and strict network policy controls.
Uncontrolled tool executionStart with Faramesh-style action authorization before side effects.
Human approval for high-risk actionsStart with Faramesh defer and approval lifecycle in policy.
Fast emergency network lockdownStart with OpenShell live network policy update workflows.
Audit-grade action traceabilityStart with decision-provenance-first governance model and replayable artifacts.
Concrete OpenShell mechanics (verified)
The following details come directly from the OpenShell docs and code paths:
01Policy domains are explicitly split into static and dynamic fields. Static fields are immutable after sandbox creation; network policies are runtime mutable.
02Live policy updates are exposed through openshell policy set, including wait and timeout options for rollout confirmation.
03L7 method and path inspection is activated through protocol rest with tls terminate; audit and enforce modes are both documented and tested.
04Network decisions are evaluated by an embedded OPA engine (regorus) with baked policy rules and atomic reload semantics.
05Examples and tests document default-deny behavior and read-only presets that allow GET, HEAD, OPTIONS while blocking mutating methods.
Recommended rollout pattern
If you can run both layers, this is the practical rollout sequence:
Step 1Use OpenShell to enforce sandbox-level boundaries and network mediation around the agent runtime.
Step 2Use Faramesh at the action authorization boundary to deterministically decide permit, defer, or deny before side effects.
Step 3Route deferred actions through human approval policies for sensitive workflows.
Step 4Join sandbox telemetry with decision provenance in your SIEM for incident reconstruction and compliance evidence.
Migration Playbook: 30/60/90
For teams moving from ad hoc guardrails to enforced governance, this phased plan avoids platform shock.
Day 0-30Stabilize containment. Lock down runtime boundaries and baseline allowed network destinations.
Day 31-60Add action governance. Gate high-risk tool calls with deterministic policy and defer approvals where needed.
Day 61-90Harden evidence and operations. Standardize incident runbooks, replay validation, and SIEM integration.
Anti-Patterns That Break Security Programs
01Assuming runtime isolation alone solves action governance. It does not cover all policy intent at tool-call level.
02Assuming action policy alone solves runtime escape risk. It does not replace sandbox boundary controls.
03Running approvals outside the policy lifecycle. This creates drift between what policy says and what operators do.
04Treating logs as equivalent to deterministic decision provenance. Forensics quality can degrade under pressure.
Bottom line for you: use OpenShell when you need strong runtime containment and hot-reloadable network policy, use Faramesh when you need deterministic execution governance at the action boundary. In high-assurance environments, the strongest posture is usually both.