enclawed

[enclawed]

What do you want to work on?

Enclawed-oss module on OpenShell

I am Alfredo Metere, PhD, CEO and founder of Enclawed LLC and sole author of enclawed, a deterministically secure agentic gateway based on several innovations referenced at the end of this document. I am also the author of an MCP specification extension that has been submitted and currently in review by the interest group (SEP #2809).

Enclawed comes in two flavors, an open source (enclawed-oss) and a closed source (enclawed-enclaved). This submission work is for the open source version.

By functionality, Enclawed positions itself as an alternative to OpenClaw that offers deterministic security baked into its core architecture. It is natively compatible with OpenClaw plugins and extensions because enclawed was born as a hard-fork of OpenClaw with a divergent mission from OpenClaw: being able to pass the most stringent security certification standards worldwide, including NIST SP 800-53 (High).

References

1. https://www.enclawed.com (Official Website)
2. https://arxiv.org/abs/2604.16838 (enclawed: A Configurable, Sector-Neutral Hardening Framework for Single-User AI Assistant Gateways)
3. https://arxiv.org/abs/2605.01740 (Architectural Obsolescence of Unhardened Agentic-AI Runtimes)
4. https://arxiv.org/abs/2605.00424 (Skills as Verifiable Artifacts: A Trust Schema and a Biconditional Correctness Criterion for Human-in-the-Loop Agent Runtimes)
5. https://arxiv.org/abs/2605.23951 (Methods for Formal Verification of Agent Skills: Three Layers Toward a Mechanically Checkable Capability-Containment Proof)
6. https://arxiv.org/abs/2605.24248 (Attested Tool-Server Admission: A Security Extension to the Model Context Protocol)
7. https://arxiv.org/abs/2605.20734 (An Application-Layer Multi-Modal Covert-Channel Reference Monitor for LLM Agent Egress)

Why this change?

I want to ship the enclawed-oss module inside OpenShell as an alternative to the NemoClaw/OpenClaw module.

This is a good fit for OpenShell, because enclawed is the most comprehensive MIT-licensed framework combining deterministic admission, per-tool authorization, and tamper-evident audit in a single distribution, closing gaps that non-deterministic security or other isolated deterministic security modules will never achieve. More specifically, Enclawed:

1. Naturally composes perfectly with OpenShell
2. Closes the credential-leak surface via not using env vars, nor the sandbox filesystem.
3. Already production-ready with hardened install path and LLM-driven adversarial test suite (27025 tool-name evasions + 14378 forged clearance assertions, all denied).

This PR contains

1. Provider yaml
2. Rust plugin modeled on GenericProvider
3. Registry entry
4. README row
5. Profile-shape test
6. 38 provider-crate unit tests + 880+ workspace tests, all green; full release build clean.

I'm aware of the vouch policy and will be signing the DCO after vouch, and respond to maintainers' feedback.

I'm fully available to discuss the issue, both now and in PR.

Checklist

• I wrote this request myself (not AI-generated)
• I have read CONTRIBUTING.md

[johntmyers]

Hi I looked at the PR. First, I think it should be possible to support this fully with a Provider v2 profile and not have to submit any changes to code for that. Have you been able to validate this independently? If so, I would suggest creating our own deployment repo that contains the provider profile, sandbox image, and any other artifacts you need.

[enclawed]

Hi I looked at the PR. First, I think it should be possible to support this fully with a Provider v2 profile and not have to submit any changes to code for that. Have you been able to validate this independently? If so, I would suggest creating our own deployment repo that contains the provider profile, sandbox image, and any other artifacts you need.

Thanks, you were right. Providers v2 covers our case fully — I validated end-to-end against unmodified main (f061b1d) and the same enclawed.yaml we had been baking into BUILT_IN_PROFILE_YAMLS works through provider profile import with no Rust changes.

Everything is now in our own deployment repo: https://github.com/enclawed/openshell-enclawed-sandbox

That ships:
  - enclawed.yaml — the v2 profile
  - Dockerfile + entrypoint.sh — sandbox image with /usr/local/bin/enclawed reachable
  - demo.sh — drives the full v2 roundtrip via e2e/with-docker-gateway.sh against upstream
  - v2-validation.txt — captured transcript of the validation run

One small friction point worth flagging: openshell provider create requires one of --from-existing | --credential | --from-gcloud-adc even for profiles that deliberately declare credentials: [] (Enclawed bootstraps secrets via the OS keyring inside the sandbox, so there's nothing to discover at gateway level). Current workaround is a sentinel --credential ENCLAWED_BOOTSTRAP=keyring. A --no-credentials flag or implicit zero-credential path would make the operator flow cleaner. Happy to file a separate issue if useful.

One thing that would help operators find this: the Supported Agents table in README.md already lists partner integrations whose sandbox lives outside the OpenShell tree — OpenClaw → NemoClaw is the existing precedent. The same shape (one doc-only row pointing at enclawed/openshell-enclawed-sandbox) would let operators discover Enclawed as a sandbox option. The integration is validated against upstream main (transcript in the deployment repo) and Enclawed is already in production with real operators. Happy to send the README row as a tiny docs-only PR — zero risk to the tree, zero review burden beyond a glance.

  PR #1689 can stay closed — no upstream code change is needed. Thanks for the steer.