AI-assisted work

Purpose and scope

Shyft combines browser-based AI for research, discussion and task design with autonomous execution in a bounded, deliberately untrusted environment. A human task owner selects permitted inputs and authority, then reviews and validates the result before integration or operational use. This model supports Shyft development, downstream development, and business scripting and analysis.

Bring the material required for the task into the execution environment rather than granting the agent access to the systems from which that material originates. A missing input calls for revised task material, not automatic access expansion. Browser planning and execution are separate disclosure decisions.

This page distinguishes the current implementation described in the supplied tooling, accepted policy governing its use, and proposed work. It applies the existing Security Principles, Dependency Selection Principles and Access Control policies; AI assistance creates no new release or deployment authority. See the Security for Shyft’s broader trust model and What is Shyft? for the framework architecture. The inspection/trust distinction in Governance and Infrastructure Control and authorities in Release Process remain unchanged.

Trust roles and authority

A security arena groups execution members, their accessible mounts and services under one communication policy. A member is an execution container, not a separate tenant boundary. Before considering the container layout, distinguish these roles:

  • Untrusted execution: the agent, its commands, generated programs and mutable workspace. Inputs can carry malicious instructions; outputs remain untrusted until reviewed.

  • Trusted control and enforcement: the task owner’s scope/data decisions, the environment operator’s configuration, broker policy, egress policy and host/VM containment controls. Gateways can be trusted enforcement components while remaining network-reachable from untrusted members; reachability does not delegate administrative authority.

  • Human review boundary: the task owner validates results and decides whether to accept them. Publication, signing and deployment remain with the existing authorized roles.

  • External or conditional services: browser AI and inference providers are governed by disclosure/provider policy, not implicitly trusted with all data.

The task owner selects inputs and accepts work; the environment operator manages containment and provisioning. One person may perform both roles. Autonomous execution grants neither authority to expand network access, add mounts, obtain new credentials, publish changes, sign releases nor deploy to production. Containment is enforced outside the agent’s authority. Prompts, approval dialogs and proxy environment variables are not filesystem or network boundaries.

Hybrid working model

Browser AI supports planning outside the execution arena using only information the task owner permits it to receive. The task owner supplies the execution agent with a task, source snapshot, dependencies, documentation and selected data. The baseline offers no general runtime Internet access. Inference through the broker is a deliberate permitted export path, not unrestricted agent-selected egress.

        ---
config:
  flowchart:
    nodeSpacing: 24
    rankSpacing: 30

---
flowchart TD
    B["External browser AI<br/>planning outside the arena"] -->|"planning advice"| U["Human guard<br/>task scope and input selection"]
    U -->|"task + selected inputs"| A["Untrusted execution arena<br/>agent, commands, mutable workspace"]
    A -->|"untrusted results"| R["Human review guard<br/>validate and accept or reject"]
    R -->|"accepted work; authorized roles"| T["Governed integration<br/>or operational use"]
    R -->|"another planning iteration"| B
    A -->|"permitted inference export"| K["Broker guard<br/>selected API operations and credentials"]
    K -->|"fixed upstream through policy"| E["Egress guard<br/>default-deny outbound policy"]
    E -->|"selected inference path only"| P["External approved provider<br/>conditional disclosure trust"]
    classDef untrusted fill:#fbe1dc,stroke:#a74432,color:#54251e
    classDef guard fill:#e4effb,stroke:#35669a,color:#193d62
    classDef external fill:#eeeeee,stroke:#666666,color:#333333
    classDef accepted fill:#e4f0e6,stroke:#477650,color:#25472b
    class A untrusted
    class U,R,K,E guard
    class B,P external
    class T accepted

Authority and workflow; labels identify trust roles independently of color.

Red/orange labels mark untrusted execution; blue labels mark guards and review; gray labels mark external services; green marks governed acceptance. Labels and edge descriptions convey these roles without color. Review may return work to planning, and planning quality does not remove the need for validation.

The broker’s credential protection does not prevent workspace material being sent through permitted inference. Browser disclosure is separate from execution disclosure; local execution cannot undo information already sent to browser AI. Local/internal inference is a deployment alternative under provider policy, not an implemented provider-selection option in the current CLI baseline.

Boundary and assurance limits

Members within an arena are intentionally mutually reachable and share one trust domain. New mounts and services enlarge accessible assets even when the network perimeter is unchanged. Separate arenas on a host still share its kernel and administrative authority. Rootless containers are not VM-equivalent isolation.

Network separation is not complete data-flow isolation: inference is an allowed data-export path, and provider credential protection does not make supplied data confidential from the provider. Client/IDE protocols and tunnels cross another boundary; an IDE does not raise the security level. Use separate VMs or hosts where the required outer boundary exceeds container separation.

The recorded rootless-Podman bridge-gateway host-service finding remains unresolved: ordinary peers reached listeners in the shared rootless network namespace. Codex file tools also retain their documented proc-mount sandbox blocker. See Known issues and assurance limits and Bounded security verification for precise scope. Bounded checks and manual experience are not full penetration testing, independent security review or certification. The diagrams show intended policy and permitted paths, not proof that every forbidden path is blocked.

Only dedicated task directories belong in execution mounts. Keep trusted management tools/state, host home, personal credentials, signing devices, container-management sockets and host authentication agents outside them. Writable mounts expose host-side contents to modification or destruction. CLI-first arena workflow supplies the simple recipe; Arena administration reference details mount/ownership safeguards and explicitly acknowledged shared paths.

Execution profiles

Baseline: provisioned development tools

The baseline contains the compilers, libraries, agents, and other tools needed for the task before execution begins. Runtime use does not require package downloads or vendor services. Agents such as OpenCode and Codex use the approved inference broker. Provider credentials remain outside the development container.

There is no general runtime egress. Network access to inference is the explicit exception, whether inference is local, corporate, or externally hosted.

Backend IDE: additional client connection

A backend IDE may be added while retaining the baseline egress policy. Experience with the supplied setup favours OpenCode or Codex together with the backend IDE’s local MCP service over IDE-integrated AI. This is an operational finding from that setup, not a guarantee for all versions or products.

An MCP service is acceptable only to the extent that its tools and reachable resources remain within the intended arena. A local endpoint is not sufficient evidence: its capabilities, credentials, and onward connections also matter.

Remote IDE protocols and their SSH tunnels connect the untrusted backend to a client computer. This is an additional trust boundary even when no vendor egress is enabled. Client integrations, forwarding, and protocol behaviour must be assessed, and the client should itself be appropriately contained.

If IDE-integrated AI requires vendor access, treat that as an explicit extension of the baseline. Record the required destinations, purpose, data exposure, and approving operator. Do not enable a broad vendor allowlist by default.

Corporate deployment: a stronger outer boundary

Current documented deployment profile: an organization may provide a hardened Linux VM or managed development workstation with restricted administrative authority and organizational host/network controls. A VM can separate execution from the normal user workstation; a managed workstation still uses its own kernel. The baseline tooling alone does not supply or verify these additional controls.

Architectural purpose: this outer boundary owns the container runtime, network configuration and private management state. It can enforce organizational policy independently of the agent. A GNOME/Wayland desktop over RDP is one possible corporate profile, not a prerequisite. Desktop access, clipboard/file transfer, client connections and reachable internal services need explicit policy. See the host-hardening discussion below.

Future/proposed tooling: planned tools/ai/vm-hardened helpers are intended to supply ready-to-use QEMU/VM images with documented, reviewable hardening profiles. They are not part of the supplied implementation. No commands or hardening guarantees are specified here before that tooling is reviewed.

Reference architecture

Current implementation: the supplied baseline uses systemd user services and rootless Podman containers managed through Quadlet. It supports the fixed OpenAI Responses gateway policy; the architecture does not imply general provider selection. The host/VM shown below is a deployment scope, not an automatically hardened property of every installation.

        ---
config:
  flowchart:
    nodeSpacing: 22
    rankSpacing: 32
    subGraphTitleMargin:
      bottom: 55
      top: 8

---
flowchart TD
    H["Human task owner / operator<br/>scope, connection and review"]
    subgraph HOST[" "]
        HS["Host / VM deployment boundary<br/>hardening not guaranteed by baseline"]
        C["Host/VM guard<br/>management state and credentials outside execution mounts"]
        W["Reviewed task workspace/data<br/>mutable contents remain untrusted"]
        S["Host-loopback SSH entry<br/>pinned identity; no agent forwarding"]
        subgraph POD[" "]
            PS["Rootless Podman environment<br/>host kernel shared"]
            subgraph ARENA[" "]
                AS["Named security arena<br/>one trust domain"]
                subgraph NET[" "]
                    NS["Internal development network<br/>members mutually reachable"]
                    M["Untrusted execution member(s)<br/>agent and commands; no general Internet route"]
                    K["ai-api broker guard (Caddy)<br/>provider secret; credential replacement + route policy<br/>fixed upstream; no direct external route"]
                    E["egress gateway guard (Squid)<br/>default-deny; only arena container with external attachment"]
                end
            end
            X["External-network attachment<br/>selected inference destination only"]
        end
    end
    R["Human review guard<br/>task owner validates and accepts or rejects"]
    P["Approved external inference provider<br/>permitted data-export destination"]
    H -->|"task + selected inputs"| W
    H -->|"SSH / controlled client connection"| S
    S -->|"member SSH"| M
    W -->|"selected read/write mounts"| M
    M -->|"untrusted output for review"| R
    M -->|"Responses API"| K
    K -->|"allowed TLS CONNECT to fixed provider"| E
    E -->|"policy-checked outbound TLS"| X
    X -->|"external inference"| P
    H -.->|"administration outside agent authority"| C
    C -.->|"runtime, mounts and network configuration"| PS
    H ~~~ HS
    HS ~~~ W
    HS ~~~ S
    HS ~~~ C
    HS ~~~ PS
    PS ~~~ AS
    AS ~~~ NS
    NS ~~~ M
    classDef untrusted fill:#fbe1dc,stroke:#a74432,color:#54251e
    classDef guard fill:#e4effb,stroke:#35669a,color:#193d62
    classDef external fill:#eeeeee,stroke:#666666,color:#333333
    classDef scope fill:#f8fafc,stroke:#87939e,color:#334155
    class HOST,POD,ARENA,NET,HS,PS,AS,NS scope
    class M,W untrusted
    class H,R,C,S,K,E guard
    class X,P external

Reference containment on a managed workstation or optional hardened VM; dashed edges are administrative control, not runtime egress.

The host/VM guard controls runtime/network setup and keeps trusted management state out of execution mounts. Solid arrows show task transfer, client access, mount access, returned output and permitted inference; they are not all network links. Dashed arrows show administration unavailable to the agent. Browser AI belongs to the planning workflow above, not a direct container connection. The outer box depicts a deployment choice; proposed VM helpers do not currently create it. Containers inside a VM still share that VM’s kernel.

In the current baseline:

  • An internal development network contains the untrusted execution containers and the internal interfaces of the gateways. Development containers are intentionally mutually reachable within an arena. Each named arena has its own internal network and gateways; this is a shared trust domain, not isolation between users, projects, or tasks.

  • The ai-api broker uses Caddy as a reverse proxy and holds the upstream credential, supplied through Podman secrets. It exposes selected API operations, replaces client authorization, and selects the upstream destination. It has no direct external route.

  • The egress gateway runs Squid with a default-deny policy. It is the only container attached to the external network. The baseline allows only the broker to reach the selected external inference endpoint.

  • Development containers receive selected workspace mounts, their own mutable runtime state, and container-specific SSH access. Published SSH ports bind to host loopback in the reference setup.

Caddy is the reference implementation for the API broker. Its documented, human-readable Caddyfile format keeps the permitted API routes, authorization-header replacement, and upstream proxy configuration explicit and reviewable. It is available as a distribution package in both Arch Linux and Fedora, consistent with Shyft’s preference for distribution-provided dependencies. Validate the required configuration features against the packaged version selected for the image.

Architectural alternatives, not current CLI options: another reverse proxy would need to preserve the same broker contract: fixed approved upstream destinations, explicitly permitted API operations, replacement of client credentials with the broker-held credential, and outbound traffic through the controlled egress gateway. The reference Caddy configuration disables its administrative API and denies unmatched requests.

The gateways are trusted enforcement components despite sharing network reachability with the arena. They need separate configuration and credentials; their administrative controls must not be exposed to the agent. Fixed addresses support policy and diagnosis but do not replace isolation or service hardening.

An internal network declaration is one control, not proof of complete containment. Validation must include host reachability, DNS, IPv4 and IPv6, forwarding, published ports, and any client tunnels. Separate arenas or VMs are needed where projects or datasets must be isolated from one another.

Choose the next step

For normal use, start with CLI-first arena workflow: prepare reusable images, create a named arena, connect over SSH and run an agent. It also covers refresh, add, remove and retained recreation. The detailed material remains separate:

Workspace mapping and control of results

Directly mapped checkout

The task owner selects a dedicated checkout separate from the trusted tooling checkout. The current managed member mounts its workspace at /home/ci/workspace; optional data mounts expose only selected inputs with the chosen access mode. The agent’s edits are immediately visible in that host workspace, so no copy-back is needed. Use CLI-first arena workflow for the supported commands and Arena administration reference for mount options rather than writing Quadlet mappings by hand.

The agent can use Git to inspect the provided history, compare implementations, and create local commits. Git does not require remote access for these tasks. The repository, including its history and local metadata, must be suitable for disclosure to the execution environment and the selected inference service. Do not supply secrets in tracked files, old commits, other branches, reflogs, untracked or ignored files, repository configuration, or credential-bearing remote URLs. Removing a secret from the current file does not remove it from history. If the required history cannot be supplied safely, provide a sanitized snapshot and explicitly describe the missing historical context.

Before starting, record the base commit outside the mounted directory and preserve existing user work separately. Prefer a clean task checkout. A writable repository mount also exposes .git: the agent can change the index, refs, configuration, and hooks as well as source files. The direct mapping therefore delegates modification of that checkout, while the user retains the decision to accept and publish the results. Git in the same writable directory is not an independent backup or a protected record of the starting state.

Review and publication

Stop the execution container and other writers before reviewing the result. On the workstation or VM, inspect the final files against the independently recorded base, together with local commits, staged changes, and new files. Plain git diff only shows unstaged tracked changes; it is insufficient if the agent has staged or committed its work. A review typically includes:

# Set base_commit to the full commit ID recorded before execution.
git status --short --untracked-files=all
git diff --no-ext-diff --no-textconv "$base_commit" --
git log --oneline "$base_commit"..HEAD

Inspect untracked deliverables separately; ignored outputs also need deliberate selection. Review repository metadata before using the directly mapped checkout with workstation tools: hooks, configured helpers, filters, and IDE tasks may execute code. Disabling external diff and text conversion in the example does not make every subsequent Git or IDE operation safe. Perform builds and tests in the controlled environment rather than automatically executing generated code on a credential-bearing workstation.

The user accepts or rejects the changes, prepares the reviewed commits, and pushes from outside the agent’s environment. Keep repository authentication and signing authority there. Shyft recommends hardware-backed GPG signing and SSH authentication, with PIN protection and configured touch requirements; private key operations remain on the hardware device. PIN caching and device policy determine when interaction is requested, so do not assume a fresh PIN prompt for every operation. See Release Trust Infrastructure and Nitrokey Setup Notes for key and Nitrokey setup. Do not forward the SSH or GPG agent, or expose the token, to an execution member. Hardware authorization protects key use; the user must still review what is being signed or published.

Separate execution copy

For stronger protection of the user’s checkout, provide an independent copy in a task directory and mount only that copy. Leave the original checkout and its Git metadata outside the arena. This has a concrete benefit: agent edits and destructive commands cannot directly modify the user’s original files, refs, hooks, or configuration through the workspace mount.

Use an independent clone or a copy without shared writable files or repository metadata. A linked git worktree shares repository state and is not this isolation boundary. Avoid hard-linked copies and shared Git object stores when the intended property is an independent execution copy. For local cloning, git clone --no-hardlinks avoids Git’s local object hard-link optimization; do not combine this approach with --shared or --reference. A clone copies committed history, not the user’s uncommitted changes, and does not sanitize secrets. The user must select and inspect the material supplied.

After execution stops, inspect the copy as untrusted input. Transfer selected changes as a reviewed patch, or import selected commits and cherry-pick them on a review branch in the original repository. Do not copy the agent’s .git directory, hooks, or local configuration back. Review the resulting diff and validate it before signing and pushing. Treat transferred source files and build instructions as untrusted until reviewed, regardless of transfer method.

This option adds a deliberate acceptance step and protects the original checkout’s integrity. It does not reduce disclosure of the data given to the agent and does not make the returned changes inherently safe.

Data and inference

The inference endpoint is an allowed data-export path. Keeping its API key in a broker prevents ordinary credential access by the agent, but does not prevent the agent from sending workspace material in inference requests or consuming the available inference budget. Data selection must therefore match the approved provider and its handling requirements.

All supplied repositories and data volumes must be free of secrets. Restricted egress reduces reachable destinations, but an agent error, a dependency bug, or malicious input can still cause sensitive content to be sent over the permitted AI API path. Keeping provider credentials in the broker does not protect secrets accidentally included in task material.

“Zero egress” must identify the boundary being described. An arena using an external inference provider is not a zero-data-egress environment. Work requiring data to remain within an organization needs inference and all associated services to remain within the approved organizational boundary.

Local GPU inference can improve confidentiality by keeping prompts, source code, and analysis data in-house. This depends on the inference service, its logs, telemetry, and onward connections also remaining within the governed boundary. Local inference does not change the requirement to exclude secrets from the arena. In the hybrid workflow, disclose only approved design context to the browser-based service; local execution does not undo earlier browser disclosure.

For business analysis, Shyft services and read-only replicas can provide a controlled subset of real data. Prefer bringing a replica or snapshot into the arena over granting access to a production service. Where a live replica is necessary, define its ingestion path, reachable operations, and resource limits. Read-only access limits mutation; it does not remove confidentiality or availability risks. Monitor and bound query load, CPU, memory, storage, and inference consumption outside the agent’s control.

Shyft’s Python .pyi stubs provide precise signatures for implementation and analysis tasks. Supply stubs matching the installed Shyft version, together with relevant API documentation, units, time conventions, and examples. Signatures support correct API use but do not establish the scientific validity of results.

Provisioning and runtime

Replaceable images and persistent work

The development image supplies the operating system and installed tools; task-specific mounts hold saved work and private runtime state. Replacement preserves those mounts, not running processes, unsaved buffers or container-layer files. Stop all writers, preserve independent backups and verify compatible identities/tools before replacement. Persistence is not a backup, and image rollback cannot undo state migrations. The CLI-first arena workflow named refresh workflow and Arena administration reference describe snapshot/recovery limits; recheck containment after image or runtime changes.

Governed image builds

Image building and IDE provisioning are separate from controlled execution. They may require approved package or vendor downloads unavailable at runtime. Apply the existing dependency policy to these inputs and record the selected versions and image identities.

See Image preparation for implemented profiles, acquisition, reviewed agent artifacts and provenance evidence. Those technical records are not independent image certification or authority to deploy or publish.

The supporting build scripts are intended to let developers build new versions of their development image through this controlled provisioning workflow. Changes to tools and packages belong in reviewable build recipes, rather than depending on undocumented installations in a running container. Build outside the agent’s execution arena, without exposing personal credentials or unrelated workspaces to build steps. Test the resulting image before selecting it for an existing workspace; the scripts support this process but do not by themselves establish that an image is safe.

In a corporate deployment, approved base images, internal package repositories, and approved external package sources can govern both internal and third-party software. Apply those controls to image builds as well as the host. Restrictions on the host’s package manager do not automatically restrict a container build’s package sources or network access.

The normal development path should make approved software readily available. General Git or file-download access can still allow a developer to obtain other software outside the package workflow. Package-source restrictions alone do not prevent this. Reviewable recipes, controlled build networking, and appropriate audit records make such additions deliberate and visible; visibility must be provided by those controls, not assumed from the use of Git.

IT-managed images for business scripting

Business scripting normally uses an environment supplied and maintained by corporate IT. Business users select an approved image and supply their scripts and permitted data; package selection, installation, and image maintenance are the responsibility of IT or its designated platform team. Requests for additional packages follow that team’s approval process. The technical ability to build an image does not imply authority to introduce it into the managed environment. Developer-built images remain a separate workflow for roles authorized to maintain or extend the development toolchain.

A controlled internal container registry provides a distribution point for approved images. Restrict publication and promotion to authorized maintainers, verify image provenance under organizational policy, and record the exact image digest used for each environment. Registry control governs supplied images; enforcing their exclusive use also requires host-side controls over image selection, local builds and imports, and container configuration. A registry allowlist alone does not prevent installation into writable containers or execution of software from mounted directories.

Security fixes and new Shyft releases can be delivered through an automated, governed lifecycle:

  1. Rebuild images from approved inputs with updated packages and Shyft versions.

  2. Validate security policy, API compatibility, and representative scripting tasks.

  3. Promote the tested image to an approved registry channel or deployment digest.

  4. Pull or preload the image on managed hosts and recreate affected containers at a controlled task boundary or maintenance window.

  5. Check readiness and retain the previous image and suitable state backups for recovery.

Publishing or pulling an image does not patch an already running container. Replacement starts the updated software while reattaching the persistent mounts. This preserves saved files, not running processes or unsaved in-memory work. Drain or checkpoint long-running tasks before replacement. Emergency security updates may require an explicitly governed interruption.

Podman provides systemd-integrated automatic updates for registry images or images already staged in local storage. This can implement the replacement step, but the rollout policy must account for its service restarts; automatic updates do not themselves determine whether a task is safe to interrupt. Where deployments pin immutable digests, management automation must explicitly select the newly approved digest. Record deployed digests even when following a moving, IT-controlled channel.

Registry access and its credentials belong to the managed host or provisioning service, outside the agent’s arena. Updating images does not require adding registry egress to the execution container. Air-gapped hosts receive approved images through the offline transfer process.

Updated Shyft clients, Python stubs, and local services must remain compatible with the APIs used by scripts. Separately deployed services have their own rollout lifecycle; updating a scripting image does not update those services. Likewise, packages or executables in persistent virtual environments and IDE directories can override image-provided software and require their own managed update policy. Image rollback alone cannot undo changes to persistent data.

Provisioned IDE state

Optional IDEs use a separately verified read-only backend, a sanitized reusable UI-only seed and private mutable runtime state. Inspect seeds before promotion; exclude logins, tokens, licenses, personal files and unintended integrations. Never implicitly promote runtime state back into a seed, and stop provisioning instances when finished. Optional IDE provisioning and named members describes the optional provisioning/import/snapshot and separate named-member branch; IDEs are not a CLI or containment prerequisite.

The CLI-first arena workflow operator guide implements the named workflow under this chapter’s policy. Its linked references distinguish disposable evidence from pending deployment, GUI/licensing, real-provider and full containment acceptance.

Host hardening and stronger containment

A managed workstation or VM can reinforce these practices with restricted administrative access, SELinux in enforcing mode, and application allowlisting such as fapolicyd. These controls have complementary roles: mandatory access policy constrains permitted interactions, while application allowlisting governs which software may execute according to the configured policy. Follow the distribution’s guidance, including its fapolicyd documentation.

Policies must accommodate legitimate compilation and execution of development outputs in the designated arena. Verify their coverage of rootless containers, interpreters, and build tools rather than assuming a host policy covers every execution path. The aim is a secure default with explicit, governed exceptions; the difficulty of bypassing a policy is not itself an enforcement guarantee.

For stronger containment, control network access at the development host or VM boundary as well as inside the container setup. Access to external repositories, file shares, and other services adds paths for importing untrusted material or exporting data. Permit only the destinations and operations required by the chosen deployment profile.

Where the required assurance excludes live external connections, an air-gapped development environment is a natural option. Inference must then run within that isolated boundary, and dependencies, model files, source, task descriptions, and results must pass through a governed offline transfer process. Browser-based planning takes place outside the air gap using only approved context. Imported material still requires review and verification; physical network separation does not establish its trustworthiness.

Task handoff and acceptance

Before execution, prepare a task with:

  • the objective, scope, exclusions, and source revision;

  • supplied inputs and permitted writable resources;

  • expected behaviour, domain constraints, and validation criteria;

  • resource and time budgets, and conditions requiring user intervention;

  • the expected deliverables and evidence needed for review.

During execution, the agent may inspect, edit, build, and test within that scope. Missing dependencies, required credentials, or unavailable services are reported to the user. The operator supplies approved inputs or explicitly revises the environment; the agent does not acquire new authority on its own.

At handoff, retain the patch or scripts, input revisions, actual validation results, and unresolved limitations. Review changes and validate important results independently of the agent’s summary. For business scripting, include data provenance and domain checks before operational use.

The responsible contributor or application owner accepts the result. Repository integration, signing, release production, and production deployment remain subject to existing authority and procedures. Neither successful agent tests nor containment makes generated output a trusted release artifact.

Operational governance

The environment operator owns containment configuration, provisioning, provider selection, resource limits, and monitoring. The task owner selects permitted data and accepts the work. Existing maintainer and release roles retain their documented authority.

Before enabling autonomous execution, verify both permitted and denied paths: inference works through the broker; direct external access and unapproved proxy destinations fail; unrelated host resources and credentials are unavailable; and IDE connections do not create unintended access. Repeat relevant checks after changes to networking, gateways, agents, or IDE integrations.

Keep configuration changes and exceptions reviewable. Logs should support diagnosis and accountability without unnecessarily retaining prompts, source contents, or credentials. If containment is suspected to have failed, stop the affected execution, preserve appropriate evidence, assess exposed resources, and follow Incident Response where applicable. Restore the arena from controlled inputs before resuming work.