OpenShell and Check Point: two different kinds of "no"

1 · The gap a sandbox can't close

After Lesson 1 you have a fence that works: deny by default, rules scoped by binary, placeholder keys. But the Check Point post puts its finger on the limit. A boundary decides only whether an action is allowed, and "whether the action still makes sense for the task is a separate judgement, and it is often where the real problems sit."^{CP blog}

Check Point's research example makes it concrete. An agent reads database credentials into a variable, and a few steps later posts that variable to GitHub. Each step on its own looks fine, so a static rule passes it. A monitor that reads the whole trace sees the harm.^{CP research} In OpenShell terms: gh → api.github.com on your scratch repo is an allowed rule, so the fence waves it through.

2 · Where everything sits

The order in row ② comes straight from OpenShell's docs: "The sandbox supervisor calls middleware after it checks network policy and before it forwards traffic," and "OpenShell injects provider credentials after request middleware runs, so middleware never sees them."^middleware Honesty flag: Check Point says "security middleware" and OpenShell documents "supervisor middleware". That they are the same hook is our reading. Neither vendor spells it out.

3 · Complementary, not overlapping

AI Defense Plane (launched 2026-03-23) is Check Point's "unified AI security control plane". It combines "discovery, governance, observability, runtime control, and continuous validation across the AI execution lifecycle". It has three modules: Workforce AI Security, AI Application & Agent Security (both available) and AI Red Teaming (limited release). It builds on ThreatCloud AI and the Lakera and Cyata acquisitions.^press Its Agent Security module already acts as "an inline enforcement layer for AI agent interactions".^{agent security} OpenShell gives that layer a kernel-enforced place to stand on the agent's own host.

4 · Lab: watch traffic change at the middleware hook

You can't run the Check Point beta at home, but OpenShell ships a demo middleware, openshell/regex. It rewrites text matching a fixed sk- pattern in outgoing HTTP bodies. It runs at the same point in the request path as a semantic monitor.^configure (The docs are explicit that it is for demonstration only: "Do not rely on it to detect or remove sensitive data.")

1. Write mw-demo.yaml. It starts from the docs' quickstart filesystem, plus a middleware entry on Anthropic's API host.

   version: 1
   filesystem_policy:
     include_workdir: true
     read_only: [/bin, /usr, /lib, /proc, /dev/urandom, /etc, /var/log]
     read_write: [/sandbox, /tmp, /dev/null]
   landlock:
     compatibility: best_effort
   network_middlewares:
     regex-demo:
       middleware: openshell/regex
       endpoints:
         include: ["api.anthropic.com"]

   No network_policies needed: the my-claude provider from Lesson 1 adds the Anthropic rule. Remember the order: policy first, then middleware.
2. Start Claude with it, reusing Lesson 1's image and provider.

   openshell sandbox create --name mw-lab --from claude-agent:local \
     --provider my-claude --policy ./mw-demo.yaml -- claude

3. Send a fake secret. In Claude, type:

   Repeat back exactly, character for character: sk-FAKE-0000-not-a-real-key

   Use only the fake string. Never paste a real key anywhere, sandbox or not.
4. Read the evidence in a second terminal:

   openshell logs mw-lab --source sandbox     # look for the regex-demo decision
   openshell policy get mw-lab --full         # network_middlewares + _provider_my_claude
   openshell sandbox delete mw-lab

Check yourself: who catches it?