Behavioral gates

A gate exercises one contract, and its self-test exercises the gate

A gate is a script under scripts/ that inspects source, runs a targeted test suite, or drives a fixture, then exits non-zero when it finds a violation. Its self-test is a second script that checks the gate's own contract. Most self-tests hand the gate, or a mutated copy of it, an input built to fail and require the refusal.

The runner has failure modes of its own: a filter that selects no tests, a renamed case that drops out of an inventory, a script that discards a failing exit status. Self-tests catch those. A passing self-test says the verifier works; the gate run against the candidate says the behavior holds. Retain each with its own command, source, output, and exit status.

A passing gate covers the layer it reaches

Each kind of check observes a different part of the implementation:

• Structural gate. A required field or construction site is still present in source.
• Unit test. A decision holds for the selected inputs.
• Durable-state exercise. Behavior survives a restart against the durable store.
• Kernel run. An operating-system restriction is in force on the host.

The tests the gates run assert typed refusals from library functions. The flow gate's engine tests expect FlowDenial::TopSource ("top-labeled data cannot egress") and FlowDenial::DeclassificationReplay ("declassification grant is already consumed"); the deception gate's lifecycle tests expect LifecycleError::IllegalEdge ("decoy lifecycle edge is illegal") and LifecycleError::ReplacementRequired ("an armed replacement is required"). A tool caller sees a signed Deny instead: on the Linux native process host, a top-labeled egress denial arrives with the reason security dispatch outcome requires reconciliation: security native dispatch capture callback failed; authoritative recovery required.

Keep each full gate run's command, trigger, source, stdout, stderr, and exit. A post-push qualification run is reported as post-push, and an interrupted compile is an incomplete attempt even when another self-test succeeded.

Four gates block every merge; the rest report after it

The required Build, lint, test job in ci.yml runs on every push to main and every pull request to main, so its failures block merging. For several gates that job runs only the self-test, and the gate itself runs after a push to main or when an operator starts it.

The gates that check behavior of the installed product ship with it. An operator runs them on the serving host with chio security selftest, one suite per gate: cage, restart, caller-delivery, deception, temporal, keyring, and broker. Each run is retained and reported as host qualification, and every release records the full gate run behind it, which chio release verify --evidence qualification shows for the release you run.

Read more in Engineering standard, which states the rule each gate checks.

The temporal gate keeps a forged event out of every durable table

An attacker keeps a well-shaped detector event and signs it with an untrusted key. The temporal ingress verifier must return an integrity failure before the event reaches any durable correlation or advisory table, while the legitimate neighbor, signed by the configured producer under the same tenant and time expectations, still enters verified ingress. A gate that refused both would show nothing useful.

The temporal suite runs ten test inventories covering rule validation, event-time correlation, producer and receipt provenance, and seven ingress mutations, and it checks the inventory's exact count and digest before any test executes. Run it on the host that ingests detector events:

chio security selftest temporal --evidence ./temporal-evidence

suite            result
temporal         pass   10 inventories, 40 tests
1 suite passed; evidence in ./temporal-evidence

./temporal-evidence keeps the suite log, its exit status, and a SHA-256 manifest. The suite's database oracle confirms the refused event is absent from security_verified_events, security_correlation_ingress, security_correlation_events, and security_advisory_events, then admits a current valid event and observes one verified row and one ingress row. Those rows say nothing about a network receiver or a physical containment effect.

Seven altered events stop at ingress, and the neighbor still lands

In the pricing project, a forged detector event claims the fixer touched /secrets. The forged case signs the original event body under another producer, so the request reaches signature verification instead of failing in a parser:

#[test]
fn verifier_ingress_rejects_forged_event_without_persistence() {
    assert_ingress_mutation_rejected(
        "forged",
        PortErrorKind::IntegrityFailure,
        |trusted, _receipt_signer, untrusted| {
            let event = current_ingress_event(trusted);
            let signed: SignedSecurityEvent =
                serde_json::from_slice(event.source_evidence.as_bytes())
                    .unwrap_or_else(|error| panic!("decode forged event body: {error}"));
            resign_event(event, signed.body().clone(), untrusted)
        },
    );
}

The full helper builds a fresh SQLite ingress for each case and inspects its tables after the refusal. Forged, unsigned, untrusted, cross-tenant, stale, future-dated, and invalid-receipt events each refuse at ingress, and each case preserves the valid neighbor that still inserts.

Read the three results together. The suite shows the ten inventories ran under their pinned names and refuses missing, renamed, or filtered cases; the typed failure shows the intended boundary refused the altered event; the inserted neighbor shows the boundary still admits useful work. None of them qualifies a Linux cage, a secret, or an external effect, which have their own gates.

Read more in Security events, which covers producer keys and freshness at ingress.

Next: tie a gate to the threat it covers