Running AISP-packaged workflows in OpenShell: recommended isolation pattern?

[optimization2026]

What is the recommended way to run a custom workflow executor as an ordinary OpenShell sandbox workload, with read-only skill packages and a separate writable output workspace?

I am exploring AISOP/AISP as a concrete example. The aim is to use OpenShell's existing isolation and policy mechanisms—not ask OpenShell to interpret another workflow format or replace its policy language.

This is a pre-prototype integration question. No OpenShell capability gap or successful runtime test is being claimed.

Context

AISOP defines a workflow program with a graph, node functions, and operations such as sys.io.read, sys.io.write, and sys.io.confirm.

AISP packages that program as aisp/<id>_aisp/aisp.aisop.json, alongside a skill contract and declared resources.

The intended responsibility split would be:

• The external executor interprets the program, maintains execution state, and implements workflow-level assertions and human confirmation.
• OpenShell confines the executor and its subprocesses using an operator-approved policy.
• The operator decides which resources and capabilities are actually granted. A package declaration is an input to review, not permission to expand the sandbox.

For example, AISP's read_and_execute resource mode does not mean filesystem write access. I would not translate it mechanically into OpenShell's read_write.

The useful outcome would be a small integration recipe that also applies to other file-based workflow engines, rather than a format-specific loader in OpenShell core.

Minimal experiment

Start with one invocation, one pinned executor/image, and one supported Linux container backend.

The workflow would read synthetic input and write a synthetic result. An illustrative sandbox layout is:

/opt/workflow/aisp/demo_aisp/   # program and bundled input: read-only
/work/output/                 # generated results: writable
/work/state/                  # executor state, if required: writable

These are proposed sandbox paths, not a complete policy or a tested configuration. Interpreter dependencies and necessary temporary storage would also need to be explicitly accounted for.

The package would remain outside the writable working-directory tree. There would be no host-home mount, container-engine socket, or control-plane credentials available to the workload.

The first experiment would use a deterministic program path without model calls. Network probes would be separate synthetic tests; any later model access would require an explicitly reviewed provider/network configuration.

The OpenShell policy would initially be authored and reviewed separately, not automatically generated or activated from the skill contract.

Questions

1. Is an ordinary sandbox workload the right starting point?

My reading of the architecture suggests that an explicit workload image and command, launched through the existing CLI or SDK, should be the baseline.

Is there an existing example closest to this arrangement? I would prefer not to introduce middleware, an interceptor, or a custom driver unless the workflow actually requires one.

2. What is the recommended package/workspace arrangement?

For the first Linux-container experiment, is baking the fixed program and input into the image the simplest supported baseline, or is there a preferred read-only staging/mounting approach?

The goal is to keep program files read-only while permitting only the explicitly selected output, state, and scratch locations to be written.

The policy schema documentation makes include_workdir and Landlock compatibility behavior important here. In particular, individual paths can be skipped even with hard_requirement; I would not assume that selecting that mode establishes that every requested path was applied.

3. Which diagnostics or existing tests best establish the applied boundary?

The experiment should distinguish an actual policy denial from an absent file, an unreachable service, or a rule that was not applied.

Is there a recommended way to capture the effective policy, applied/skipped filesystem paths, and relevant denial information together for a reproducible integration test?

This is about verifying the resource boundary—not treating OpenShell logs as evidence that every AISOP node or human-confirmation step executed correctly.

What a useful first result would demonstrate

Test	Intended observation
Read the selected input and write the result	The actual executor loads the AISP program and completes the intended operation
Attempt to modify the package	The write is refused at the resource boundary
Attempt to access a pre-existing forbidden test file	Access is refused, rather than failing because the file does not exist
Attempt an unapproved connection to a controlled, reachable test service	The connection is refused by policy, not merely unavailable
Required enforcement cannot be established	The experiment is not reported as passing; unsupported or incomplete coverage remains explicit

A Python probe alone would establish only the tested sandbox behavior. An AISP interoperability result would additionally require the real executor to load aisp.aisop.json and exercise that path.

Protocol parsing, package validation, and executor integration would stay outside OpenShell core. If the current interfaces are sufficient, an external example may be all that is needed; a feature request would only follow a specific, reproducible missing behavior.

Pointers to the closest existing example or corrections to this responsibility split would be appreciated.

Source-format details

• AISP skill-package specification
• AISOP execution specification