OPEN SOURCE AGENT RUNTIME

A space for AI agents.
With boundaries
you define.

Give agents a place to build, test, and use services. Cella separates their execution from the authority to access resources, use credentials, and act outside their workspace.

Get Started View on GitHub

In development · CLI inspection available today

You / policyCellaExecution · access · actions

Agent CellPrivate candidate

Agent + tools. No host secrets.

Service CellSealed revision

backend-testRUNNING

An approved application runtime.

Code: Approved revision
Secrets: Scoped to this runtime
Lifetime: Independent of the agent

Application + authorized data.

Wall contains execution. Policy scopes access across boundaries.

Request an external action

cellad → GatewayPolicy-bound operation

Provider credentialsOutside both Cells

Effect policyrepo + branchALLOW

GitHubacme/backendPermitted push. Credential stays outside.

Evidencegit.push · ALLOW · result recorded

Intended architecture · interactive example

Useful access shouldn’t mean
unrestricted authority.

An agent may need your code, build tools, APIs, and a way to deliver changes. Giving it a shell should not also give it every host file, credential, service, or permission.

Inherited access

One shell. Too much within reach.

When an agent runs under your account, its tools may inherit access intended for you.

Source alongside personal and host files
SSH keys, API tokens, and cloud credentials
Services and external actions under your identity

Cella’s approach

Separate boundaries. Explicit access.

A Cell provides the workspace. Each connection or privileged action has its own permitted scope.

Workspace and tools admitted for the workload
Credential use mediated outside the Agent Cell
Named service endpoints and authorized external actions

How permissions work

Isolation includes where work runs, where authority lives, and how a permitted operation crosses the boundary.

Execution has a place.
Authority has a scope.

Cells, policy, credential mediation, and evidence share one control model. You define the boundaries; Cella admits the work and mediates the permitted connections and actions.

Isolate the work

Cells contain workloads with the workspace and tools their role needs. Agent and Service Cells separate editable source from an approved application runtime. Sandbox infrastructure is replaceable.

Keep authority separate

Policy scopes tools, resources, credential use, and approvals. Gateway mediates credential-backed access and Effects govern external actions. Application secrets can be bound to an approved Service Cell generation.

Permit the crossing. Record the decision.

Channels authorize access to named service endpoints; Relay carries that traffic. Evidence links an operation to its identity, policy decision, and result without combining the workloads’ permissions.

Explore the components

Intended workflow · one example Build, test, and deliver a backend change

Edit and test inside an Agent Cell
The agent changes its private candidate with the admitted coding tools.
Admit the application separately
Required checks and approval bind a Service Cell to a sealed revision and runtime inputs.
Call the permitted endpoint
A Channel through Relay allows the test request without exposing the service’s shell or credentials.
Review and deliver the change
An approved Effect performs the scoped delivery. The decision and result remain inspectable.

Shared contractIdentity · policy · evidence

Follow the work cycle

Give every operation
an explicit scope.

Permission to use a credential is permission for a scoped operation. Gateway keeps provider credentials outside Cells; approved Service Cells can receive separately bound application secrets.

✕ Raw credentials

Inside the agent’s environment

AWS_SECRET_ACCESS_KEY=…
GITHUB_TOKEN=…
SSH_PRIVATE_KEY=…

Reusable authority, exposed to the workload.

✓ Scoped operations

The agent asks. Cella decides.

git.pushs3.uploaddeploy.staging

agent:       codex
capability:  git.push
repository:  acme/backend
branch:      feature/api
decision:    ALLOW

Illustrative capability request.

Make permission
an explicit contract.

Define which tools and commands a workload may use, what it may read or edit, which endpoints it may call, and which external actions require approval. Access is checked against the effective policy for that work.

Bound the workspace.Source access does not grant access to personal files.
Scope the operation.A Git push can be limited to one repository and branch pattern.
Keep denials final.The agent’s prompt cannot expand its permissions.

Explore policy and approvals

policy.example.yaml

agent: codex

allow:
  filesystem:
    - ./workspace/**
  network:
    - api.github.com
  channels:
    - service: backend-test
      methods: [GET]
      paths: [/health]
  capabilities:
    - git.commit
    - git.push:
        repository: acme/backend
        branches: [feature/*]

deny:
  filesystem:
    - ~/.ssh/**
    - ~/.aws/**
    - ~/.config/**

Illustrative policy. Syntax is not the final Cella API.

Know what happened.
Know what allowed it.

Inspect the action, its inputs, the policy that applied, and the result. Evidence connects autonomous work to the authority it used.

Event detailDENY

Workstream: backend-health
Agent: codex
Session: example_run_01
Action: fs.read
Arguments: ~/.ssh/id_ed25519
Policy matched: deny.filesystem: ~/.ssh/**
Result: Refused. No host key read.
Timestamp: 2026-10-08T14:32:21Z

Illustrative records. Select an event to inspect its decision.

From a task
to a reviewed change.

1
Define the task and policy
Set scope, limits, and approval requirements.
2
Start an Agent Cell
Admit a private candidate and coding tools.
3
Build and check a change
Produce a candidate tied to exact inputs.
4
Run the approved application
A Service Cell gets its own runtime authority.
5
Test through a Channel
Permit the endpoint and scope the request.
6
Review, deliver, and continue
Retain evidence and checkpoint for the next run.

Illustrative Workstream · intended behavior

workstream: backend-health

✓ candidate checked
✓ sealed service revision admitted
✓ channel: backend-test / HTTP

agent run       paused · approval needed
service         running · own lifecycle
checkpoint      sealed · ready to resume

Next run: restore declared task state,
re-evaluate policy, issue fresh grants.

Use the same model for daily development, a reused project Cell, or remote work that continues between visits. This complete workflow is in development. Try today’s CLI →

Cells use replaceable sandbox infrastructure. The first isolation target is containerd + gVisor on Debian; protection requires qualification for the exact runtime profile. Read the Wall contract →

Built in the open.

Run Cella on infrastructure you control. Inspect the boundaries, extend the runtime, and help test how agents work within them.

Build the CLI today. The complete protected Agent and Service Cell workflow is still in development. Managed infrastructure is planned for later.

View on GitHub Contribute Apache 2.0

Common questions.

Explore the docs

Is Cella a coding agent?

You bring the agent. Cella provides its working environment and the boundaries around access, communication, and external actions. The same model supports local development, remote work, and reusable project Cells.

How is Cella different from a sandbox?

The sandbox contains execution. Cella also defines where authority lives and how it may be used: tool and resource permissions, credential-backed operations, service connections, approvals, and evidence. These boundaries share the same identity and policy model. Explore the architecture.

Can I keep using the same Cell?

That is the intended workflow: explicitly select a project Cell again, with retained work where policy permits. Its identity continues across Runs. Changed permissions or other admitted inputs require a new generation, and continuation revalidates access. The complete reuse and checkpoint workflow is still in development. How Cell reuse works.

Can Cells work together?

Through declared interfaces. An Agent Cell can request access to a named service endpoint through a bounded Channel carried by Relay. That does not combine their permissions. General agent-to-agent messaging would need an additional contract. Understand Channels and Relay.

Why separate Agent and Service Cells?

The agent needs editable source and coding tools. An application needs an approved runtime, storage, and sometimes secrets. Separate Cells give each its own authority and lifecycle. A bounded Channel lets the agent interact with the application. Read about services and secrets.

Does the agent get my credentials?

Cella is designed to keep protected credentials outside the agent’s sandbox. The agent requests a scoped operation, such as pushing to an approved repository and branch, while Cella mediates access and records the result. Explore permissions and approvals.

What can I try today?

You can build the open-source CLI or use the Debian CLI-only bootstrap, inspect its commands, and run read-only runtime checks. The complete protected coding-agent workflow is still in development. Get started with the CLI.

Give agents room to work.
Keep authority under control.

Get Started View on GitHub

A space for AI agents.With boundariesyou define.

Useful access shouldn’t meanunrestricted authority.