coulomb/gate-house
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Rewrite INTENT.md: Gate House as the doctrine council

Browse source 
Re-cuts Gate House from deterministic authority plane to the Staff-layer
council where NetKingdom's security and defence doctrine is established,
documented, taught, and supervised.

The decisive argument is now stated in the document itself: a decision point
inside Gate House would place the deterministic authority boundary inside the
non-deterministic management layer, violating INV-02 — the first invariant the
repository exists to defend. access-engine (currently flex-auth) stays the only
policy decision point.

Adds the layer model and the Staff invariant (Staff never touches tooling
directly), a corrected responsibility table that names access-engine,
zone-engine, and the canon repos, the access lane/rule demarcation with
ops-warden and ops-mason, the conformance loop, and falsifiers.

Drops the /authorize surface, policy evaluation order, policy engine
selection, grant storage, revocation, and the technical direction section.
Keeps what no other repo owns: operating modes, the principal/actor/runtime
triple, mandates and ceilings, change dynamics, MCP doctrine, the posture
asymmetry, and the assurance specifications.

Addresses the name/metaphor risk in the opening: the gate house is where the
watch is set and the porter's rules are posted, not the gate itself.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
This commit is contained in:
tegwick 2026-08-28 20:16:31 +02:00
parent 4d913c52fd
commit 7f13f7290d
1 changed files with 322 additions and 541 deletions
Download patch file Download diff file Expand all files Collapse all files

863
INTENT.md
View file

@ -1,49 +1,169 @@
# Gate House — INTENT
**Repository:** `gate-house`
**Project family:** NetKingdom
**Status:** Initial intent
**Date:** 2026-08-24
**Repository:** `gate-house`
**Project family:** NetKingdom
**Layer:** Staff
**Status:** Re-cut as the security and defence doctrine council
**Version:** 0.2
**Date:** 2026-08-28
**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 establishes and enforces deterministic authority boundaries for human, workload, and agent actions across NetKingdom.**
> **Gate House is the council where NetKingdom's security and defence doctrine is established, documented, taught, and supervised.**
Gate House is the reference implementation of the **Active Secrets Management Plane** defined by the Active Secrets Management Canon.
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.
Its purpose is deliberately narrow:
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.
> **Nothing crosses a protected boundary without deterministically established authority.**
Humans and agents may decide what they want to attempt. Adaptive security systems may assess risk and recommend restrictions. Operations systems may know how to execute a change. Secret systems may know how to materialize credentials.
**Gate House decides whether the requested authority exists, under which conditions, for which actor, on whose behalf, against which resource, for how long, and within which hard limits.**
> **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.**
---
## Why Gate House Exists
## Where Gate House Sits
Agentic development and operations increase the rate, scope, concurrency, and duration of system change.
NetKingdom's IT security is layered by determinism and by the kind of artifact
each layer produces:
Two operating modes are particularly important:
| 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 |
### Agent Assistant Coding
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.
A human developer or operator is actively engaged with a coding or operations agent and can observe, redirect, approve, or stop actions with human-scale latency.
The layer model carries one rule, and it is the architectural form of "no
privilege from cognition":
The human normally remains the principal and primary accountable operator.
> **Staff never touches tooling directly. It acts only through engine APIs.**
### Autonomous Agent Coding
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.
Scheduled, triggered, event-driven, or machine-initiated agents act without continuous human supervision.
---
They therefore require their own identities, mandates, access profiles, budgets, lifecycle controls, audit trails, and governance boundaries.
## Why Gate House Is Not the Decision Point
Both modes introduce more dynamic system change than human-only operation. Assistant-mode dynamics are partly bounded by human risk appetite and reaction speed. Autonomous-mode dynamics are bounded primarily by policy, organizational governance, runtime constraints, and resource budgets.
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:
Neither mode can safely depend on the behavior of an LLM as the final security boundary.
> **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.**
Gate House exists to provide the deterministic substrate underneath this increasingly dynamic environment.
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.
---
@ -51,573 +171,234 @@ Gate House exists to provide the deterministic substrate underneath this increas
> **Cognition proposes. Authority disposes. Infrastructure executes.**
Gate House belongs to the **Authority Plane**.
Read across the layers, that sentence is NetKingdom's layering rule, not only
its security maxim: Staff proposes, Engines dispose, Tooling executes.
It sits between probabilistic/adaptive systems and protected execution systems.
## The Core Security Question
The doctrine Gate House maintains exists so that, for any privileged action,
the estate can answer:
```text
COGNITIVE PLANE
┌───────────────────────────────┐
│ humans │
│ LLMs │
│ coding agents │
│ operations agents │
│ MCP / A2A tool discovery │
│ King's Guard risk signals │
└──────────────┬────────────────┘
│ requests action
▼
════════════════════════════════════════════════
GATE HOUSE
DETERMINISTIC AUTHORITY PLANE
┌───────────────────────────────┐
│ identity context │
│ principal / actor │
│ tenant / environment │
│ mandate / delegation │
│ resource / action │
│ policy │
│ approval │
│ posture constraints │
│ TTL / quotas / budgets │
│ authority ceiling │
└──────────────┬────────────────┘
│ grant / deny
▼
════════════════════════════════════════════════
EXECUTION PLANE
┌───────────────────────────────┐
│ Git / CI/CD │
│ Kubernetes │
│ cloud APIs │
│ databases │
│ SaaS APIs │
│ production services │
└───────────────────────────────┘
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
```
---
## Core Security Invariant
> **No protected action succeeds merely because an intelligent system believes it should.**
For every privileged action, Gate House should be able to evaluate a request equivalent to:
```text
WHO
principal
actor
runtime identity
WHERE
tenant
environment
resource
WHAT
requested operation
WHY
task
mandate
delegation
UNDER WHICH CONDITIONS
policy
approval
security posture
quotas
budgets
UNTIL WHEN
TTL / expiry
→ deterministic GRANT or DENY
```
For the same authoritative input state, the decision must be reproducible and auditable.
Deterministic does **not** mean static. Context may change continuously. Risk posture, approvals, resource ownership, incident state, tenancy, time, and quotas may all influence authorization. The rule is that the final privilege boundary is enforced by explicit policy rather than probabilistic model judgment.
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.
---
## Gate House Does
## Domain Vocabulary
Gate House should:
Gate House owns these terms. Other repositories should use them rather than
synonyms:
- receive authenticated identity and context from trusted upstream systems;
- distinguish **principal**, **actor**, and **runtime identity**;
- evaluate deterministic authorization policy;
- enforce authority ceilings;
- model delegation and attenuation;
- issue or represent narrowly scoped, time-bounded authority;
- bind authority to tenant, environment, resource, action, task, and conditions;
- require step-up or parameter-bound approval for sensitive operations;
- expose machine-verifiable grant/deny decisions;
- coordinate credential materialization through the Secrets Engine and secret backends;
- accept bounded security-posture inputs from King's Guard;
- support deterministic circuit breakers and emergency revocation;
- produce authoritative audit evidence;
- preserve policy and decision versioning;
- fail closed for security-critical ambiguity or unavailable authority state;
- provide reusable policy and execution interfaces for NetKingdom tools.
---
## Gate House Does Not
Gate House should deliberately **not** become a security super-system.
It does not own:
- primary human identity lifecycle;
- tenant lifecycle;
- identity-provider federation;
- password or secret storage;
- PKI implementation;
- secret scanning;
- anomaly detection;
- threat intelligence;
- behavioral risk inference;
- vulnerability scanning;
- penetration testing;
- infrastructure reconciliation;
- deployment execution;
- incident investigation;
- autonomous remediation;
- security learning or adaptive threat modeling.
Those responsibilities belong elsewhere in NetKingdom.
---
## Responsibility Boundaries
| Component | Primary responsibility | Relationship to Gate House |
|---|---|---|
| **User Engine** | users, subjects, memberships, identity lifecycle | supplies subject context |
| **Tenant Engine** | tenant and organizational boundaries | supplies tenancy context |
| **Key Cape** | authentication, federation, identity assertions | establishes authenticated identity |
| **Gate House** | deterministic authority and delegation | decides what may happen |
| **Secrets Engine** | credential abstraction, dynamic issuance, rotation/revocation orchestration | materializes granted authority as credentials |
| **OpenBao** | secure secret storage, leases, PKI, dynamic secret engines | protects and issues credential material |
| **Ops Warden** | bounded operational execution | executes authorized operations |
| **Ops Mason** | construction, reconciliation, reconstitution | builds or restores authorized state |
| **King's Guard** | adaptive observation, risk assessment, containment coordination, security memory | supplies posture and defensive constraints |
| **Whitehat Security** | adversarial testing and attack simulation | challenges Gate House assumptions and controls |
A useful shorthand is:
```text
User Engine identifies
Tenant Engine contextualizes
Key Cape authenticates
Gate House authorizes
Secrets Engine provisions
OpenBao protects
Ops Warden operates
Ops Mason constructs / restores
King's Guard observes / defends / adapts
Whitehat Security attacks / validates
```
---
## Relationship to King's Guard
King's Guard is intentionally more ambitious than Gate House.
King's Guard is an adaptive security control system:
```text
declare healthy intent
→ establish and attest identity
→ observe actual behavior
→ compare behavior with policy and intended scope
→ assess risk and confidence
→ respond within bounded authority
→ restore known-good operation
→ validate the outcome
→ retain governed security memory
```
Gate House is the deterministic boundary through which King's Guard's defensive intent must pass.
A critical asymmetry applies:
> **Adaptive systems may automatically reduce authority, require stronger authorization, or request containment. They must not probabilistically manufacture additional authority.**
For example:
```text
King's Guard posture = DEGRADED
│
▼
Gate House policy:
deny production.write
allow production.read
require step-up for staging.write
```
King's Guard detects and reasons about risk.
Gate House defines what that risk posture means for authority.
---
## Relationship to Secrets Engine and OpenBao
Gate House should separate **authority** from **credential material**.
Example:
```text
Agent:
"I need SELECT on orders-prod for task T"
│
▼
Gate House
│
deterministic decision
│
GRANT:
action = SELECT
resource = orders-prod
ttl = 15m
│
▼
Secrets Engine
│
determine credential mechanism
│
▼
OpenBao
│
create / lease DB credential
│
▼
execution gateway
```
**Gate House decides the authority.**
**Secrets Engine determines how that authority is materialized.**
**OpenBao securely protects and issues the credential material.**
The credential is an implementation artifact of authority, not the source of authority.
---
## Domain Concepts
Gate House should keep a small, explicit domain model.
- **Principal** — the human, organization, workload, or system on whose behalf authority originates.
- **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 without collapsing principal and actor identity.
- **Authority Ceiling** — the maximum authority an actor can obtain under deterministic policy.
- **Grant** — a positive authorization decision scoped by action, resource, context, and time.
- **Denial** — a negative authorization decision with machine-readable reason and evidence.
- **Approval** — an independent authorization artifact required for actions exceeding normal policy.
- **Posture** — a bounded security-state input, normally supplied by King's Guard or another trusted source.
- **Credential Binding** — the mapping from an authority grant to the technical credential required by the target system.
- **Decision Evidence** — the record explaining which policy, identities, inputs, and conditions produced the decision.
---
## Preferred Authority Pattern
A privileged action should be reconstructable approximately as:
```text
principal: alice@example
actor: deploy-agent-22
runtime: spiffe://netkingdom/prod/deployer/22
tenant: tenant/acme
task: deploy release 7.2.1
action: production.deploy
resource: cluster/payments
mandate: release-automation
approval: approval-9432
policy_version: authz-2026-08-24
authority_ttl: 20m
credential_type: aws-sts
decision: GRANT
```
Not every field must live inside a single token. The system must preserve enough linked evidence to reconstruct the authority chain.
---
## Core Rules
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-scoped, tenant-scoped, environment-scoped, and time-bounded wherever possible.**
8. **Delegation attenuates.**
9. **Security posture may reduce authority but must not probabilistically 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 preferably 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 security guarantees must survive incorrect agent behavior.**
- **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
### Agent Assistant Profile
The distinction Gate House exists to keep sharp.
```text
human principal
↓
interactive assistant session
↓
agent actor
↓
Gate House
↓
restricted authority
↓
execution
```
### Assistant
The human's credentials should not simply be dumped into the agent environment. Selective delegation, short-lived sessions, explicit tooling boundaries, and production-side controls remain required.
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.
Human disconnect must not silently transform the session into autonomous privileged operation.
**A human disconnecting must never silently promote the session into autonomous
privileged operation.**
### Autonomous Agent Profile
### Autonomous
```text
governance mandate
↓
agent identity
↓
task context
↓
Gate House
↓
time-bounded authority
↓
execution
↓
independent audit
```
Autonomous agents require unique identity, named owner, explicit mandate, authority ceiling, environment and resource bounds, time limits, concurrency limits, token/compute/tool budgets, independent kill switch, lifecycle termination, and audit reconstruction.
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
Gate House should explicitly support a **Change Dynamics Envelope**.
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.
The envelope defines the maximum rate, scope, duration, and concurrency of system change the organization is prepared to tolerate while preserving required invariants.
Possible constraints include:
- maximum concurrent mutating agents;
- maximum resources per grant;
- maximum destructive actions;
- maximum deployment frequency;
- maximum task duration;
- credential TTL;
- maximum agent-chain depth;
- maximum tool calls;
- token and compute budgets;
- environment restrictions;
- read/write separation;
- reversible versus irreversible action classes.
Economic budgets are useful blast-radius controls but never authorization substitutes.
---
## Circuit Breakers
Gate House should make autonomous degradation simple and deterministic.
```text
NORMAL
↓
risk / anomaly / velocity threshold crossed
↓
AUTONOMOUS WRITE DISABLED
↓
READ / DIAGNOSE REMAINS AVAILABLE
↓
STEP-UP OR HUMAN INTERVENTION REQUIRED
```
Safe degraded mode should normally remove mutation authority before observability.
---
Economic budgets are useful blast-radius controls. **They are never
authorization.**
## MCP and Tooling Doctrine
MCP is a capability interface, not an authority system.
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.
A tool declaration such as:
## 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 fifteen 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.**
---
## 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
restart_service()
rotate_database_password()
delete_namespace()
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
```
means only that the operation exists.
Invocation still requires Gate House policy evaluation or equivalent resource-side enforcement.
Token passthrough should be avoided. Downstream authority should be separately issued or exchanged and bound to the correct resource.
Gate House's own health is measured by that loop turning, not by the volume of
documents it produces.
---
## Technical Direction
## What Would Make This Repository Wrong
Gate House should be designed as a small, composable control plane rather than a monolith.
Stated up front, because a repository re-cut on an argument should say what
would falsify it:
Likely implementation areas include:
- **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.
- canonical authorization request schema;
- policy-decision API;
- principal/actor/delegation model;
- policy-engine abstraction;
- grant representation;
- approval binding;
- posture input model;
- authority ceilings;
- quota and time constraints;
- credential-binding interface to Secrets Engine;
- execution-gateway integration;
- audit/event schema;
- decision replay and explainability;
- emergency revocation;
- agentic security test harness.
## Success Criteria
Potential policy backends may include OPA/Rego, Cedar, native policy evaluators, or multiple pluggable engines. Gate House should not make the conceptual model depend on one policy implementation.
Gate House is working when:
---
## First Reference Use Cases
### UC-01 — Human-Assisted Read
A human operates a coding agent that requests read-only Kubernetes diagnostics.
Expected outcome:
- human principal preserved;
- agent actor identifiable;
- time-bounded grant;
- no production mutation capability;
- decision and tool use auditable.
### UC-02 — Autonomous CI Deployment
A scheduled release agent deploys an approved artifact.
Expected outcome:
- independent workload identity;
- explicit release mandate;
- workload-federated authentication;
- environment-bound deploy authority;
- short TTL;
- no IAM/policy modification rights;
- full provenance from source to deployment.
### UC-03 — Dynamic Database Access
An agent requests temporary database read access.
Expected outcome:
- Gate House grants scoped authority;
- Secrets Engine maps authority to dynamic DB credentials;
- OpenBao issues leased credential;
- credential expires/revokes automatically;
- raw credential is not placed in model context.
### UC-04 — King's Guard Containment
King's Guard detects degraded posture for an autonomous actor.
Expected outcome:
- King's Guard publishes bounded posture;
- Gate House deterministically removes write authority;
- Ops Warden performs authorized containment;
- King's Guard validates outcome;
- audit chain remains intact.
### UC-05 — Policy Self-Escalation Attempt
An autonomous agent attempts to modify the policy constraining its own access.
Expected outcome:
- request denied or requires a separately governed authority path;
- event becomes high-value audit/security telemetry.
---
## Initial Success Criteria
Gate House is useful when it can demonstrate that:
1. human and agent identities remain distinguishable;
2. Assistant and Autonomous sessions use different authority profiles;
3. a model cannot grant itself additional privilege;
4. protected operations are decided by reproducible policy;
5. authority can be narrower and shorter-lived than the actor identity;
6. secrets can be materialized only after authority exists;
7. security posture can deterministically restrict authority;
8. autonomous agents can be stopped independently;
9. policy self-modification is constrained;
10. every privileged action can be reconstructed from audit evidence;
11. the system remains secure under deliberately incorrect agent behavior.
---
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 should mature from a reference Active Secrets Management Plane into NetKingdom's reusable **deterministic authority substrate**.
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 mature system should make it natural to express:
> Who or what is acting?
> On whose behalf?
> In which tenant and environment?
> Under what mandate?
> Against which resource?
> For which action?
> Under which constraints?
> Until when?
> According to which policy?
> With which evidence?
and return a machine-enforceable answer.
The end state is not a larger secrets manager.
It is a system in which **standing secrets and standing authority progressively disappear**, while authorization becomes explicit, scoped, ephemeral, explainable, and governable.
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. Gate House decides what may cross the boundary.**
> **Agents decide what to attempt. Engines decide what may cross the boundary.
> Gate House decides what the boundary is for.**