Deterministic authority control system based on observability for vault managed secrets.

Find a file

tegwick 8604fe6021 Added active secrets management standard and architecture blueprint draft		2026-08-24 20:26:50 +02:00
spec	Added active secrets management standard and architecture blueprint draft	2026-08-24 20:26:50 +02:00
INTENT.md	Seeded INTENT.md and README.md	2026-08-24 19:58:45 +02:00
README.md	Seeded INTENT.md and README.md	2026-08-24 19:58:45 +02:00

README.md

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

                 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:

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:

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.

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.

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:

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:

actor: agent-934
posture: DEGRADED
confidence: 0.72
reason: anomalous-tool-usage

Gate House converts that posture into deterministic authority consequences:

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.

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:

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:

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.

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:

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

Small control plane, explicit boundaries.
Deterministic final authorization.
Least authority by default.
Principal and actor are not collapsed.
Delegation attenuates.
Credentials are implementation artifacts, not authority.
Short-lived authority beats standing privilege.
Tool discovery never implies authorization.
Adaptive security may restrict; it does not invent privilege.
Agents cannot casually edit their own authority ceiling.
Emergency controls do not depend on agent cooperation.
Security decisions are explainable and auditable.
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.