Skip to content

Secure single-server AI harness

Documentation Deploy documentation

Published documentation. The rendered guides are available at redhat-et.github.io/secure-single-server.

Secure single-server AI harness runs OpenCode and OpenClaw on one dedicated RHEL 9 x86_64 host. OpenShell enforces the execution boundary. For the integrated harness paths, Praxis routes model traffic, while the optional Red Hat bootc deployment provides a repeatable OS environment managed by a container image.

The simplest way to understand what OpenShell can add to your environment is the Streamlit before-and-after demo. It runs the same app in an ordinary container and an OpenShell sandbox to show credential substitution and filesystem confinement.

Important

This is an experimental demonstration, not a production-ready platform. Use a disposable host for first evaluation and review the linked qualification evidence before extending a deployment.

How It Works

The integrated request path is:

OpenCode / OpenClaw → OpenShell sandbox → Praxis → approved model

OpenClaw supports bounded coding tasks through Praxis; see the OpenClaw walkthrough and its test evidence.

  • Dedicated always-on execution. Long-running agents continue on the server while your laptop disconnects. Workspaces, audit records, and cached model artifacts remain on the host.
  • Policy-enforced harnesses. OpenShell confines each harness and its tools with declared filesystem, network, process, runtime, and service-account policies. The gateway records policy decisions for later review.
  • Centralized model access. On the integrated paths, Praxis owns provider credentials and selects the approved upstream. The harness and sandbox do not hold provider keys.
  • Repeatable deployment. Published bootc images carry the OpenShell CLI, service configuration, and pinned workload references. First boot pulls the selected control-plane and harness images into rootless Podman storage.

Deployment methods

Deploy the stack as a bootc image or install it manually with Podman. Both methods support the post-deployment scenarios. See Deployment methods for the guides.

What can I do with this setup?

For a post-deployment workflow, try the OpenCode PR-candidate queue:

  • Queue public GitHub issues or operator prompt files for a public repository.
  • Optionally keep a longer batch alive in tmux after disconnecting from SSH.
  • Collect one reviewable bundle per task containing the task, proposed patch, metadata, and report.
  • Review the bundle on your workstation, then apply it and open a draft PR with your local Git and GitHub CLI credentials.

This scenario is issue/prompt-to-patch only. It does not perform pull-request reviews, and the sandbox receives no GitHub token or GitHub write access.

For risk-focused security demos, explore these scenarios:

  • API key theft: a planted key is discoverable, but attempts to spend it outside the approved gateway are blocked and audited.
  • Document exfiltration: a malicious skill tries several ways to send a document to an attacker destination; the boundary blocks each attempt.
  • Model escalation: compare an unrestricted model choice with the approved gateway catalog, which refuses an unapproved model before credentials are used.

For quota administration, see the Praxis token quotas scenario. All post-deployment scenarios are indexed in Example scenarios. Run them from the deployed repository checkout: on a bootc image, use /usr/share/secure-single-server; on a manual deployment, use /opt/secure-single-server. Published image tags contain only the reviewed revision from their build time, so use a rebuilt image or an updated manual checkout when trying newer examples.

Explore Further