Permissions and policy

Current status: partial integrated policy slices. Restricted-YAML parsing, durable Project adoption, explanation/simulation, and exact shell, Service, Channel, and model grants are wired into cellad. Gateway Effects, Project Secret bindings, and complete cross-boundary enforcement remain incomplete. This is not the full proposed Policy Engine or complete workflow qualification.

Hierarchy and strict authoring

Effective authority intersects the installed Cella Security Floor with organization, Project, Workstream, Cell, and operation restrictions. A lower layer may preserve or narrow authority; it cannot widen an inherited boundary. Prompts, repository Markdown, model memory, and agent edits grant no authority.

A restricted YAML 1.2 authoring surface rejects duplicate keys, aliases, anchors, merge keys, tags, multiple documents, ambiguous implicit scalars, unknown fields, unsupported schemas, invalid destinations, unregistered operations, and over-limit structure. It normalizes into a format-independent policy IR; the original YAML bytes are not the authority representation.

Canonical compilation pins referenced profiles and operation definitions, produces an immutable digest, and retains source maps and provenance. Policy, template, or candidate changes invalidate stale approvals and Capsules.

Templates and custom operations

Versioned templates cover personal ephemeral work, repository review, development, PR authorship, service observation, and organization-restricted execution. They remain inspectable/editable convenience inputs, compile through the same hierarchy, and have no special authority.

Trusted installations or connectors can register namespaced versioned custom operations with bounded typed parameters, mediation classes, and exact mediator identity. Registration is not authorization. The catalog definition enters the Effective Policy digest; a repository cannot install mediator code or assign its own trust class.

Decisions, explanation, and simulation

A request includes actor, model, repository, Workstream, Run, generation, operation, destination, parameter digest, budget, and time. A decision returns allow, deny, or approval-required, plus matched rule, source, explanation, scope, expiry, and evidence requirements. Validation, explanation, simulation, and diffing must use the same evaluator as runtime decisions. Deny decisions and missing authority fail closed. Approval can satisfy only an exact permitted approval condition; it cannot override the Security Floor or an inherited denial.

Example: changing from Codex to Claude Code preserves the governing policy hierarchy, while requests are re-evaluated for the new actor, adapter, model, operation, and generation. The resulting grant may differ or be denied; handoff does not automatically broaden a Connection or inherit an earlier lease.

See Policy Engine and policy hierarchy.