Seeded INTENT.md and README.md
This commit is contained in:
parent
65268fd221
commit
683f6d2769
2 changed files with 1245 additions and 2 deletions
624
README.md
624
README.md
|
|
@ -1,3 +1,623 @@
|
|||
# gate-house
|
||||
# Gate House
|
||||
|
||||
Deterministic authority control system based on observability for vault managed secrets.
|
||||
**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.**
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue