The vocabulary mapping this path was waiting on is not coming: gate-house rejected it in GH-DEC-2026-008, because a translation can be confidently wrong and fails open by accepting a claim approved for a different action. The stronger option arrived instead, and both halves are enforced here. flex-auth published binding.approval_binding_digest (FLEX-DEC-2026-007) to fix the circularity this repo reported: a pdp_digest recorded at issue time can never equal the request_digest of the request that carries the claim in its hashed context, so with GH-DEC-2026-008 requiring that equality, destroy would have failed closed forever on a check no correct record could pass. - authorization.approval_binding_digest implements the published exclusion rule, including Go's context,omitempty behaviour when stripping empties the context; digest_material drops an empty context for the same reason. - validate_decision_envelope recomputes the field rather than trusting it, refuses a claim-bearing request whose decision records none, and compares the claim's digest from step 1 against it -- never against request_digest, which still covers the claim so it stays a sound replay identity. - validate_approval_claim requires binding.pdp_path true before using pdp_digest at all. Path intent is never inferred from a digest that happens to be present; pre-schema-v3 approvals carry pdp_path false regardless of any digest they hold. Replay fixtures re-vendored from dd3ce4c. The destroy pins moved a second and final time; approval_binding_digest did not, which is the point. The fixture now demonstrates the property instead of asserting it: we rederive fa07becf... from its own request through our canonical implementation, proving we hash the same material flex-auth does rather than pinning a constant we cannot reproduce. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E4tNMAYcSQmZWUE4wqP4ij Assistant: claude-code Assistant-Model: opus Assistant-Process: 715726@bnt-lap001 Assistant-Session: 80a42b32-cba6-4b23-8be0-68819b1a6092 |
||
|---|---|---|
| .claude/rules | ||
| .decisions | ||
| .forgejo/workflows | ||
| catalog | ||
| docs | ||
| history | ||
| intakes | ||
| policies | ||
| registry | ||
| scripts | ||
| src/secrets_engine | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| evidence-classification.yaml | ||
| INTENT.md | ||
| layer.yaml | ||
| LICENSE | ||
| pep-stance.yaml | ||
| ProductRequirementsDocument.md | ||
| pyproject.toml | ||
| README.md | ||
| SCOPE.md | ||
| uv.lock | ||
| WORK-RECORDS.md | ||
secrets-engine
Headless, multi-application, multi-tenant secrets workflow and automation layer for approved secret custody, delivery, and lifecycle work across build, test, and production stages.
Layer: Engine / Lifecycle under the accepted NetKingdom Security Layer
Model (layer.yaml). OpenBao remains the custody and enforcement backend.
secrets-engine is the deterministic API over it: catalog, decision
consumption, plan/apply, guarded provisioning, verification, delivery,
evidence, lifecycle metadata, and native-access deactivation. It does not
render authorization decisions. Local evidence can be inspected through an
allowlisted per-lane audit summary without exposing record detail.
Start Here
- INTENT.md - why this repository exists, including the Engine / Lifecycle declaration.
- layer.yaml - machine-readable layer declaration and proposed surfaces.
- ProductRequirementsDocument.md - product requirements and MVP scope.
- NetKingdom security infrastructure boundary pointer
- points to the canonical document in
net-kingdom/docs/, covering responsibilities and interactions with OpenBao, flex-auth, user-engine, ops-warden, ops-bridge, info-tech-canon, State Hub, and agents.
- points to the canonical document in
- Bootstrap MVP workplan - first implementation plan after State Hub bootstrap.
Core Direction
The MVP proves the whynot-design-npm-publish lane end to end:
- describe the lane in a non-secret catalog (
catalog/); - verify an approved decision (State Hub or local fixture);
- apply OpenBao policy/auth metadata through a stage-aware role;
- provision and verify the value without printing it;
- run a workload command through safe exec-time delivery.
Target command shape:
secrets-engine exec --catalog whynot-design-npm-publish -- npm publish
Quickstart
uv venv && uv pip install -e ".[dev]"
source .venv/bin/activate
secrets-engine catalog list
# Run the whole pilot chain live against a throwaway OpenBao dev server:
SECRETS_ENGINE_HUB_URL="" bash scripts/demo-e2e.sh
- CLI reference: docs/cli.md
- Publication-scope policy (maturity → token scope): docs/publication-scope-policy.md
- Stage roles & bootstrap tokens: docs/openbao-stage-roles.md
- warden-sign auth-capability lane: docs/warden-sign-auth-capability.md
- whynot-design real publish closeout: docs/whynot-design-real-publish-closeout.md
- ops-warden routing contract: docs/ops-warden-routing-contract.md
- Hardening backlog (exit bootstrap mode): docs/hardening-backlog.md
- Existing-lane catalog admission: docs/catalog-admission.md
- Native lane cutover (WP-0006 T05/T06): docs/native-lane-cutover.md
- KeyCape service-auth consumer boundary: docs/service-auth.md
- Approval consume-before-OpenBao (GH-DEC-2026-003): docs/approval-consumption.md
- OpenBao JWT login contract (engine consumer): docs/openbao-jwt-login.md
- Secret-use evidence surface: docs/secret-use-evidence-contract.md
The implementation is a Python package (src/secrets_engine/). OpenBao is
reached only through the bao CLI adapter (openbao.py); the rest of the code
speaks in lanes and guarded plans.
Security Rules
- Do not put raw secret values in Git, State Hub, chat, prompts, issue comments, workplans, or normal logs.
- OpenBao is the backend custody and audit authority.
- Build, test, and production have separate policy boundaries.
- Production live actions fail closed until the durable State Hub action-authorization endpoint is available; local approval mirrors are throwaway-demo material only.
- A privileged production OpenBao call also requires a successful approval-engine CAS consume first. Conflict or unavailability means do not write.
- Temporary bootstrap OpenBao credentials must live outside repos, use mode 0600, be revocable, and be removed after narrower auth is working.