Documentation Feature catalog
Run and test applications
Run an approved application separately from the coding agent, with its own secrets and only explicitly permitted test connections.
Product guide · implementation in progress
On this page
Current status: partial independent no-secret Service and fixed Channel
slices. Local tests exist; live two-Cell qualification, integrated policy,
secret-bearing Service runtime, persistent data, and replacement remain open.
Relay currently runs as a cellad child and needs privilege separation before a
protected claim.
This capability lets the application run beside the agent under its own permissions. The agent's writable candidate is separate from a Service Cell's sealed runtime inputs, application secrets, and persistent data.
Run Targets
A Run Target is an approved command definition. Bounded project discovery suggests targets; the user selects or adds them. An approved digest binds the argument array, manifest, runtime, Secret Set, candidate scope, network, resources, command-change behavior, approval, and evidence requirements.
An agent asks for a target ID and candidate digest. It cannot supply a replacement command, environment, Secret Set, runtime profile, or network rules. Changes to command definitions follow configured allow, session, require, always, or deny behavior; they do not silently inherit an earlier approval.
Project Secrets and secret-bearing runtimes
Project Secret Sets contain application runtime values, such as database
configuration. They are distinct from provider Connections. Importing .env
values is a separate secret-boundary operation; .env never enters repository
ingress, the Agent Cell, prompts, logs, checkpoints, artifacts, or evidence.
An exact Secret Runtime Binding projects approved values only to an eligible non-agent generation and lifetime. A secret-bearing Service has no attached agent, shell, debugger, or cross-process inspection. This prevents direct agent access to the secret; it does not prove that unreviewed application code cannot exfiltrate a value it receives. Secret-bearing code and permitted outputs need appropriate policy and review.
Services and Service Cells
A Cella Service is a named service identity and endpoint contract. A Service Cell implements it using an immutable revision or pinned artifact, approved Run Target, profile, network, resources, health definition, and explicit bindings. It can continue after the CLI or Agent disconnects.
A Connected Service is an enrolled endpoint running outside Cella, such as an existing database. Cella may mediate its traffic and observations; it does not claim that the external process is Wall-contained or that every other access path is governed.
Service observation can expose authorized redacted logs, metrics, traces, health, artifacts, and narrowly scoped restart/update operations. Source changes require a sealed candidate and a new service generation. Development policy may automate seal, build, health verification, and replacement; stronger policy may require an approved digest. A Channel transition to the replacement generation is explicit, and health-gated replacement and rollback are separate later gates.
Channels and Cella Relay
A Channel is a directional grant between exact endpoints. Cella Relay
(cella-relay, sometimes called the relayer) carries only its authorized traffic.
cellad authorizes the Channel; Relay does not own provider credentials or choose
a destination from an agent-supplied URL, host, or port.
A Channel binds Project, named Service, source and destination generations, protocol, permitted operation, direction, policy digest, expiry, and connection, request, byte, and time limits. Provisioned endpoint identity is trusted; a payload cannot declare itself to be another Cell.
Agent generation -> authorized Channel -> Relay -> named Service endpoint
stop / detach / expiry / revoke -> Channel closes; Service may stay runningIntended paths include Cell-to-Cell, Cell-to-enrolled-local-service, and explicitly authorized local-client preview. A grant does not expose every service port, filesystem, environment value, or host route. Wrong generations, direct routes, stale grants, over-limit requests, wrong operations, and post-revocation traffic must fail. Restart and reconnect must not revive expired authority.
Network, packages, and tools
Admitted tools and lockfile-derived package access use governed paths with resolved digest receipts. Private networks, metadata endpoints, undeclared localhost, arbitrary DNS/IP/port/Unix sockets, redirects, and tunnels are denied. There is no general Cell networking, wildcard host bridge, runtime socket, SSH agent, or credential socket. If Gateway, Relay, or the secret boundary is unavailable, its governed path blocks while permitted local work can continue.
Persistent data and Analysis Job Cells
A Data Volume is declared Cella-owned mutable service storage. A Data Snapshot is an immutable point-in-time identity. A Data Grant authorizes a specific read-only projection; it is not arbitrary mount permission. Database-native backup or consistency procedures are required before treating live database state as a usable snapshot.
An Analysis Job Cell runs one approved bounded task against exact data, parameters, resources, network, secret binding, and expiry. It may have database authority the Agent Cell never receives. A classified, redacted, content-addressed Artifact can then reach an Agent Cell through an exact read-only Artifact Grant. Object Transfer verifies ingress/export by digest rather than exposing caller-selected host paths.
Service data -> consistent snapshot -> approved Analysis Job Cell
-> bounded analysis artifact -> Artifact Grant -> Agent CellA policy may deliberately grant raw snapshot access to an agent, binding classification, snapshot digest, path, size, lifetime, model/provider policy, and network restrictions. Data visible to an agent can reach its model provider. Restricted data may instead require filtering, aggregation, a local model, an approved provider, or denial of raw access.
Example: the agent tests a backend's named endpoint through Relay. The backend uses its own database secret and volume. A separate analysis job returns only an approved report to the agent.
See service runtime and data, Channel flow, and Service milestone.
Source: docs/concepts/features.md · Current feature milestones