Skip to main content

Governance (Deny-Closed)

Most systems permit and log. System9 refuses at the boundary and records the refusal. Governance here is not a filter on a prompt or a warning in a UI, it is an authorization decision made at the point an action would take effect, and its default posture is deny-closed: an asset with no governance bound to it is refused, not served open.

This is the most under-sold property in the platform. The question to ask any platform is "what does it refuse, and where is the record of the refusal?", and permit-and-log is the industry's default answer.

In this area​

  • The two-stage gate: a decision-boundary gate that judges a proposed action by its net potential gain across the whole system, and can refuse it. It implements the value primitive of the open substrate-alignment standard.
  • Capability control and approval: gating a grant on grantee trust, sensitivity, and blast radius, with human approval as a first-class step. Includes N-of-M dual control, where M distinct approvers must each cryptographically sign before a sensitive operation runs.
  • The authoritative deny: one canonical grant graph as the source of truth, where a single revoke denies serving at every face at once.

What deny-closed means​

Deny-closed is a precise posture, not a slogan: absence of a positive authorization is a denial. On the serving path, an asset is served only if at least one enabled policy governs it; an empty or disabled-only policy set means the asset is ungoverned, and ungoverned is denied. An operator turns "ungoverned, therefore denied" into "explicitly available" by binding an explicit allow policy, the asset becomes governed by a positive authorization rather than open by default.

Deny-closed has a sibling discipline, fail-closed: when a policy source fails (a loader raises rather than returning cleanly) the decision is deny. "No policy configured" and "the policy source failed" are treated as different events, and both resolve safely.

Refusal is first-class​

Because refusals are decisions rather than errors, they are enumerable. Across the platform, the gate refuses (and records) actions such as:

  • A net-negative action scored across the affected entities.
  • An agent's own consequential act beyond its authority (halt-and-escalate).
  • Raw rows attempting to leave a clean room (deny-all egress by default).
  • An unsigned or badly-signed policy (the cell holds last-known-good).
  • A schema a peer does not speak (a typed wire error, not silent corruption).
  • A workflow placed on a cell below the required clearance (a hard constraint).
  • A capability a workspace may not hold (capability control, strictest-wins).
  • An operation that cannot be enforced, returned as an explicit refusal rather than accepted and ignored, because an unenforced deny is a false assurance.

Core and edge​

The deny-closed and Net Potential Gain disciplines hold on both runtimes. On the cell, governance is realized through the canonical grant graph and the serving gates. On the Edge Agent, authorization runs locally through a default-deny policy engine with hard-wired red lines checked first, followed by the same NPG evaluation, both must pass. A revoke denies immediately within a cell; across an air gap, a grant made on one cell is not visible on a peer until they reconcile, which is a property of the air gap and is raised as a known limit rather than hidden.

  • Roles and permissions, the catalog this model governs: every permission, its risk tier, and what each built-in role can do.
  • Identity & Access, the attenuable grants that governance gates and revokes.
  • Data Governance, the in-engine enforcement plane (row filters, column masks, lineage) that this model governs.
  • Compliance & Audit, the tamper-evident records that governance decisions are designed to produce.