net-kingdom/SECURITY-COMPANION.md

---
id: netkingdom-security-companion-v0.2
type: standard-companion
title: "NetKingdom Security — Working Companion v0.2"
domain: netkingdom
status: accepted
version: "0.2"
companion_to: canon/standards/security-layer-model_v0.7.md
owner: gate-house
publication_owner: net-kingdom
created: "2026-08-29"
updated: "2026-08-29"
review_interval: 3m
standard_token: security-companion_v0.2
---

# NetKingdom Security — Working Companion

**Start here.** This is the operative form of
[`canon/standards/security-layer-model_v0.7.md`](canon/standards/security-layer-model_v0.7.md)
(accepted): the same rules, without the change log or the review history.

The statute governs where the two disagree. **A disagreement is a finding** —
report it to `gate-house` rather than working around it.

For *how to get something done* in NetKingdom — which lane, which credential,
which route — ask `ops-warden`. This document says what the rules are;
`ops-warden` stewards the paths through them.

---

## 1. The four layers

| Layer | You are this if you produce | Deterministic |
| --- | --- | --- |
| **Taxonomy** | terms, semantic contracts, standards | n/a |
| **Tooling** | state and persistence | yes |
| **Engine** | a deterministic API for one modeled concept | yes |
| **Staff** | specifications, decisions, workplans, tasks | **no** |

One test decides it: **given the same authoritative inputs, do you always return
the same result?** If your core function is inference or judgment you are Staff,
however much of your work happens at runtime.

Engines carry a role — **PDP** (decides; `access-engine` only), **PIP**
(supplies facts as claims), **Evidence** (`audit-core`), **Lifecycle** (an API
over Tooling it owns). A new engine is a PIP unless the statute is amended.

## 2. Declare your layer

In your `INTENT.md` frontmatter, plus prose in your own voice in the body. A
layer someone else stated about you is not a declaration.

```yaml
layer: Staff          # Taxonomy | Tooling | Engine | Staff
role: null            # Engines only: PDP | PIP | Evidence | Lifecycle
```

Working references, both offered estate-wide: `ops-warden`'s `layer.yaml`,
`scripts/check_layer_conformance.py`, `tests/test_layer_conformance.py`;
`kings-guard`'s adaptation of the same for a repository with no Tooling
contacts at all.

**Contest the proposed layer if it is wrong.** Three repositories have returned
corrections that changed the standard; one talked us out of an exception we had
offered. A correction is worth more than a label.

## 3. The rules that bind everyone

1. **One decision point.** `access-engine` renders authorization decisions. No
   other repository, in any layer, renders or caches one.
2. **Compiled data that determines an outcome is still deciding.** A registry,
   cache, or schema that resolves a result before the engine runs decided early.
3. **Doctrine arrives as a claim.** Anything changing an outcome — authority
   ceiling, zone stance, posture, maturity level — reaches the decision as a
   request claim or a versioned policy rule. Never a side channel.
4. **Adaptive systems may only tighten.** Reduce, step up, request containment;
   never manufacture authority.
5. **Staff never touches Tooling directly.** Act through Engine APIs. See §4.
6. **Every allow has a lifetime** — a TTL, or a binding to a session or
   obligation that ends.

## 4. If you touch Tooling

"Tooling" means a system catalogued as Tooling in statute §4 — today `key-cape`
and `OpenBao`. Uncatalogued infrastructure (State Hub, `llm-connect`) is outside
the rule, but **list it anyway** so your conformance check is total. That
carve-out sunsets: an uncatalogued store another layer *reads* must, within two
review intervals, be catalogued or declared a gap.

| Shape | When | You must |
| --- | --- | --- |
| **Read-only diagnostic** | no engine exposes the read | declare it; no writes; it is a gap to close |
| **Conduit** | you run the *owner's* tool under the *caller's* identity | present no credential of your own, widen nothing, stay reconstructable as the caller |
| **Declared gap** | you must contact Tooling and no engine exposes it | declare `capability`, `intended_owner`, `blocked_on`, `review` — machine-readably |

A conduit presenting its own token is not a conduit. A declared gap is **tracked
non-conformance** — but declaring beats hiding, and it is never scored below
silence.

There is deliberately **no "operator of third-party Tooling" shape**. Someone
must run OpenBao, and that stays a declared gap whose review keeps returning,
because a clean operator shape would turn a tracked gap into a permanent
allowance.

## 5. If you cause side effects (you are PEP-shaped)

Being PEP-shaped does not change your layer. `ops-warden` issuing a certificate
and `ops-mason` opening a route are both Staff and both PEP-shaped.

1. **No side effect without a decision record** naming the request it was
   rendered for — **or** your declared stance permits proceeding and **you record
   the application of that stance in its place.** A fail-open result is metadata,
   never silence.
2. **Do not replay a verdict outside its own binding and lifetime.** Within them
   it is the decision being used as issued. The test is mechanical: replay is
   permitted iff the canonical request digest matches and the lifetime holds.
   Caching a DENY is permitted where the refusal is recorded against the request
   refused and the cache lifetime is declared.
3. **Publish your unreachable-engine stance map** — total, per zone or
   equivalent, no implicit default, no per-call discretion. **Publish it at a
   path named in your layer declaration, and register it in statute §13.1** — a
   map only you can read is not published. The published map MUST equal shipped
   behaviour; assert that with a test. Reference: `ops-warden`
   `ADR-0009` + `pep-stance.yaml`.
4. **Stay reconstructable**, within the bound in §6.

If `access-engine` is reachable but degraded, the fallback is the engine's. If it
is unreachable, the behaviour is necessarily yours — which is why it is declared
in advance rather than decided in the moment.

## 6. What you may never claim about evidence

An append-only archive with a verified chain proves records were **not altered or
truncated after arrival**. It proves nothing about an event never sent.

- ✗ "the audit record proves it happened"
- ✗ "there is no record, so it did not happen"
- ✓ "the archive proves the records it holds were not altered or truncated after arrival"

Which control covers which threat:

| Threat | Covered by |
| --- | --- |
| Accidental omission (crash between mutation and emit) | atomic emission via a **local** outbox — **prevented** |
| Adversarial omission (a compromised source suppresses) | cadence and reconciliation — **detected after the fact** |
| Adversarial omission at a compromised source | **nothing prevents it.** Known residual |

If a control's soundness depends on an event being present, that evidence is
**load-bearing**: emission must be atomic with the state change, queued locally,
and you **MUST** declare an expected cadence. For rare load-bearing events —
revocations, denials, containment — rate monitoring cannot work, so the required
NetKingdom profile is **heartbeat plus reconciliation**: a positive claim that
can itself go missing and a comparison of source transitions with accepted
evidence. The mechanically checkable overlay is
[`canon/standards/emission-cadence-security-profile_v0.1.md`](canon/standards/emission-cadence-security-profile_v0.1.md);
it imports the InfoTechCanon contract assigned by `GH-DEC-2026-004` and
remains proposed pending owner-instance validation.

Otherwise evidence is **attributive**: seek atomicity, and if you trade it away
deliberately, declare the trade and never describe the trail as complete.

## 7. If you are an agent

Same layer as your human colleagues, different blast radius:

1. **No standing credential.** Authority is per task, time-bounded, attributable
   to the principal you act for.
2. **Tool use is a conduit or an Engine API.** There is no third route. **Tool
   availability is not permission** — a callable tool means the operation exists,
   not that you may invoke it.
3. **Your memory is not a state plane.** Memory, tool-call traces, and prompt
   caches must not become state another layer depends on unless catalogued.
4. **Every action is reconstructable as the caller's action.**

Session semantics — session loops, tool policy, harness routing, model selection
— are `glas-harness`'s, not this standard's. Rule 2 is the seam between them, and
neither side is sufficient alone.

## 8. Conformance: four states

| State | Meaning |
| --- | --- |
| **Conforming** | no Tooling contact, or only declared diagnostic/conduit shapes |
| **Blocked-clean** | the capability does not exist because no engine exposes it, and you make no Tooling contact |
| **Declared gap** | a declared Tooling contact — tracked non-conformance |
| **Undeclared violation** | anything else |

**Blocked-clean is not worse than conforming.** Declining a shortcut and leaving
a capability at zero is compliance at cost, and will never be ranked below a
repository that quietly opened a client and said nothing.

## 9. If you operate workloads (Railiance)

Operations belong to **Railiance** (`railiance-master`), not to NetKingdom. A
workload is a managed running deployable, operated through four axes:
`railiance-*` ownership, `rail-*` execution contract, `rapp-*` managed package,
`reef-*` substrate. `rein-*` is **not** a fifth axis — reins are `glas-harness`
agent-harness backends.

What holds for any Railiance consumer of NetKingdom security: decisions come from
`access-engine` and nowhere else; approvals are objects in `approval-engine`
consumed as claims; credentials come from `secrets-engine` **after** a decision;
evidence goes to `audit-core` under §6's bound; anything causing a protected side
effect is PEP-shaped and owes §5.

**How the axes map onto the layer model is not settled** — see statute §20.3. Do
not assume a mapping; raising the question is welcome.

## 10. Two things the estate cannot do yet

Stated so nobody plans around a capability that does not exist:

- **Nothing is observed in production.** `kings-guard` has reported it has never
  seen a real event. Do not cite "observed in operation" as evidence.
- **Nothing can be contained automatically.** There is no actuation surface — no
  API to reduce authority, require step-up, or isolate a workload. The capability
  is at zero, not degraded, and it is nobody's gap to close alone.

---

**Statute:** [`canon/standards/security-layer-model_v0.7.md`](canon/standards/security-layer-model_v0.7.md) — accepted 2026-08-29.
**Owner:** `gate-house`. **Guidance on getting things done:** `ops-warden`.