Deployment Models
Where Layer-7 Runs
Deployment models describe how Layer-7 components are positioned in an environment. The objective is always the same: execution cannot occur without governance. Models differ by scale, reliability, and hardening requirements.
Required Components
Every deployment includes the same primitives. Even in “local dev,” you should keep the separation between decision governance and execution enforcement.
Governance Engine
Evaluates policy gates, computes risk, routes authority, emits enforcement results.
Policy Store
Versioned policy bundles (hash-addressed preferred) loaded by the engine.
Decision Ledger
Append-only event stream for audit reconstruction and governance reporting.
Execution Gateway
Enforces allow/deny/queue outcomes. Blocks direct execution when governance is missing.
Reference Deployment Models
Model A — Local Dev
Single developer machine. Engine + gateway run as separate processes. Ledger is local DB. Policy bundles on disk.
Model B — Single Node
One server/VM. Engine, gateway, ledger run on the same host but isolated by ports and service identities.
Model C — Enterprise Cluster
Multiple services across nodes. Dedicated ledger tier, policy store, engine replicas, and gateway layer in front of tools.
Model D — Edge / Appliance
A hardened appliance runs engine + ledger locally near execution targets (air-gapped or semi-connected). Policy updates are signed and synchronized on schedule.
- Target: regulated or disconnected environments
- Constraint: updates must be verifiable and controlled
When to choose which
- Local Dev: building & testing quickly
- Single Node: investor demo, small pilot
- Enterprise Cluster: production governance at scale
- Edge Appliance: offline/regulated/field operations
Hardening Requirements (By Model)
Hardening increases as you move from dev to production. The table shows minimum controls that should be present.
| Control | Local Dev | Single Node | Enterprise Cluster | Edge / Appliance |
|---|---|---|---|---|
| mTLS between services | Optional | Recommended | Required | Required |
| Policy bundle signing | Recommended | Required | Required | Required |
| Append-only ledger + hash chain | Required | Required | Required | Required |
| Network segmentation | N/A | Recommended | Required | Required |
| HA / replication | N/A | Optional | Required | Optional (depends) |
| Periodic integrity anchoring | Optional | Recommended | Required | Required |
| Break-glass controls | Optional | Required | Required | Required |
| Fail-closed gateway | Required | Required | Required | Required |
Reference Network Shape
At scale, the gateway sits between tools and execution targets. The engine is not publicly exposed. The ledger is protected.
Boundary rules
- Engine: internal-only; receives requests from trusted systems
- Gateway: front-door for actions; blocks direct access to tools
- Ledger: protected tier; append-only; restricted reads
- Policy store: signed bundles; strict versioning
Degraded mode
- Ledger unavailable: queue/deny governed actions
- Policy unavailable: deny (no “unknown policy” fallback)
- Identity degraded: reject approvals; re-auth required
- Gateway bypass detected: incident trigger + halt
Operational Notes
Deployment is governance. Operational practices must preserve ledger integrity, policy versioning, and identity validity.
Operational requirements
- Policy change control: signed bundles + review workflow
- Key rotation: scheduled rotation for signing and mTLS certs
- Backups: ledger archive backups + integrity validation
- Monitoring: anomaly detection on approvals and overrides
What breaks the model
- Allowing tools to be called directly outside the gateway
- Storing unsigned or mutable policies in production
- Fail-open behavior when ledger is degraded
- Unlogged overrides or break-glass actions