Headless multi-application, multi-tenant security zone mangement engine.
Reviewed as the only policy decision point. Four task amendments: T01 - the 'only PDP' invariant guards latency, not authority. Compiled data that determines an outcome still decides. Tightened wording: zone-engine owns membership, flex-auth policy owns stance. T03 - split membership from stance rather than rejecting option (c) wholesale. Stance for the pre-sign gate belongs in the policy package because registry content is absent from decision provenance. Also: fail-open is a PEP property and no PDP can express it. T05 - no registry schema change needed; metadata/attributes already flatten into rego input. But trust_zone is a live name collision - a hardcoded 'platform' constant no policy reads. T04 - flex-auth loads registry and policy once at process start with no reload path, so an inert compiled exception expires only by human redeploy. Enforced expiry requires a not_after evaluated in rego. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| GOAL.md | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
zone-engine
Headless authority for security zones — named bands of the estate with different enforcement rigidity, and the lifecycle of time-boxed exceptions to them.
A zone answers a question no existing axis answers: is this control enforced
here, and what happens when it fails? NetKingdom can already say how exposed a
workload is (environment posture), how ready it is (workload maturity M0–M3),
and what state the organization is in (organization_posture). All three
describe. None decides.
zone-engine is not a policy decision point. flex-auth remains the only
PDP; zone membership reaches it by compilation into the registry it already
consumes, never by a synchronous lookup in the decision path.
Orient: GOAL.md → SCOPE.md → workplans/.