Chris Criner Operations · systems · working software
Menu

Case study · flagship

Company OS

Agents can already act. The usual answer is Docker plus a second .env file. That jails the process. It does not decide who may act, which tools a worker is granted, or what evidence remains after the fact.

Public site GitHub v0.5.0-rc1 pre-release

The problem

On one Linux host, people now run several agents — work vs personal, two clients, a research bot next to a mail bot. They share a user account and often one environment file. If a token exists in that shared environment, any agent can use it. “Confirm before acting” is frequently just a prompt. Prompts get ignored. After a bad send, there is nothing to open in the morning except rotated logs.

Company OS is the authority layer around that mess: named companies, grants that are not raw keys, HOLD/DENY before irreversible work, receipts after. It is not a process or syscall sandbox. If the pain is “jail the process,” use Docker.

Architecture, in ordinary language

The engine is a Python package. A company is a directory: its own tenant.json, sqlite database, token, and port. The platform control plane lists companies on loopback http://127.0.0.1:8760/. Dashboards never bind 0.0.0.0.

  • Multi-tenant isolation. Tenant A’s work, receipts, and database are not visible to tenant B. Opening the wrong sqlite as the wrong tenant fails closed.
  • Scoped authority. Capabilities are grants — allow, hold, or deny — not API keys copied into config. Secrets stay in a 0600 file and are not printed in HTML.
  • ALLOW / HOLD / DENY. ALLOW runs. HOLD queues for an owner. DENY refuses. Defaults: public intake can be allowed; publish and spend hold; marketplace writes deny.
  • Approvals and receipts. An approved row is evidence that an owner clicked. It does not, by itself, publish or spend. Completing work writes a receipt; completing already-done work is refused.

What a grant looks like

Sanitized example language, matching the public Cedar Clippings sample — not live operator state.

ALLOW intake HOLD publish HOLD spend DENY marketplace

Adversarial security work

Security Baseline 1.2.0 is frozen. The claims are mapped to tests in docs/SECURITY_MODEL.md and docs/security/guarantees.json. A green run is necessary, not a certification.

Composition was the defect class we actually broke and then fixed: two steps that each looked safe combining into something unsafe (restore installing secrets; status echoing event payloads; duplicate complete receipts; empty capability maps upgrading to ALLOW; spend self-approving). Those are in the public security model, not a private war story.

82 tests pass on the public tree (python3 -m unittest discover -s tests). Outsider clone from GitHub and bash scripts/docker_eval.sh are expected to print EVAL_OK, with no dashboard and no 0.0.0.0.

Out of scope, stated on purpose: compromised host, in-process sqlite access, kernel sandbox, WAN-published dashboards, executing scraped text as code.

Public release

Discovery / evaluation release 0.5.0-rc1, Apache-2.0, GitHub account TheCriners. Not production 1.0. Not a product-market-fit claim.