Audience: Platform engineers integrating agent safety runtimes, compliance officers mapping sandbox evidence to EU AI Act / NIST AI RMF, auditors verifying containment attestation.

1. What NVIDIA Built

NVIDIA's Open Agent Safety Platform (September 2026) brings runtime containment to AI agents at scale. 120+ organizations adopted it in the first week, including PAN Networks, Microsoft, Oracle, CrowdStrike, Salesforce, and JPMorganChase.

The platform has two components: OpenShell, an Apache 2.0 CPU-based agent runtime using Linux Landlock LSM and seccomp BPF for containment, and Sentry, a hardware-backed watchdog on BlueField-4 DPUs. OpenShell emits events in OCSF (Open Cybersecurity Schema Framework) format, runs on any Linux with Landlock support (kernel 5.13+), and supports AMD, Intel, and Arm architectures.

Enforcement and evidence are separate concerns. OpenShell handles the first. This guide covers how to produce auditable compliance evidence from the containment events OpenShell generates.

Complementary, not competitive. OpenShell enforces containment. SWT3 proves it happened. Engineering teams use OpenShell to contain agents. Compliance teams use SWT3 to demonstrate containment to auditors. The two layers serve different stakeholders with different requirements.

2. The Evidence Layer

OpenShell focuses on enforcement. Compliance evidence -- proving to an auditor that containment was in effect during a specific time window -- is a separate architectural concern. Two open GitHub issues on the NVIDIA/OpenShell repository reflect community interest in this area:

Issue #2745

"Atomic sandbox governance evidence bundle"

Proposed bundling manifest.json + effective-policy.yaml + events.ocsf.jsonl with SHA-256 digests into a single attestable artifact.

Issue #3817

"Make sandbox event stream verifiable"

Proposes sequence numbers and hash chains to prove the OCSF event record is complete. Motivated by EU AI Act Article 12 (record-keeping requirements).

The SWT3 protocol provides this evidence layer today. AI-SHELL.1 records containment attestation as an immutable SWT3 Witness Anchor, producing the kind of cryptographic compliance evidence these issues describe.

3. The Three-Layer Stack

Layer 1: Enforcement

NVIDIA OpenShell

Landlock, seccomp, network policy, tool interception. Stops agents from going rogue.

Layer 2: Evidence

SWT3 Protocol

Witness anchors, fingerprints, clearing levels. Proves containment happened.

Layer 3: Assessment

Auditors / NBs

Verify anchors, check policy hashes, validate observation windows. Trust but verify.

Each layer operates independently. Enforcement continues if the evidence layer is unavailable. Evidence records remain verifiable without enforcement running. Assessment can occur offline from either layer.

4. NVIDIA's 5 Governance Principles Mapped to SWT3

NVIDIA PrincipleSWT3 ProcedureEvidence Type
"Policies must be verifiable before agent runs"AI-ACC.1 (Access Authorization)Pre-inference gate with authorization_id
"Enforcement occurs out-of-band"AI-SHELL.1 (Runtime Containment)Containment attestation with policy hash
"Path to model is critical control point"AI-TOOL.1 (Tool Call Witnessing)Tool call inventory with duration + scope
"Authority scales with visibility"AI-CLR levels (Clearing Engine)L0 Analytics through L3 Classified
"Safety responsibility is shared"Cross-framework crosswalks279 procedures across 80 regulatory frameworks

5. AI-SHELL.1: Runtime Containment Attestation

AI-SHELL.1

Runtime Containment Attestation

Records that a sandboxed runtime enforced its containment policy during a specific observation window. Works with any OCSF-compatible runtime.

Factor Aruntime_type_code -- 0=openshell, 1=gvisor, 2=kata, 3=firecracker, 4=wasm, 5=custom
Factor Bpolicy_enforced -- 1.0 if policy active and zero violations, 0.0 otherwise
Factor Cviolation_count -- Number of policy violations in the observation window
VerdictPASS when factor_b = 1 (zero violations). FAIL when violations detected.
Assessor Tip

Verify the policy_hash in the anchor matches the SHA-256 of the enforced containment policy. This proves the same policy was in effect across multiple attestation windows. Cross-reference observation_window_ms with the sandbox's OCSF event log to confirm coverage.

Framework Crosswalks

FrameworkCitationRelevance
EU AI ActArt. 9(2)(a)Risk management technical measures for high-risk AI
EU AI ActArt. 12Record-keeping (the article cited in OpenShell Issue #3817)
NIST AI RMFGOVERN 1.2Governance processes for AI risk management
ISO 42001A.6.2.6System integrity for AI management systems
OWASP Agentic#3 (MCP-03)Tool misuse prevention in agentic applications
OWASP Agentic#1Goal hijacking prevention via containment proof

6. Code Examples

Python: Witness OpenShell Containment

from swt3_ai import Witness

witness = Witness(
    endpoint="https://sovereign.tenova.io",
    api_key="axm_live_...",
    tenant_id="YOUR_TENANT_ID",
    clearing_level=1,
)

# After your OCSF event pipeline computes summary stats:
payload = witness.witness_runtime_containment(
    runtime_type="openshell",
    policy_hash="e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    violation_count=0,
    sandbox_id="sandbox-agent-7b2f",
    observation_window_ms=300000,   # 5-minute window
    ocsf_event_count=1247,          # events processed
    quarantine_events=0,            # kill/quarantine actions
)

print(f"Anchor: {payload.anchor_fingerprint}")
# PASS -- policy enforced, zero violations

# Flush to persist
witness.flush()

TypeScript: Witness gVisor Containment

import { Witness } from "@tenova/swt3-ai";

const witness = new Witness({
  endpoint: "https://sovereign.tenova.io",
  apiKey: "axm_live_...",
  tenantId: "YOUR_TENANT_ID",
  clearingLevel: 1,
});

// Works with any OCSF-compatible runtime -- not just OpenShell
const payload = witness.witnessRuntimeContainment({
  runtimeType: "gvisor",
  policyHash: "a1b2c3d4e5f6...",
  violationCount: 0,
  sandboxId: "gvisor-pod-abc123",
  observationWindowMs: 60000,
  ocsfEventCount: 342,
  quarantineEvents: 0,
});

await witness.flush();

MCP Server: Runtime Containment Tool

// The @tenova/swt3-mcp server exposes witness_runtime_containment as a tool.
// Any MCP-compatible agent can call it directly:

{
  "tool": "witness_runtime_containment",
  "arguments": {
    "runtime_type": "openshell",
    "policy_hash": "e3b0c44298fc...",
    "violation_count": 0,
    "observation_window_ms": 300000,
    "ocsf_event_count": 1247
  }
}

Python: Real-Time OCSF Event Stream (Adapter Pattern)

from swt3_ai.adapters.openshell import OpenShellWitness

# The adapter processes individual OCSF events in real time.
# Each event is mapped to the appropriate SWT3 procedure automatically.
osw = OpenShellWitness(witness=witness)

# Feed OCSF events as they arrive from the sandbox:
for event in ocsf_event_stream:
    procedure = osw.process_event(event)
    # Returns "AI-INF.1", "AI-SEC.1", "AI-TOOL.1", etc.
    # Unknown event types are silently skipped.

print(osw.stats)  # {"processed": 1247, "skipped": 3}

Two Integration Patterns. Use witness_runtime_containment() for periodic summary attestation (e.g., every 5 minutes). Use OpenShellWitness for real-time OCSF event witnessing. Both are duck-typed: zero NVIDIA SDK imports, zero OpenShell API calls, zero hardware requirements.

7. Procedure Coverage Matrix

SWT3 procedures that map to OpenShell capabilities:

OpenShell CapabilitySWT3 ProcedureWhat It Witnesses
Sandbox lifecycleAI-SHELL.1Containment policy enforcement over time
Tool call interceptionAI-TOOL.1Tool call inventory with scope and duration
Network policyAI-ACC.1Access authorization with pre-inference gate
File system isolationAI-ENV.1Runtime environment attestation
Policy violationAI-VIO.1Policy violation record with severity
Guardrail activationAI-GRD.1Guardrail trigger, action taken, scope
Agent identityAI-ID.1Agent identity assertion with signing key
Sandbox enforcementAI-SAND.1Tool allow-list compliance (MCP harness)
Eval gateAI-GATE.1Pre-deployment eval pass/fail decision
Incident responseAI-INCIDENT.1Incident classification, severity, containment
Real-time enforcementN/ASWT3 is post-hoc evidence, not real-time enforcement. OpenShell handles this.
Hardware attestation (Sentry)N/ABlueField-4 DPU attestation is hardware-bound. SWT3 witnesses software-layer evidence.

8. For Auditors

Verification Checklist

What the Auditor Sees

Each witness_runtime_containment() call produces an anchor like this:

SWT3-E-VULTR-AI-AISHELL1-PASS-1790646774-8ead3df6087d

procedure_id: AI-SHELL.1
factor_a: 0 (openshell)
factor_b: 1 (policy enforced, zero violations)
factor_c: 0 (violation count)
clearing_level: 1
policy_hash: e3b0c44298fc1c14...
observation_window_ms: 300000
ocsf_event_count: 1247
fingerprint: 8ead3df6087d

The anchor is immutable, independently verifiable, and maps to EU AI Act Art. 12 and NIST AI RMF GOVERN 1.2. The policy_hash lets auditors confirm the same containment policy was in effect across every attestation window without seeing the policy itself.

Sample Verification Query

# Verify all containment anchors for a tenant over 30 days
curl -s "https://sovereign.tenova.io/api/v1/ai-witness/export" \
  -H "Authorization: Bearer axm_live_..." | \
  jq '.anchors[] | select(.procedure_id == "AI-SHELL.1")'

9. Clearing Level Behavior

FieldL0 AnalyticsL1 StandardL2 SensitiveL3 Classified
runtime_typePreservedPreservedPreservedIn factors only
policy_hashPreservedPreservedPreservedStripped
violation_countPreservedPreservedPreservedIn factors only
sandbox_idPreservedSHA-256 hashedStrippedStripped
ocsf_event_countPreservedPreservedPreservedStripped
quarantine_eventsPreservedPreservedPreservedStripped
observation_window_msPreservedPreservedStrippedStripped

At L3 (Classified), only the three factors survive: runtime type code, policy enforcement status, and violation count. This is sufficient for verdict computation while protecting all operational details.

10. Beyond OpenShell

AI-SHELL.1 is runtime-agnostic. The same procedure works with any sandbox that produces containment summary statistics:

RuntimeType CodeLicenseContainment Mechanism
NVIDIA OpenShell0Apache 2.0Landlock LSM + seccomp BPF
Google gVisor1Apache 2.0User-space kernel (Sentry)
Kata Containers2Apache 2.0Lightweight VM (QEMU/Cloud Hypervisor)
AWS Firecracker3Apache 2.0MicroVM (KVM-based)
WASM Runtimes4VariesWebAssembly sandbox (Wasmtime, WasmEdge)
Custom5N/AAny containment mechanism

No Vendor Lock-In: Switching from OpenShell to gVisor (or any other runtime) requires changing one parameter: runtime_type="gvisor". The factor semantics, clearing behavior, fingerprint formula, and anchor format remain identical. Auditors verify containment evidence the same way regardless of the underlying runtime.

11. Integration Patterns by Use Case

The evidence layer applies regardless of which enforcement stack you run. Common patterns:

Use CaseEvidence PatternRegulatory Driver
EDR + sandbox containmentAI-SHELL.1 anchors alongside existing security telemetry. Separate evidence chains for separate concerns.NIST 800-53 SI-7, EU AI Act Art. 12
Agentic tool orchestrationAI-TOOL.1 for tool calls + AI-SHELL.1 for sandbox enforcement. Two procedures, one observation window.OWASP Agentic #3, #5
Classified workloadsL2/L3 clearing levels strip operational details while preserving verdict integrity. Auditors verify without seeing sandbox IDs.NIST AI RMF GOVERN 1.2, ISO 42001
Model risk managementContainment proof + model integrity (AI-MDL.1) + inference provenance (AI-INF.1) in a single evidence chain per model.SR 11-7 III.B, EU AI Act Art. 9

12. Get Started

Install

pip install swt3-ai

or npm install @tenova/swt3-ai

Explore

UCT Registry

279 procedures, 80 frameworks

Connect

Free Tier

Zero-cost. No credit card. Full API access.