Seeded INTENT.md and README.md
This commit is contained in:
parent
65268fd221
commit
683f6d2769
2 changed files with 1245 additions and 2 deletions
623
INTENT.md
Normal file
623
INTENT.md
Normal file
|
|
@ -0,0 +1,623 @@
|
|||
# Gate House — INTENT
|
||||
|
||||
**Repository:** `gate-house`
|
||||
**Project family:** NetKingdom
|
||||
**Status:** Initial intent
|
||||
**Date:** 2026-08-24
|
||||
|
||||
## The Mission
|
||||
|
||||
> **Gate House establishes and enforces deterministic authority boundaries for human, workload, and agent actions across NetKingdom.**
|
||||
|
||||
Gate House is the reference implementation of the **Active Secrets Management Plane** defined by the Active Secrets Management Canon.
|
||||
|
||||
Its purpose is deliberately narrow:
|
||||
|
||||
> **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.**
|
||||
|
||||
---
|
||||
|
||||
## Why Gate House Exists
|
||||
|
||||
Agentic development and operations increase the rate, scope, concurrency, and duration of system change.
|
||||
|
||||
Two operating modes are particularly important:
|
||||
|
||||
### Agent Assistant Coding
|
||||
|
||||
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 human normally remains the principal and primary accountable operator.
|
||||
|
||||
### Autonomous Agent Coding
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Neither mode can safely depend on the behavior of an LLM as the final security boundary.
|
||||
|
||||
Gate House exists to provide the deterministic substrate underneath this increasingly dynamic environment.
|
||||
|
||||
---
|
||||
|
||||
## Foundational Principle
|
||||
|
||||
> **Cognition proposes. Authority disposes. Infrastructure executes.**
|
||||
|
||||
Gate House belongs to the **Authority Plane**.
|
||||
|
||||
It sits between probabilistic/adaptive systems and protected execution systems.
|
||||
|
||||
```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 │
|
||||
└───────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
---
|
||||
|
||||
## Gate House Does
|
||||
|
||||
Gate House should:
|
||||
|
||||
- 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.
|
||||
- **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.**
|
||||
|
||||
---
|
||||
|
||||
## Agentic Operating Modes
|
||||
|
||||
### Agent Assistant Profile
|
||||
|
||||
```text
|
||||
human principal
|
||||
↓
|
||||
interactive assistant session
|
||||
↓
|
||||
agent actor
|
||||
↓
|
||||
Gate House
|
||||
↓
|
||||
restricted authority
|
||||
↓
|
||||
execution
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
Human disconnect must not silently transform the session into autonomous privileged operation.
|
||||
|
||||
### Autonomous Agent Profile
|
||||
|
||||
```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.
|
||||
|
||||
---
|
||||
|
||||
## Change Dynamics
|
||||
|
||||
Gate House should explicitly support a **Change Dynamics Envelope**.
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## MCP and Tooling Doctrine
|
||||
|
||||
MCP is a capability interface, not an authority system.
|
||||
|
||||
A tool declaration such as:
|
||||
|
||||
```text
|
||||
restart_service()
|
||||
rotate_database_password()
|
||||
delete_namespace()
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## Technical Direction
|
||||
|
||||
Gate House should be designed as a small, composable control plane rather than a monolith.
|
||||
|
||||
Likely implementation areas include:
|
||||
|
||||
- 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.
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
---
|
||||
|
||||
## Long-Term Direction
|
||||
|
||||
Gate House should mature from a reference Active Secrets Management Plane into NetKingdom's reusable **deterministic authority substrate**.
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## Motto
|
||||
|
||||
> **Agents decide what to attempt. Gate House decides what may cross the boundary.**
|
||||
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