taudit, tsafe, and CellOS are three separate tools. Each one works standalone. But they were designed to compose — and the composed system is qualitatively different from the sum of the parts.
The loop is: detect over-authority → constrain secrets → isolate execution → observe again. Each tool owns one step, routes findings to the next, and the cycle closes.
The problem each tool sees in isolation
Running taudit alone tells you where authority leaks. Running tsafe alone scopes secrets at the invocation boundary. Running CellOS alone isolates execution. None of them, by themselves, close the loop.
Consider a real finding:
taudit found the propagation path and routed the remediation to tsafe. But tsafe exec just scopes the secret at the process boundary — it doesn't prevent the build step from making arbitrary network calls. That's where CellOS comes in.
How findings route between tools
| Finding category | Routes to | What that tool does |
|---|---|---|
| AuthorityPropagation | TsafeRemediation | Scope the secret to exactly the steps that need it; strip parent credentials |
| OverPrivilegedIdentity | TsafeRemediation | Narrow the GITHUB_TOKEN scope declaration in the workflow |
| UntrustedWithAuthority | CellosRemediation | Isolate the step in a cell with explicit secretRefs and network egress allowlist |
| ArtifactBoundaryCrossing | CellosRemediation | Produce artifacts through declared export channels, not ambient filesystem |
| LongLivedCredential | TsafeRemediation | Replace static credential with scoped injection via tsafe exec |
The routing is typed — TsafeRemediation and CellosRemediation are distinct recommendation variants in the finding model. The tool that emits the finding knows which layer fixes it.
Walking a scenario end to end
Start with a real workflow. taudit scans it:
Step one: fix the identity scope in the workflow YAML (taudit's OverPrivilegedIdentity finding). Step two: wrap the build step with tsafe exec:
Now the secret is scoped to this process only. But the build step still has arbitrary network access. Step three: move the step into a CellOS cell:
Rescan:
The loop closed. taudit detected, tsafe constrained, CellOS isolated. The final scan produces no findings because the authority graph now matches what the workflow actually needs.
The composability is by design
| Layer | Input | Output | Routes to |
|---|---|---|---|
| taudit | Pipeline YAML | Authority graph + findings with propagation paths | TsafeRemediation or CellosRemediation per finding |
| tsafe | tsafe exec invocation | Scoped secret injection; parent credentials stripped; every exec logged | CellOS cell spec (secrets declared in secretRefs) |
| CellOS | Cell spec (JSON contract) | Isolated execution; CloudEvents lifecycle trail | taudit (rescan to verify no findings remain) |
Each tool's output is the next tool's input. taudit findings reference tsafe commands. tsafe's secret namespaces map to CellOS secretRefs. CellOS CloudEvents feed back into taudit's observability picture.
0sh in the loop
0sh is the authoring language that sits across all three tools. A 0sh script declares its effects (uses_secrets, network_access, writes_filesystem) at plan time. Those declarations are the cell spec. The 0sh LSP in tedit surfaces taudit findings inline as you write. The entire loop becomes visible at development time, not just in CI.
Why the loop matters
Most security tooling is advisory. It tells you what's wrong and leaves remediation as an exercise for the reader. The governance loop is different: each tool knows which layer fixes its findings, and the remediation commands are generated, not described. Run taudit, get a tsafe exec command. Run that command in a CellOS cell spec. Rescan. Done.
The authority model is not an add-on to the execution model. It is the execution model.