623 lines
15 KiB
Markdown
623 lines
15 KiB
Markdown
# Gate House
|
|
|
|
**Deterministic authority control system for human and agentic coding and operations.**
|
|
|
|
Gate House is a NetKingdom security control-plane project and the reference implementation of the **Active Secrets Management (ASM) Plane**.
|
|
|
|
Think of Gate House as observability for vault managed secrets based on sound governance policy best practices.
|
|
|
|
Its job is deliberately narrow:
|
|
|
|
> **Gate House decides whether a human, workload, or agent is allowed to perform a requested action against a protected resource — under explicit, deterministic, auditable rules.**
|
|
|
|
It does **not** replace an identity provider, secrets vault, policy engine, operations framework, or adaptive security system. It connects those responsibilities through a common authority model.
|
|
|
|
---
|
|
|
|
## Why?
|
|
|
|
Agentic development changes the operational risk profile of software engineering.
|
|
|
|
Human-only development is naturally rate-limited by human execution.
|
|
|
|
Interactive coding agents increase change velocity while a developer or operator remains actively involved.
|
|
|
|
Autonomous agents remove much of that human friction entirely and therefore require explicit identities, mandates, authority ceilings, budgets, circuit breakers, and governance.
|
|
|
|
At the same time, modern tooling such as MCP makes infrastructure capabilities increasingly easy for agents to discover and invoke.
|
|
|
|
The central Gate House rule is therefore:
|
|
|
|
> **Tool availability is not permission.**
|
|
|
|
And more generally:
|
|
|
|
> **Cognition may be probabilistic. Authority must be deterministically constrained.**
|
|
|
|
---
|
|
|
|
## Core Architecture
|
|
|
|
```text
|
|
Cognitive Plane
|
|
┌──────────────────────────────────────────┐
|
|
│ humans │
|
|
│ LLMs / coding agents │
|
|
│ operations agents │
|
|
│ MCP / A2A │
|
|
│ King's Guard │
|
|
└───────────────────┬──────────────────────┘
|
|
│ request
|
|
▼
|
|
══════════════════════════════════════════════
|
|
GATE HOUSE
|
|
┌──────────────────────────────────────────┐
|
|
│ principal │
|
|
│ actor │
|
|
│ tenant / environment │
|
|
│ mandate / delegation │
|
|
│ resource / action │
|
|
│ policy │
|
|
│ approval │
|
|
│ posture │
|
|
│ TTL / quotas / budgets │
|
|
│ authority ceiling │
|
|
└───────────────────┬──────────────────────┘
|
|
│ GRANT / DENY
|
|
▼
|
|
══════════════════════════════════════════════
|
|
Execution Plane
|
|
┌──────────────────────────────────────────┐
|
|
│ Git / CI/CD │
|
|
│ Kubernetes │
|
|
│ cloud APIs │
|
|
│ databases │
|
|
│ SaaS / production services │
|
|
└──────────────────────────────────────────┘
|
|
```
|
|
|
|
A short version:
|
|
|
|
> **Cognition proposes. Authority disposes. Infrastructure executes.**
|
|
|
|
---
|
|
|
|
## What Gate House Owns
|
|
|
|
Gate House owns the deterministic authority decision.
|
|
|
|
It should answer questions such as:
|
|
|
|
```text
|
|
WHO
|
|
principal
|
|
actor
|
|
runtime identity
|
|
|
|
WHERE
|
|
tenant
|
|
environment
|
|
resource
|
|
|
|
WHAT
|
|
requested operation
|
|
|
|
WHY
|
|
task
|
|
mandate
|
|
delegation
|
|
|
|
UNDER WHICH CONDITIONS
|
|
policy
|
|
approval
|
|
posture
|
|
quotas
|
|
budgets
|
|
|
|
UNTIL WHEN
|
|
TTL
|
|
|
|
→ GRANT or DENY
|
|
```
|
|
|
|
Gate House should provide:
|
|
|
|
- deterministic authorization;
|
|
- principal/actor separation;
|
|
- delegation and attenuation;
|
|
- authority ceilings;
|
|
- tenant and environment constraints;
|
|
- task- and resource-scoped grants;
|
|
- short-lived authority;
|
|
- approval binding;
|
|
- posture-dependent restrictions;
|
|
- quotas and change-rate controls;
|
|
- independent circuit breakers;
|
|
- credential-binding integration;
|
|
- explainable decisions;
|
|
- protected audit evidence.
|
|
|
|
---
|
|
|
|
## What Gate House Does Not Own
|
|
|
|
Gate House is intentionally **not** a security monolith.
|
|
|
|
| System | Responsibility |
|
|
|---|---|
|
|
| **User Engine** | users, identities, memberships |
|
|
| **Tenant Engine** | tenant and organizational boundaries |
|
|
| **Key Cape** | authentication and federation |
|
|
| **Gate House** | deterministic authorization |
|
|
| **Secrets Engine** | credential abstraction and lifecycle orchestration |
|
|
| **OpenBao** | secret storage, PKI, leases, dynamic secret engines |
|
|
| **Ops Warden** | operational execution |
|
|
| **Ops Mason** | construction, reconciliation, recovery |
|
|
| **King's Guard** | adaptive security observation and response |
|
|
| **Whitehat Security** | adversarial testing and validation |
|
|
|
|
A useful shorthand:
|
|
|
|
```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
|
|
```
|
|
|
|
---
|
|
|
|
## Agentic Operating Modes
|
|
|
|
Gate House treats two agentic modes as distinct security regimes.
|
|
|
|
### Agent Assistant Coding
|
|
|
|
A human developer or operator remains actively engaged with the agent.
|
|
|
|
```text
|
|
human principal
|
|
↓
|
|
assistant agent
|
|
↓
|
|
Gate House
|
|
↓
|
|
bounded delegated authority
|
|
↓
|
|
execution
|
|
```
|
|
|
|
The human remains the primary operational principal, but Gate House should preserve the agent as an actor where practical.
|
|
|
|
A human session ending must not silently convert the workflow into privileged autonomy.
|
|
|
|
### Autonomous Agent Coding
|
|
|
|
A scheduled or triggered agent operates without continuous human supervision.
|
|
|
|
```text
|
|
governance mandate
|
|
↓
|
|
agent/workload identity
|
|
↓
|
|
Gate House
|
|
↓
|
|
task-scoped authority
|
|
↓
|
|
execution
|
|
```
|
|
|
|
Autonomous agents require:
|
|
|
|
- unique identity;
|
|
- named owner;
|
|
- explicit mandate;
|
|
- explicit authority ceiling;
|
|
- runtime limit;
|
|
- credential TTL;
|
|
- concurrency limit;
|
|
- token/compute/tool-call budgets;
|
|
- independent kill switch;
|
|
- audit trail;
|
|
- lifecycle termination.
|
|
|
|
---
|
|
|
|
## Deterministic Security Substrate
|
|
|
|
Gate House follows one non-negotiable design rule:
|
|
|
|
> **No protected action succeeds merely because an intelligent system believes it should.**
|
|
|
|
An LLM may decide:
|
|
|
|
> "I should restart the production service."
|
|
|
|
It may not decide:
|
|
|
|
> "Therefore I am authorized to restart the production service."
|
|
|
|
Authorization belongs to deterministic policy enforcement.
|
|
|
|
That policy may be dynamic:
|
|
|
|
```text
|
|
ALLOW production.restart
|
|
IF
|
|
actor.role == "operations-agent"
|
|
AND environment == "production"
|
|
AND service.team == actor.team
|
|
AND incident.status == "active"
|
|
AND approval.valid == true
|
|
AND approval.action == request.action
|
|
AND approval.target == request.target
|
|
AND now < approval.expiry
|
|
```
|
|
|
|
For the same authoritative input state, the result must be reproducible and auditable.
|
|
|
|
---
|
|
|
|
## King's Guard Integration
|
|
|
|
King's Guard is the adaptive security system around Gate House.
|
|
|
|
King's Guard may detect:
|
|
|
|
- anomalous tool usage;
|
|
- unexpected behavioral drift;
|
|
- compromised workloads;
|
|
- unusual change velocity;
|
|
- cross-tenant disturbance;
|
|
- declining confidence in an actor.
|
|
|
|
It may then publish a bounded posture signal.
|
|
|
|
Example:
|
|
|
|
```text
|
|
actor: agent-934
|
|
posture: DEGRADED
|
|
confidence: 0.72
|
|
reason: anomalous-tool-usage
|
|
```
|
|
|
|
Gate House converts that posture into deterministic authority consequences:
|
|
|
|
```text
|
|
IF posture == DEGRADED
|
|
THEN
|
|
deny production.write
|
|
allow production.read
|
|
require step_up for staging.write
|
|
```
|
|
|
|
Adaptive systems may automatically **reduce** authority.
|
|
|
|
They must not probabilistically manufacture additional authority.
|
|
|
|
---
|
|
|
|
## Secrets Engine and OpenBao Integration
|
|
|
|
Gate House separates authorization from credential materialization.
|
|
|
|
```text
|
|
agent requests DB read
|
|
│
|
|
▼
|
|
Gate House
|
|
│
|
|
GRANT SELECT
|
|
orders-prod
|
|
TTL 15m
|
|
│
|
|
▼
|
|
Secrets Engine
|
|
│
|
|
choose credential mechanism
|
|
│
|
|
▼
|
|
OpenBao
|
|
│
|
|
issue leased credential
|
|
│
|
|
▼
|
|
execution gateway
|
|
```
|
|
|
|
The credential is an implementation artifact of the grant.
|
|
|
|
This keeps organizational authorization outside the vault itself while still using OpenBao as the protected credential engine.
|
|
|
|
---
|
|
|
|
## Domain Model
|
|
|
|
Initial concepts:
|
|
|
|
- **Principal** — who authority originates from;
|
|
- **Actor** — who attempts the action;
|
|
- **Runtime Identity** — concrete executing workload;
|
|
- **Mandate** — standing organizational authorization;
|
|
- **Delegation** — scoped transfer of authority;
|
|
- **Authority Ceiling** — maximum authority an actor can obtain;
|
|
- **Grant** — positive scoped authorization;
|
|
- **Denial** — negative authorization decision;
|
|
- **Approval** — independent authorization artifact;
|
|
- **Posture** — trusted security-state input;
|
|
- **Credential Binding** — mapping from grant to technical credential;
|
|
- **Decision Evidence** — audit record of why a decision occurred.
|
|
|
|
---
|
|
|
|
## Example Authority Request
|
|
|
|
Conceptually:
|
|
|
|
```yaml
|
|
principal:
|
|
id: user:alice@example
|
|
actor:
|
|
id: agent:deploy-agent-22
|
|
runtime:
|
|
id: spiffe://netkingdom/prod/deployer/22
|
|
|
|
tenant: tenant:acme
|
|
environment: production
|
|
|
|
task:
|
|
id: release-7.2.1
|
|
|
|
request:
|
|
action: production.deploy
|
|
resource: cluster/payments
|
|
|
|
mandate:
|
|
id: release-automation
|
|
|
|
approval:
|
|
id: approval-9432
|
|
|
|
constraints:
|
|
ttl: 20m
|
|
max_mutations: 1
|
|
```
|
|
|
|
Possible decision:
|
|
|
|
```yaml
|
|
decision: GRANT
|
|
policy_version: authz-2026-08-24
|
|
|
|
authority:
|
|
action: production.deploy
|
|
resource: cluster/payments
|
|
expires_in: 20m
|
|
mutation_limit: 1
|
|
|
|
credential_binding:
|
|
type: aws-sts
|
|
provider: secrets-engine
|
|
```
|
|
|
|
The exact wire format is not fixed yet.
|
|
|
|
---
|
|
|
|
## Change Dynamics
|
|
|
|
Agentic systems change infrastructure faster than humans can.
|
|
|
|
Gate House should therefore support a **Change Dynamics Envelope**.
|
|
|
|
Potential dimensions:
|
|
|
|
- concurrent mutating agents;
|
|
- maximum actions per grant;
|
|
- maximum resources per task;
|
|
- task duration;
|
|
- credential TTL;
|
|
- agent-chain depth;
|
|
- deployment frequency;
|
|
- destructive-action quota;
|
|
- token and compute spend;
|
|
- external-service spend;
|
|
- read/write separation.
|
|
|
|
Budgets are useful blast-radius controls.
|
|
|
|
They are not authorization.
|
|
|
|
---
|
|
|
|
## Circuit Breakers
|
|
|
|
Autonomous write authority should be independently suspendable.
|
|
|
|
```text
|
|
NORMAL
|
|
↓
|
|
threshold / invariant violation
|
|
↓
|
|
AUTONOMOUS WRITE DISABLED
|
|
↓
|
|
READ / DIAGNOSE AVAILABLE
|
|
↓
|
|
STEP-UP / HUMAN INTERVENTION
|
|
```
|
|
|
|
When degraded, preserve observability before mutation authority.
|
|
|
|
---
|
|
|
|
## Initial Reference Scenarios
|
|
|
|
### 1. Human-Assisted Kubernetes Diagnostics
|
|
|
|
A developer uses a coding agent to inspect production logs.
|
|
|
|
- human principal retained;
|
|
- agent actor visible;
|
|
- read-only authority;
|
|
- short TTL;
|
|
- no mutation rights;
|
|
- auditable tool use.
|
|
|
|
### 2. Autonomous Release Agent
|
|
|
|
A scheduled agent deploys an approved release.
|
|
|
|
- independent workload identity;
|
|
- release mandate;
|
|
- workload federation;
|
|
- production deployment only;
|
|
- no IAM modification;
|
|
- bounded runtime;
|
|
- complete audit chain.
|
|
|
|
### 3. Dynamic Database Access
|
|
|
|
An agent requests temporary `SELECT` access.
|
|
|
|
- Gate House authorizes;
|
|
- Secrets Engine materializes;
|
|
- OpenBao generates leased credentials;
|
|
- credentials are kept outside LLM context;
|
|
- lease expires automatically.
|
|
|
|
### 4. King's Guard Containment
|
|
|
|
King's Guard marks an actor as degraded.
|
|
|
|
- Gate House removes write authority;
|
|
- Ops Warden performs authorized containment;
|
|
- King's Guard verifies the result.
|
|
|
|
### 5. Policy Self-Escalation
|
|
|
|
An agent attempts to broaden its own permission boundary.
|
|
|
|
- Gate House denies;
|
|
- event is audited;
|
|
- security telemetry may be forwarded to King's Guard.
|
|
|
|
---
|
|
|
|
## Initial Implementation Areas
|
|
|
|
The first prototype will likely need:
|
|
|
|
```text
|
|
gate-house/
|
|
├── api/
|
|
│ ├── authorization-request
|
|
│ ├── decision
|
|
│ └── grant
|
|
├── domain/
|
|
│ ├── principal
|
|
│ ├── actor
|
|
│ ├── mandate
|
|
│ ├── delegation
|
|
│ ├── authority
|
|
│ └── posture
|
|
├── policy/
|
|
│ ├── engine
|
|
│ ├── policies
|
|
│ └── test
|
|
├── grants/
|
|
│ ├── issuance
|
|
│ ├── ttl
|
|
│ └── revocation
|
|
├── approvals/
|
|
├── limits/
|
|
│ ├── quota
|
|
│ ├── budget
|
|
│ └── concurrency
|
|
├── integrations/
|
|
│ ├── user-engine
|
|
│ ├── tenant-engine
|
|
│ ├── key-cape
|
|
│ ├── secrets-engine
|
|
│ ├── openbao
|
|
│ ├── kings-guard
|
|
│ └── ops-warden
|
|
├── audit/
|
|
├── test/
|
|
│ ├── deterministic
|
|
│ ├── adversarial
|
|
│ └── integration
|
|
└── docs/
|
|
```
|
|
|
|
This is a direction, not yet a mandatory repository structure.
|
|
|
|
---
|
|
|
|
## Design Principles
|
|
|
|
1. **Small control plane, explicit boundaries.**
|
|
2. **Deterministic final authorization.**
|
|
3. **Least authority by default.**
|
|
4. **Principal and actor are not collapsed.**
|
|
5. **Delegation attenuates.**
|
|
6. **Credentials are implementation artifacts, not authority.**
|
|
7. **Short-lived authority beats standing privilege.**
|
|
8. **Tool discovery never implies authorization.**
|
|
9. **Adaptive security may restrict; it does not invent privilege.**
|
|
10. **Agents cannot casually edit their own authority ceiling.**
|
|
11. **Emergency controls do not depend on agent cooperation.**
|
|
12. **Security decisions are explainable and auditable.**
|
|
13. **Production guarantees must survive incorrect agent behavior.**
|
|
|
|
---
|
|
|
|
## Non-Goals for the First Prototype
|
|
|
|
The first implementation does not need to:
|
|
|
|
- implement a new identity provider;
|
|
- replace OpenBao;
|
|
- implement a complete secrets manager;
|
|
- implement King's Guard;
|
|
- implement a general SIEM;
|
|
- perform anomaly detection;
|
|
- solve every cloud authorization model;
|
|
- become an IAM suite;
|
|
- invent a new policy language;
|
|
- support every agent protocol;
|
|
- provide autonomous remediation.
|
|
|
|
It should prove that a clean deterministic authority plane can coordinate these systems.
|
|
|
|
---
|
|
|
|
## Success
|
|
|
|
Gate House succeeds when a developer can look at any privileged action and answer:
|
|
|
|
> **Who acted? On whose behalf? Under which mandate? Against what resource? For what action? Under which policy and constraints? For how long? And why was it allowed?**
|
|
|
|
And when the system can also prove:
|
|
|
|
> **An agent could not have exceeded that authority merely by deciding to do so.**
|
|
|
|
---
|
|
|
|
## Status
|
|
|
|
Gate House is currently at the **reference architecture / research prototype** stage.
|
|
|
|
The Active Secrets Management Canon provides the initial conceptual baseline. The next step is to turn the authority model into executable contracts, policy decisions, and end-to-end reference scenarios.
|
|
|
|
---
|
|
|
|
## Motto
|
|
|
|
> **Agents decide what to attempt. Gate House decides what may cross the boundary.**
|