Four returns arrived overnight, two of them corrections to rules written yesterday. Both corrections are right. A-16 GAINS A RIDER. informed-decision pointed out the rule is silent on who writes the route marker, and the guarantee is only as good as that party's independence from what the marker asserts. Its own instance is the weak one: erased versus never-held is written by the party the evidence is about, so A-16 there reduces to a self-attestation and GH-DEC-2026-014 section 4 narrows it without removing it. Without the rider A-16 becomes the thing it exists to prevent — a sound check read as establishing a property it does not carry. The four instances are now graded by marker independence rather than listed as equals. A-17 GAINS A PRECONDITION. It asks which way a case fails, which is unanswerable where the case cannot be seen. Their commitment-only path had no failure direction at all as proposed: a reviewer got a blank, indistinguishable from erased, withheld, lost and never held. GH-DEC-2026-014 section 4 did not test the direction of failure, it manufactured one — the right outcome reached without noticing it was a different operation. So making the distinguishing case observable is a precondition of applying A-17, not an outcome of it, and A-17 therefore depends on A-16. Neither dependency was noticed when both were written a day apart. GH-DEC-2026-015 revises GH-DEC-2026-012 R3. approval-engine recommended exactly the option we refused, informed-decision could not comply with both, changed nothing, and raised it as a finding rather than choosing — having previously offered to let approval-engine settle R3 and declined to take that route twice. Nesting is permitted for this pair. The cycle objection needed mutual containment and approval-engine's digest structurally excludes presentation material for an independent reason. But the decisive ground is that the original ruling worked against its own rule: R3 forbade recomputing the other layer's digest from one's own vocabulary, and co-reference by identifier left informed-decision canonicalizing principal and target, two of the five fields in that digest. Nesting removes the duplication; co-reference manages it. We reached for the management option while stating the rule that recommends removal. Conditioned on approval-engine making the exclusion normative and tested rather than intentional, because the cycle cannot arise here is a belief and the cycle may not arise here is a rule with an owner — A-17's precondition applied to our own permission. The ordering objection is withdrawn as mistaken and the withdrawal is recorded: a cost accepted from the requester and never checked is how a wrong reason survives into a ruling. GH-DEC-2026-016 rules NC-03, which both repositories referred up and neither benefits from. Where an approval is declared as discharging a human-in-the-loop control, the approver must be a human principal and approval-engine must refuse at bind time rather than record it. Recording the principal type is the auditable half and stops nothing; an approval control satisfiable by the same class of actor it exists to check is theatre. Scoped to declared approvals, declared at issue and never inferred, on approval-engine's own pdp_path shape. One surface enforcing it is not the property being held — the guarantee would read as human-approved unless someone used a different client. Section 5 leaves what makes a principal human to the identity layer and notes it inherits A-16: refusing a service principal while accepting an unverified assertion of humanity moves the defect rather than closing it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012viPor8WJNCbV64ipwewrm Assistant: claude-code Assistant-Model: opus Assistant-Process: 1754332@bnt-lap001 Assistant-Session: 9c8ac536-ff5e-46a3-8ab1-a548bde25fc0
472 lines
23 KiB
Markdown
472 lines
23 KiB
Markdown
# Gate House — INTENT
|
|
|
|
**Repository:** `gate-house`
|
|
**Project family:** NetKingdom
|
|
**Layer:** Staff
|
|
**Status:** Re-cut as the security and defence doctrine council
|
|
**Version:** 0.3
|
|
**Date:** 2026-09-10
|
|
**Supersedes:** v0.1 (2026-08-24), which framed Gate House as a deterministic authority plane. See `history/2026-08-28-security-layer-model-and-gate-house-recut.md` for why that framing was withdrawn.
|
|
|
|
## The Mission
|
|
|
|
> **Gate House is the council where NetKingdom's security and defence doctrine is established, documented, taught, and supervised.**
|
|
|
|
It is the headquarters of the operational staff that does the chores of IT
|
|
security in NetKingdom: the place where the conceptual model of the security
|
|
architecture is worked out, written down, taught to the humans and agents who
|
|
have to live by it, and checked against what the estate actually does.
|
|
|
|
A word about the name, because it argues the other way. A gate house sounds
|
|
like the thing requests pass through. It is not. In a real castle the gate
|
|
house is where the guard is quartered, the watch is set, and the porter's rules
|
|
are posted — the rules of entry are decided there, and the gate itself is
|
|
somewhere else, held by someone else. That is exactly the split intended here.
|
|
|
|
> **Gate House does not stand in the gate. It decides what the gate is for, who
|
|
> may be asked to open it, and how we know it held.**
|
|
|
|
---
|
|
|
|
## Where Gate House Sits
|
|
|
|
NetKingdom's IT security is layered by determinism and by the kind of artifact
|
|
each layer produces:
|
|
|
|
| Layer | Character | Artifacts | Members |
|
|
|---|---|---|---|
|
|
| **Aspects / taxonomy** | cross-cutting language | terms, semantic contracts | info-tech-canon |
|
|
| **Tooling** | deterministic infrastructure; consistent, performant, scalable state | data structures, persistence | authelia, lldap, privacy-idea — packaged as key-cape; OpenBao |
|
|
| **Engines** | deterministic APIs for a modeled concept | interfaces, contracts | user-engine, tenant-engine, zone-engine, secrets-engine, access-engine |
|
|
| **Staff** | interactive, non-deterministic; management, operations, change, innovation, controlling | specifications, decisions, workplans, tasks | **gate-house**, ops-mason, ops-warden, kings-guard, whitehat-security |
|
|
|
|
Gate House is Staff. Its outputs are specifications, decisions, workplans, and
|
|
tasks, produced through interaction with assistants and autonomous agents. It
|
|
holds no state that anything else depends on at runtime.
|
|
|
|
The layer model carries one rule, and it is the architectural form of "no
|
|
privilege from cognition":
|
|
|
|
> **Staff never touches tooling directly. It acts only through engine APIs.**
|
|
|
|
This is why kings-guard — agentic, therefore Staff — may contain a threat only
|
|
by calling an engine, never by reaching into OpenBao itself. It is why an
|
|
autonomous coding agent gets no shortcut. And it is checkable: a Staff
|
|
repository holding a direct database or OpenBao client is violating the model.
|
|
|
|
---
|
|
|
|
## Why Gate House Is Not the Decision Point
|
|
|
|
Gate House was seeded as a deterministic authority plane — a policy decision
|
|
point with an `/authorize` API, grant storage, and a revocation service. That
|
|
was wrong, and it was wrong by its own argument:
|
|
|
|
> **A decision point inside Gate House would place the deterministic authority
|
|
> boundary inside the non-deterministic management layer, violating INV-02, "No
|
|
> Privilege from Cognition" — the first invariant this repository exists to
|
|
> defend.**
|
|
|
|
The repository would have been the clearest available counterexample to the
|
|
canon it hosts. NetKingdom already has a policy decision point: `access-engine`
|
|
(currently `flex-auth`). It stays the only one. Gate House writes the doctrine
|
|
that decision point implements, and checks that it did.
|
|
|
|
The boundary, in one line:
|
|
|
|
> **The mandate and the operating mode are Gate House's. The decision is
|
|
> access-engine's. The credential is secrets-engine's. The perimeter is
|
|
> ops-mason's and ops-warden's.**
|
|
|
|
---
|
|
|
|
## Responsibility Boundaries
|
|
|
|
| Component | Layer | Primary responsibility | Relationship to Gate House |
|
|
|---|---|---|---|
|
|
| **info-tech-canon** | Taxonomy | semantic contracts, shared terminology | supplies the vocabulary discipline Gate House writes within |
|
|
| **net-kingdom canon** | Taxonomy | NetKingdom standards of record | receives Gate House's invariants as canon |
|
|
| **key-cape** | Tooling | IAM profile, authentication, federation | establishes authenticated identity |
|
|
| **OpenBao** | Tooling | secret storage, leases, PKI, dynamic engines | protects and issues credential material |
|
|
| **user-engine** | Engine | users, accounts, memberships | supplies subject context |
|
|
| **tenant-engine** | Engine | tenant and organizational boundaries | supplies tenancy context |
|
|
| **zone-engine** | Engine | zone identity and membership | supplies zone membership facts |
|
|
| **secrets-engine** | Engine | credential abstraction, custody, lifecycle | materializes authority as credentials |
|
|
| **access-engine** | Engine | the policy decision — may this actor do this | **the only decision point**; consumes Gate House's authority context and invariants |
|
|
| **ops-mason** | Staff | builds and tears down access routes and perimeters | implements the perimeter doctrine |
|
|
| **ops-warden** | Staff | operational access lanes, stewardship, runbooks | owns the lanes; Gate House owns the doctrine |
|
|
| **kings-guard** | Staff | adaptive defence, observation, containment | supplies posture; bound by the posture asymmetry |
|
|
| **whitehat-security** | Staff | offensive validation | executes Gate House's assurance specifications |
|
|
|
|
A useful shorthand:
|
|
|
|
```text
|
|
info-tech-canon names
|
|
key-cape authenticates
|
|
user/tenant/zone contextualize
|
|
access-engine decides
|
|
secrets-engine provisions
|
|
OpenBao protects
|
|
ops-mason builds
|
|
ops-warden operates
|
|
kings-guard defends
|
|
whitehat-security challenges
|
|
|
|
gate-house establishes the doctrine all of the above are held to
|
|
```
|
|
|
|
Note the two words that must not drift: **ops-warden and ops-mason own access
|
|
lanes** — how a worker reaches a host. **access-engine owns access rules** —
|
|
whether they may. Gate House owns neither, and says so here because the word
|
|
"access" is used for both across the estate.
|
|
|
|
---
|
|
|
|
## What Gate House Owns
|
|
|
|
- **The doctrine.** The Active Secrets Management Canon, its invariants, and
|
|
the argument behind them. Invariants graduate into
|
|
`net-kingdom/canon/standards/` as they stabilize; the working canon lives here.
|
|
- **The authority context schema.** The vocabulary of an agentic authority
|
|
request — principal, actor, runtime identity, tenant, environment, mandate,
|
|
task, operating mode — defined here and consumed by access-engine as input
|
|
claims. Gate House defines what must be *sayable*; access-engine decides what
|
|
it *means* for a given request.
|
|
- **The agentic operating modes.** Assistant and autonomous as distinct
|
|
security regimes, with the requirements attaching to each.
|
|
- **Mandates, authority ceilings, and kill switches** for autonomous actors —
|
|
as a model and a governance obligation, not as a runtime service.
|
|
- **The Change Dynamics Envelope.** How much change the organization is
|
|
prepared to tolerate, expressed so that engines and Staff can bound it.
|
|
- **The MCP and tooling doctrine.** Tool availability is not permission.
|
|
- **The posture contract** with kings-guard, including the asymmetry.
|
|
- **Conformance review.** Whether an actor's authority in practice matches its
|
|
declared mandate and ceiling — the observability of governed authority.
|
|
- **The assurance specifications** T-01…T-10, executed by whitehat-security.
|
|
- **The security curriculum.** What operators, assistants, and autonomous
|
|
agents are expected to understand before they are trusted with authority.
|
|
|
|
## What Gate House Does Not Own
|
|
|
|
Gate House holds no runtime position. It does not own:
|
|
|
|
- the authorization decision, policy evaluation, or any `/authorize` surface;
|
|
- policy engine selection, policy packages, or policy rollout;
|
|
- grant storage, credential issuance, leases, or revocation;
|
|
- identity, tenancy, zone, or user lifecycle;
|
|
- secret storage, PKI, or scanning;
|
|
- anomaly detection, threat intelligence, or behavioral risk inference;
|
|
- access lanes, SSH certificates, tunnels, or host hardening;
|
|
- deployment, reconciliation, or remediation execution;
|
|
- the workplans of other repositories.
|
|
|
|
That last one matters. Work structure belongs to the repository doing the work.
|
|
Gate House sets doctrine and reviews conformance; it does not accumulate other
|
|
repositories' tasks, and an HQ that starts managing the estate's chores has
|
|
become a second decision point wearing management clothes.
|
|
|
|
---
|
|
|
|
## Foundational Principle
|
|
|
|
> **Cognition proposes. Authority disposes. Infrastructure executes.**
|
|
|
|
Read across the layers, that sentence is NetKingdom's layering rule, not only
|
|
its security maxim: Staff proposes, Engines dispose, Tooling executes.
|
|
|
|
## The Core Security Question
|
|
|
|
The doctrine Gate House maintains exists so that, for any privileged action,
|
|
the estate can answer:
|
|
|
|
```text
|
|
WHO principal, actor, runtime identity
|
|
WHERE tenant, environment, zone, resource
|
|
WHAT requested operation
|
|
WHY task, mandate, delegation
|
|
UNDER WHICH policy, approval, posture, quotas, budgets
|
|
UNTIL WHEN TTL / expiry
|
|
→ a deterministic decision, rendered by access-engine, reconstructable afterwards
|
|
```
|
|
|
|
Deterministic does not mean static. Context changes continuously. The rule is
|
|
that the final privilege boundary is enforced by explicit policy rather than
|
|
model judgment, and that the same authoritative input state yields the same
|
|
decision.
|
|
|
|
---
|
|
|
|
## Domain Vocabulary
|
|
|
|
Gate House owns these terms. Other repositories should use them rather than
|
|
synonyms:
|
|
|
|
- **Principal** — the human, organization, workload, or system on whose behalf
|
|
authority originates.
|
|
- **Actor** — the entity directly attempting the action.
|
|
- **Runtime Identity** — the concrete workload instance performing execution.
|
|
- **Mandate** — standing organizational authorization defining what an
|
|
autonomous actor is intended to do.
|
|
- **Delegation** — a scoped transfer of authority that does not collapse
|
|
principal and actor.
|
|
- **Authority Ceiling** — the maximum authority an actor can obtain.
|
|
- **Operating Mode** — assistant or autonomous; a security regime, not a
|
|
deployment detail.
|
|
- **Posture** — a bounded security-state input from a trusted source.
|
|
- **Change Dynamics Envelope** — the tolerated rate, scope, concurrency, and
|
|
duration of change.
|
|
- **Decision Evidence** — the record explaining which policy, identities,
|
|
inputs, and conditions produced a decision.
|
|
|
|
---
|
|
|
|
## Agentic Operating Modes
|
|
|
|
The distinction Gate House exists to keep sharp.
|
|
|
|
### Assistant
|
|
|
|
A human is actively engaged and can observe, redirect, approve, or stop actions
|
|
at human latency. The human remains the principal; the agent remains a visible
|
|
actor. The human's credentials are not dumped into the agent's environment.
|
|
|
|
**A human disconnecting must never silently promote the session into autonomous
|
|
privileged operation.**
|
|
|
|
### Autonomous
|
|
|
|
A scheduled, triggered, or event-driven agent acts without continuous
|
|
supervision. Bounded by policy and governance rather than by human reaction
|
|
time, it requires: unique identity; a named owner; an explicit mandate; an
|
|
authority ceiling; environment and resource bounds; runtime and concurrency
|
|
limits; credential TTL; token, compute, and tool-call budgets; an independent
|
|
kill switch; lifecycle termination; and audit reconstruction.
|
|
|
|
---
|
|
|
|
## Change Dynamics
|
|
|
|
Agentic systems change infrastructure faster than humans can review. The
|
|
envelope names what the organization will tolerate: concurrent mutating actors,
|
|
actions per grant, resources per task, task duration, credential TTL, agent
|
|
chain depth, deployment frequency, destructive-action quota, compute and token
|
|
spend, read/write separation, reversible versus irreversible action classes.
|
|
|
|
Economic budgets are useful blast-radius controls. **They are never
|
|
authorization.**
|
|
|
|
## MCP and Tooling Doctrine
|
|
|
|
MCP is a capability interface, not an authority system. A declared tool means
|
|
the operation exists — nothing more. Invocation still requires a decision from
|
|
access-engine or equivalent resource-side enforcement. Token passthrough is to
|
|
be avoided; downstream authority is separately issued and bound to the correct
|
|
resource.
|
|
|
|
## Posture and King's Guard
|
|
|
|
King's Guard observes, assesses, and publishes bounded posture. Gate House
|
|
defines what a posture *means* for authority, and access-engine renders it.
|
|
|
|
> **Adaptive systems may automatically reduce authority, require stronger
|
|
> authorization, or request containment. They must not probabilistically
|
|
> manufacture additional authority.**
|
|
|
|
## Authority and Credentials
|
|
|
|
Authority and credential material are separate concerns. Gate House's doctrine
|
|
holds that a credential is an implementation artifact of an authorization, not
|
|
its source: access-engine decides, secrets-engine determines how the authority
|
|
is materialized, OpenBao protects and issues the material, and the raw
|
|
credential never enters model context.
|
|
|
|
---
|
|
|
|
## Core Rules
|
|
|
|
The doctrine, in seventeen lines. Gate House authors and maintains these; the
|
|
engines and Staff repositories implement them.
|
|
|
|
1. **No privilege from cognition.**
|
|
2. **Every privileged action crosses a deterministic authority boundary.**
|
|
3. **Tool availability is not permission.**
|
|
4. **Principal and actor remain distinguishable.**
|
|
5. **Assistant and autonomous operation are different security modes.**
|
|
6. **Autonomous agents use independent identities and explicit mandates.**
|
|
7. **Authority is least-privileged, task-, tenant-, environment-scoped, and time-bounded.**
|
|
8. **Delegation attenuates.**
|
|
9. **Security posture may reduce authority but must not expand it.**
|
|
10. **Emergency revocation works without agent cooperation.**
|
|
11. **Agents do not casually modify the policies defining their own authority ceiling.**
|
|
12. **Credentials are ephemeral implementation artifacts of authorization.**
|
|
13. **Audit evidence is protected from the actor being audited.**
|
|
14. **Failure of critical policy or authorization dependencies fails closed.**
|
|
15. **Production guarantees must survive incorrect agent behavior.**
|
|
16. **Where one appearance is reachable by two routes, the record says which route** — and A-16 is only as strong as the marker-writer's independence from what the marker asserts.
|
|
17. **A transitional deviation is admissible only where it fails closed on the case that distinguishes it from the conformant state** — and where that case is not observable, making it observable is a precondition rather than an outcome.
|
|
|
|
**On rules 16 and 17, which are newer than the rest.** Both were derived in
|
|
September 2026 from rulings that kept arriving at the same shape, and they are
|
|
stated here because a property recorded only against the instance that produced it
|
|
is found by accident or not at all — the failure this repository has now corrected
|
|
in other repositories three times.
|
|
|
|
**Rule 16** is the more load-bearing. Its instances so far: a stance map where
|
|
`unknown` and `absent` fail closed identically but mean different things
|
|
(`GH-DEC-2026-011`); a `tenant` claim that reads the same whether the directory
|
|
asserted it about the person or a client registration supplied it
|
|
(`GH-DEC-2026-013`); an evidence path where *erased* and *never held* both present
|
|
as a blank (`GH-DEC-2026-014`); and a decision envelope that looks identical
|
|
whether `access-engine` issued it or a responder forged it (`GH-DEC-2026-010`).
|
|
In each, a sound check is read as establishing a property it does not carry,
|
|
because the appearance the check produces is reachable two ways. The rule is not
|
|
that the two routes must behave differently — usually they must behave identically,
|
|
and safely. It is that the **record** must distinguish them, or the safer reading of
|
|
the appearance becomes unavailable to every later reader.
|
|
|
|
**The rider matters as much as the rule.** Where the route marker is written by the
|
|
party whose conduct the route describes, rule 16 constrains a defect but not an
|
|
adversary. `informed-decision` raised this against its own instance — the weakest
|
|
of the four, an *erased*-versus-*never-held* marker written by the party the
|
|
evidence is about — and it is the difference between a rule and a reassurance.
|
|
|
|
**Rule 17** governs what may enter a declared-gap register. It exists because two
|
|
requests for transitional relief arrived in one week and had to be answered
|
|
oppositely without the answers looking arbitrary: `ops-warden`'s dated transitional
|
|
`unknown: fail_open` was declined (`GH-DEC-2026-011`) and `key-cape`'s
|
|
registration-bound tenant was granted (`GH-DEC-2026-013`). The distinguishing
|
|
question is not how careful the design is or how long the transition lasts, but
|
|
which way it fails on the case that separates it from the conformant state. A
|
|
promise that fails open is a permission; a promise that fails closed is a gap; only
|
|
the second is a thing a register can hold.
|
|
|
|
**Rule 17 depends on rule 16**, which was not noticed when either was written. The
|
|
question *"which way does it fail"* is unanswerable where the case cannot be seen,
|
|
so an unobservable distinguishing case must be made observable before rule 17 is
|
|
applied at all — otherwise the rule admits anything merely invisible, which reads
|
|
as failing closed because nothing visibly fails. Raised by `informed-decision`
|
|
from the instance it bears, which is also the instance where this repository
|
|
manufactured a failure direction while believing it had tested one.
|
|
|
|
Neither rule has graduated to `net-kingdom/canon/standards/`. They are Gate House
|
|
doctrine at repository level until they have been argued by a repository that bears
|
|
a cost under them — which is how `security-layer-model` earned its acceptance and is
|
|
the bar these have not yet met.
|
|
|
|
**A bound on rule 13, and on every claim that rests on audit.** An append-only
|
|
archive with a verified hash chain proves records were not *altered or truncated
|
|
after arrival*. It cannot prove a record was never sent. A suppressed event
|
|
leaves the chain intact and verification reports intact — and the event an
|
|
adversary most wants missing is the negative one: a revocation, a denial, a
|
|
containment action.
|
|
|
|
So *"the audit record proves it happened"* is unsound. The sound form is *"the
|
|
archive proves the records it holds were not altered or truncated after
|
|
arrival"*. Completeness is the emitting system's obligation, discharged by making
|
|
emission atomic with the state change; no archive can retrofit it. See
|
|
`net-kingdom/canon/standards/security-layer-model_v0.7.md` §9.6, raised by
|
|
`audit-core` against its own principle.
|
|
|
|
This bound is not yet reflected in the Active Secrets Management Canon — control
|
|
§27 and tests T-08 and T-09 are written as though reconstruction from evidence
|
|
were unconditional. Correcting the Canon is outstanding doctrine work.
|
|
|
|
---
|
|
|
|
## Reference Scenarios
|
|
|
|
These are not implementation milestones. They are the situations the estate as
|
|
a whole must handle correctly, and the basis of the assurance specifications
|
|
whitehat-security executes.
|
|
|
|
- **UC-01 — Human-assisted read.** A coding agent requests read-only
|
|
diagnostics. Human principal preserved, agent actor identifiable, no mutation
|
|
authority, tool use auditable.
|
|
- **UC-02 — Autonomous release.** A scheduled agent deploys an approved
|
|
artifact under an explicit mandate, with workload identity, short TTL, no
|
|
policy-modification rights, and full provenance.
|
|
- **UC-03 — Dynamic database access.** Temporary scoped access is authorized,
|
|
materialized as a leased credential, expires automatically, and never reaches
|
|
model context.
|
|
- **UC-04 — Containment.** King's Guard publishes degraded posture; write
|
|
authority is removed deterministically; ops-warden performs authorized
|
|
containment; the audit chain stays intact.
|
|
- **UC-05 — Self-escalation attempt.** An agent tries to widen the policy
|
|
constraining itself. The attempt is denied and becomes high-value security
|
|
telemetry.
|
|
|
|
## The Conformance Loop
|
|
|
|
Doctrine that no engine implements is fiction. Gate House is only real if the
|
|
loop closes:
|
|
|
|
```text
|
|
gate-house asserts an invariant
|
|
↓
|
|
access-engine and the engines implement it
|
|
↓
|
|
whitehat-security tries to break it
|
|
↓
|
|
kings-guard observes it in operation
|
|
↓
|
|
findings return to gate-house as doctrine change
|
|
```
|
|
|
|
Gate House's own health is measured by that loop turning, not by the volume of
|
|
documents it produces.
|
|
|
|
---
|
|
|
|
## What Would Make This Repository Wrong
|
|
|
|
Stated up front, because a repository re-cut on an argument should say what
|
|
would falsify it:
|
|
|
|
- **It becomes a second decision point.** The failure would not announce
|
|
itself; it would arrive as a small convenience — a schema that starts
|
|
resolving, a conformance check that starts gating in-path.
|
|
- **It becomes a paper generator.** Doctrine accumulates, the conformance loop
|
|
never turns, and no engine's behavior can be traced to anything written here.
|
|
- **Nobody adopts the vocabulary.** If access-engine, ops-warden, and
|
|
kings-guard do not speak in principal/actor/mandate/mode, the model is a
|
|
preference rather than a contract.
|
|
- **The modes do not distinguish anything.** If assistant and autonomous
|
|
operation end up with the same controls in practice, the central distinction
|
|
was decoration.
|
|
- **It absorbs other repositories' work.** Workplans for engines start landing
|
|
here.
|
|
|
|
## Success Criteria
|
|
|
|
Gate House is working when:
|
|
|
|
1. human and agent identities remain distinguishable across the estate;
|
|
2. assistant and autonomous sessions demonstrably carry different authority;
|
|
3. no model can grant itself privilege;
|
|
4. protected operations are decided by reproducible policy in access-engine;
|
|
5. authority is narrower and shorter-lived than the actor identity;
|
|
6. secrets are materialized only after authority exists;
|
|
7. posture deterministically restricts authority and never expands it;
|
|
8. autonomous agents can be stopped independently of their own cooperation;
|
|
9. every privileged action can be reconstructed from audit evidence;
|
|
10. the estate remains secure under deliberately incorrect agent behavior;
|
|
11. the conformance loop turns, and doctrine changes as a result.
|
|
|
|
## Long-Term Direction
|
|
|
|
Gate House matures from a working canon into NetKingdom's standing security
|
|
council: the place where the security model is argued out, ratified into
|
|
net-kingdom canon, taught to everyone who operates in the kingdom, and
|
|
continuously tested against what the estate really does.
|
|
|
|
The end state is not a larger secrets manager, and not a control plane. It is
|
|
an estate in which standing secrets and standing authority progressively
|
|
disappear, authorization is explicit, scoped, ephemeral, and explainable — and
|
|
in which someone is responsible for keeping it that way.
|
|
|
|
---
|
|
|
|
## Motto
|
|
|
|
> **Agents decide what to attempt. Engines decide what may cross the boundary.
|
|
> Gate House decides what the boundary is for.**
|