Local baseline engine
Learns local norms from environment signals.
Flags drift for operator triage and policy review.
RoleLocal baseline authority
TechnologyZero-Trust control architecture
ZTA Control Architecturefor governed edge operations
A Zero-Trust stack that keeps baselines local, actions policy-scoped, and every change signed, reviewable, and rollback-ready.
Local baselines
Policy gates
Signed change
Audit-ready
Architecture layers
Four control layers, one governed stack
Each layer keeps detection, response, change, and records separate, reviewable, and operator-controlled.
Policy-gated response plane
On-device policy defines least-privilege action scope.
Restriction and containment stay approval-bound.
RoleControlled response execution
Signed change pipeline
Signed policy and software releases.
Staged rollout windows with rollback-ready recovery.
RoleControlled change path
Decision record store
Local records link signals, approvals, and actions.
Traceability stays available for SOC and assurance review.
RoleAudit-ready traceability
Differentiators
What keeps the stack defensible
The architecture is differentiated by explicit control scope, readable records, and recovery-first change discipline.
Explicit control boundaries
- Policy scope is explicit before enforcement.
- Approvals define least-privilege action range.
- Escalation paths stay operator-owned.
AssuranceNamed approvals before enforcement.
Case-ready decision records
- Signals, approvals, and actions stay linked.
- Records support SOC triage and incident review.
- Outputs stay readable under pressure.
AssuranceReadable records for SOC review.
Recovery-first change control
- Signed releases and policy bundles.
- Staged rollout windows by cohort.
- Rollback-ready recovery path.
AssuranceSigned change with safe recovery.
Operating principles
Control rules and privacy defaults
The control plane keeps response constrained, while the privacy posture keeps data movement local by default.
Architected for controlled operations
- Detection stays local to the environment.
- Policy gates separate signals from action.
- Least-privilege action is the default.
- Records stay ready for SOC, IR, and governance review.
DefaultSignals and action stay explicitly separated.
Core mode works without payload inspection
- No raw traffic export by default.
- Behaviour signals still detect drift on opaque traffic.
- Opt-in sharing only when policy allows.
- Review and action records stay local by default.
DefaultLocal-first data handling with opt-in sharing only.
Execution path
Stage the architecture before enforcement
Pilot the stack in a controlled sequence, then expand scope only when operators and controls are aligned.
Stage before enforcement
- Start alert-only and stabilise baselines.
- Run guided actions under operator review.
- Move to enforcement only when approved.
Core mode avoids payload inspection requirements.
ProgressionAlert first, then enforce by approval.
Review the architecture in a pilot briefing
Use a pilot to align scope, workflow, and expansion criteria before deployment decisions are made.
- Deployment scope and asset profile
- Operator workflow and approval design
- Success metrics and expansion criteria