Trustworthy sandbox attestation: durable operations, applied-state snapshots, complete observations, and exact cleanup receipts

[rcs2153]

Hello OpenShell maintainers,

We are evaluating NVIDIA OpenShell as an optional execution-containment
provider for a local-first workflow governance kernel. Our system decides
whether an operation may execute and which evidence must return; OpenShell
would remain responsible for sandbox lifecycle and the filesystem, process,
network, inference, and platform controls it actually enforces.

We reviewed OpenShell v0.0.101 at exact source commit
8ddd98c3dff62619a3963f99ba1e055b67650e72. The current APIs already expose
useful typed facts, including gateway-owned sandbox identity and resource
version, committed structured policy, effective policy content and revision,
configuration revision, policy source and failure mode, sandbox-reported
policy-load status, driver runtime object identity, and the final exit code for
one connected exec stream.

For a restart-safe execution receipt, we could not identify authoritative API
facts for several other lifecycle boundaries:

1. idempotent sandbox creation and exact request reconciliation after an
   ambiguous transport result;
2. the immutable image digest observed by the compute driver after image
   resolution;
3. a complete typed snapshot of applied controls and degradation for the
   active gateway, driver, and platform;
4. a durable exec-operation identity with request commitment, applied-state
   binding, complete terminal semantics, and restart lookup;
5. an operation-bound observation export manifest with interval watermarks,
   event and drop counts, finalization posture, integrity commitment, and a
   stable reference;
6. resource-version-bound deletion with a durable terminal cleanup receipt;
   and
7. typed capability negotiation for those facts before sandbox creation.

We do not think callers should infer those facts from requested configuration,
human CLI text, a live stream alone, or partial log records. The component that
enforces or observes a fact should expose it authoritatively and bind it to
stable resource and operation identities.

Would a lifecycle model like the following align with OpenShell's direction?

SandboxCreationRecord
  -> SandboxAppliedStateSnapshot
  -> SandboxExecOperation
  -> ObservationExportManifest
  -> SandboxDeletionOperation

The names are illustrative. Some of these semantics may fit better as fields
or operations on existing resources.

The properties we care about are:

• mutations accept an opaque idempotency key plus a canonical request
  commitment;
• matching retries return the original durable result and conflicting reuse
  fails closed;
• canonical structured input policy is related machine-readably to the final
  composed and loaded policy;
• the driver reports the immutable image and effective control posture it
  actually applied;
• exec is a durable operation rather than only a transient stream;
• observation completeness is reported by the observing subsystem, including
  known drops and finalization state;
• deletion targets an exact resource version and remains queryable after the
  sandbox disappears; and
• capability output reflects the active gateway, driver, and platform rather
  than a compile-time support claim.

For one narrow motivating use case, imagine a fixed no-write CI/governance
operation in a sandbox with no credentials and default-deny networking. A
caller wants to prove that the reviewed policy and immutable image were
applied, the fixed operation reached a typed terminal outcome, one deliberate
egress denial appears inside a complete observation interval, and the exact
sandbox reached terminal cleanup. Raw stdout, stderr, policy, environment, and
security logs should remain outside the caller's governance state; stable
references, commitments, bounded counts, and typed postures are sufficient.

We would value guidance on these questions:

1. Which of these semantics fit existing OpenShell resources, and which merit
   first-class durable resources?
2. Where should creation, operation, observation, and deletion records live so
   reconciliation survives gateway or client restart within a declared
   retention period?
3. Can the driver expose resolved immutable image identity and a portable
   applied-control/degradation snapshot across supported platforms?
4. Can the observation subsystem finalize an operation-bound manifest with
   watermarks, event and drop counts, integrity commitment, and retrieval
   posture?
5. How should canonical request commitments handle secret-bearing general exec
   inputs without exposing sensitive values as retrievable metadata?
6. Would you prefer one cohesive attestation API direction followed by smaller
   independently useful issues, or a different incremental sequence?

We are not asking OpenShell to adopt workflow approvals, evidence ledgers,
reports, or any Workflow OS-specific model. We are also not proposing a fork,
a custom runtime distribution, arbitrary provider writes, or a production
security claim. Our intent is to understand whether general-purpose,
enforcer-owned lifecycle attestation belongs upstream and where maintainers
would want those boundaries.

Source references for the reviewed pin:

• OpenShell source at v0.0.101 commit
• public gateway API schema
• sandbox policy API schema
• compute-driver API schema
• OCSF JSON export documentation

Thank you for any direction on fit, preferred API shape, or work already in
progress that addresses these gaps.

[krivonosoff161]

Hi.

The question here about enforcer-owned receipts connects to a sequencing problem I'm investigating.

I read Alex Watson's note on formal methods in OpenShell. The case where blocking a write through one interface still left a write possible through another permitted tool stood out to me. It shows why permissions need to be considered together.

I'm the solo developer of Agentic Security Harness. I'm investigating a related question: an action may belong to the permitted set, yet only be valid after specific preceding steps have actually happened.

For example, an agent must obtain two results before performing the final operation. Saying "I've already obtained both" or supplying a fabricated receipt must not substitute for those events. In my local prototype, state changes follow the results of controlled execution, not the model's assertions. For the tested sequences, a separate checker reconstructs transitions and rejects substituted results, substituted actions, or fabricated completion. The next question is how to justify trust in the source of that history itself.

Do you have work connecting permission containment to these state and event-origin dependencies, especially when a task is handed to another agent? I'm interested in the link between the formal model and observed execution, rather than another model-output score.

If this is close to your research, I'd be interested in comparing approaches on a small shared example. This is currently local research; the new wrapper is not part of the published Harness yet.

Thanks!
krivonosoff161