SWT3 for OpenShell Partners

1. The Evidence Gap

Your customers deploy OpenShell to contain agent behavior. The sandbox works. It blocks unauthorized network calls, restricts file access, enforces tool permissions. None of that is in question.

The question is: when an auditor asks "prove that Agent-47 was sandboxed on Tuesday at 14:00 UTC," where is the evidence?

Enforcement logs exist, but they sit on local disk. They have no cryptographic integrity. They cannot be verified by a third party. An auditor must trust the operator -- and trust is not evidence.

2. What is SWT3?

SWT3 (Sovereign Witness Traceability) is an open protocol for recording cryptographic evidence of AI system behavior. Think of it as TLS for accountability -- infrastructure that any tool can plug into, not a vendor product that competes with yours.

When your tool makes a decision -- allow a network call, deny file access, block a guardrail violation -- SWT3 records a witness anchor: a signed, timestamped, fingerprinted attestation of what happened. The anchor is immutable and independently verifiable. The formula that produces the fingerprint is published and locked across 10 SDK languages.

SWT3 speaks OCSF natively. The OpenShell adapter consumes OCSF v1.7.0 events and automatically maps them to the correct accountability procedure. No schema translation, no custom integration code, no runtime dependency.

Key Terms

• Witness Anchor: A cryptographic attestation record -- signed, fingerprinted, mapped to a specific accountability procedure. Not a log entry. Not a metric. An independently verifiable proof that something happened.
• Procedure: A specific accountability obligation. For example, AI-SHELL.1 records that a sandboxed runtime enforced its containment policy during a specific observation window. There are 279 procedures covering everything from inference witnessing to agent delegation.
• Clearing Level: A privacy tier that controls what metadata survives in the anchor. L0 (analytics) keeps everything. L3 (classified) strips all identifying information while preserving the verdict. Your customers choose the level that matches their data sensitivity.

3. Three-Layer Architecture

Every compliance question has three layers. Your tool handles Layer 1. SWT3 handles Layer 2. Auditors and regulators consume Layer 3.

4. How It Works

SWT3 stays out of the critical path. It reads events after they occur. Zero runtime dependencies on your sandbox. Zero performance impact on sandbox operations. If SWT3 goes down, your sandbox keeps running exactly as before.

OCSF Event Mapping

The OpenShell adapter maps OCSF v1.7.0 event classes to SWT3 procedures automatically:

Integration

The adapter is a consumer, not a proxy. It reads your OCSF events from a log file, a stream, or a queue. Your sandbox never knows SWT3 exists.

from swt3_ai.adapters.openshell import OpenShellWitness

osw = OpenShellWitness()
osw.process_event(ocsf_event)   # That's it.

# Or tail a log file in real time:
import asyncio
asyncio.run(osw.watch_log("/var/log/openshell/sandbox-001.jsonl"))

import { OpenShellWitness } from "@tenova/swt3-ai/adapters/openshell";

const osw = new OpenShellWitness(witness);
osw.processEvent(ocsfEvent);    // That's it.

// Or consume from an async stream:
await osw.watchStream(eventIterator);

No OCSF? No problem. If your sandbox does not emit OCSF events, use the one-liner for periodic attestation:

witness.witness_runtime_containment(
    runtime_type="openshell",
    policy_hash=policy_sha256,
    violation_count=0,
    observation_window_ms=300000
)

5. What Your Customers Get

6. Also Works With

SWT3's runtime containment procedure (AI-SHELL.1) is duck-typed. OpenShell is the headline integration, but the same procedure works with any sandbox that emits OCSF events or provides summary statistics.

If your product uses a different sandbox runtime, the same evidence layer applies. The procedure does not prescribe the enforcement mechanism -- it records what the mechanism did.

7. Next Steps

For Integration Engineers

Install the SDK and point it at your OCSF event stream. The adapter handles procedure mapping automatically.

• Python SDK -- pip install swt3-ai
• TypeScript SDK -- npm install @tenova/swt3-ai
• Technical Crosswalk -- full OCSF mapping, clearing levels, code examples

For Partner Managers

Share this page with your customer's compliance team. The three-layer diagram (Section 3) is the fastest way to explain the integration value. For customers who need the deep technical detail, send the Technical Crosswalk.

For Sales Engineers

Use the before/after comparison (Section 1) in customer conversations. The question "prove that your sandbox was enforced last Tuesday at 14:00 UTC" is the one that opens the door. The answer is: enforcement + evidence.

• UCT Procedure Registry -- browse all 279 procedures
• Anchor Verification -- live verification demo
• Protocol Specification -- v2.0.0

Questions or partnership inquiries: partners@tenovaai.com

8. FAQ