tenant-engine named the relation in TEN-DEC-2026-002: `tenant` is the target
tenant record and always equals `resource.id`; the write API is cross-tenant
by design and `tenant.guardrail.read` does not differ. v2 carried no tenant
rule and a constant fixture tenant, so the deliberate scope and an omitted
rule were indistinguishable.
tenant-engine.write-api.mutate v3 (FLEX-DEC-2026-016):
- allowed requires tenant_is_target; a mismatch or absent tenant is denied
tenant_not_target (object.get, so an absent key names the right cause).
- the cross-tenant scope is stated in the package and quantified by
test_tenant_never_changes_effect over every action, three subjects and
four tenants, with guards against passing by denying everything.
- fixtures rotate tenant across four tenants; five cross-tenant allows and
two tenant_not_target denies added (42 fixtures, 33 tests, all pass).
- user-engine's tenant:platform exclusion is named as a fixed-record rule,
not a subject/tenant relation, and tested separately.
Closes FLEX-WP-0022 (T01, T02 done). Also records TEN-IN-0004 and
SECRETS-IN-0002 on FLEX-WP-0020 and acknowledges the GH-DEC-2026-017
replies on FLEX-WP-0030-T04.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
GH-DEC-2026-017: the validator admitted {Staff, Engine, Tooling}, built from
section 4's catalog rows, and rejected Taxonomy, which section 3.1 defines.
railiance-master was conforming; the validator was the divergent artifact.
Now four tokens, ASCII case folded, section 4's spelling canonical, INTENT.md
governing while form disagreements are still reported, and every run states
its scope (section 11 binds section 4; volunteers are not non-conformances).
Also fixes the survey silently dropping audit-core's layer.yaml by decoding
peers into flex-auth's own struct.
GH-DEC-2026-018: flex-auth is a section 4 source of evidence. G2 closes as a
question and reopens as a dated gap (review 2026-10-19). cadence.yaml
publishes the per-event-class inventory: deny, redact, not_applicable and
audit_only rare load-bearing (heartbeat and reconciliation, rate forbidden);
allow volume load-bearing (expected-rate and reconciliation). INTENT.md
declares source_of_evidence and names it; tests assert both. Delivery is
FLEX-WP-0031.
FLEX-DEC-2026-015: resource.system follows the runtime, not the repository,
answering ops-warden's WARDEN-IN-0003.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 28468@bnt-lap001
Assistant-Session: c76569b2-6056-4dad-aea4-49cd7a018f5d
Updated by fix-consistency on 2026-09-21:
- workplan status: ready → active
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 28468@bnt-lap001
Assistant-Session: c76569b2-6056-4dad-aea4-49cd7a018f5d
B1 was found with a shell pipeline and published as a finding. The review it
appeared in had already argued that a mechanical check nobody can re-run is an
assertion, and §11's entire claim is mechanical checkability — so asserting B1
unmechanically was that defect committed by the repository reporting it.
tools/survey_layer_declarations.go reads both §11 forms per repository, reports
intra-repository disagreement, and writes a receipt. Run once, it showed the
published B1 was wrong: the estate does not spell layer: three ways across
repositories. The original pipeline took the first ^layer: match per repository
without recording which file it came from, reporting one value where there were
two.
The corrected finding is stronger. Nine of nine repositories carrying both §11
forms declare a different value in each: INTENT.md says Engine/Staff, layer.yaml
says engine/staff. The disagreement is within each repository, between the two
forms §11 permits, and it is universal rather than careless — two generators, two
conventions. Nobody is inconsistent with anybody else.
That relocates the question from casing to precedence: §11 accepts either form
and does not say which governs when both exist and disagree, so a conformance run
reading INTENT.md and one reading layer.yaml reach different answers for nine
repositories while both follow §11. flex-auth is the only declared repository
that cannot exhibit this, and only because it never wrote the second file.
The correction is recorded in the review rather than edited away: a published
review corrected silently is FLEX-DEC-2026-008's defect, and that rule has no
exception for the reviewer.
Four tests cover the disagreement case, the refusal to fold case, a missing
declaration, and the single-form shape that must not read as self-disagreement.
The survey checks only the §3 vocabulary and never applies flex-auth's house
rules to peers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 28468@bnt-lap001
Assistant-Session: c76569b2-6056-4dad-aea4-49cd7a018f5d
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 28468@bnt-lap001
Assistant-Session: c76569b2-6056-4dad-aea4-49cd7a018f5d
Eleven messages sent. Every finding is open until its owner answers; T04 stays
in progress rather than done, because a finding is not closed by silence.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 28468@bnt-lap001
Assistant-Session: c76569b2-6056-4dad-aea4-49cd7a018f5d
INTENT.md pinned standard_version: "0.7" in the frontmatter §11 requires. That
conflated two things the standard separates itself: assent "records assent to a
BOUNDARY, given at the version named. It is not assent to the current text."
flex-auth is Engine/PDP at v0.6, v0.7, v0.8 and after; the role does not change
when the text is amended. The field was also decorative — parsed into
Declaration.StandardVersion and never validated — so the version was load-bearing
only via a test asserting it equalled 0.7.
That test is inverted rather than deleted: internal/layer now rejects a version
pin in the declaration and requires conformance_record to name a file that
exists. Version-scoped state moves to docs/conformance/security-layer-conformance.md,
a derived artifact carrying what it derives from and the version derived at, as
§11 requires of derived artifacts.
SCOPE.md: gap assessment replaces "conforming with one declared gap" with three
gaps, each with an owner and a route. G2 is new — flex-auth declares no emission
guarantee where §11 requires one of every §4 source of evidence. It is recorded
as a gap rather than as conformance because the flattering reading, that
audit-core is the source and flex-auth merely produces, has been asserted by
nobody but flex-auth. Also corrects the stance register from two rows to five.
Fixing one line meant reading what the declaration asserts, and a boundary is
only half held here. docs/conformance/boundaries-review.md checks the other
halves across twelve counterparts and finds four security-relevant repositories
with no layer declaration at all — including key-cape, the identity source whose
claims flex-auth consumes as normative input. That boundary is asserted from one
side only. Recorded as unstated, never as agreed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 28468@bnt-lap001
Assistant-Session: c76569b2-6056-4dad-aea4-49cd7a018f5d
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 28468@bnt-lap001
Assistant-Session: c76569b2-6056-4dad-aea4-49cd7a018f5d
docs/stance-register-review.md is published, dated 2026-09-06, and titled "the
register has a second row". Three things moved under it: §13.1 now carries five
rows rather than two, v0.8 §6.4 obligation 3 ruled that unknown is not a zone and
must resolve to fail_closed, and two rows are now marked non-conformant.
The review's closing line warned that the cost of two incommensurable axes is
small and the cost of five is not. Five arrived in fourteen days.
The plan supersedes rather than amends: a published review silently rewritten to
match the world is FLEX-DEC-2026-008's defect, and flex-auth does not exempt its
own artifacts from a rule it holds others to.
Recorded accurately rather than flatteringly — the divergence was resolved by
gate-house doctrine in secrets-engine's direction, not by flex-auth's review, and
ops-warden's marked-non-conformant row is right to stay unconverted until
WARDEN-WP-0040 raises zone coverage. Conformance and correctness have come apart
on that cell.
INTENT.md stays at standard_version 0.7: v0.8 is still proposed, and the trigger
for the bump is stated in T04 so it is not "fixed" early.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 28468@bnt-lap001
Assistant-Session: c76569b2-6056-4dad-aea4-49cd7a018f5d
FLEX-WP-0020-T04: reuse-surface is the first owner to return a live work-record
(REUSE-WP-0023, two tasks, both deliberately in wait). Recorded in the handoff
evidence and verified rather than taken on report — the hub record is active,
access-engine raw returns 404, flex-auth returns 303, so the rename has not
landed and their refusal to pre-rewrite the federation source URL is correct.
That refusal changed the plan rather than only their side: flipping an enabled,
publish-passing source before the rename drops a live capability from the
composed federated index, so the source rewrite is ordered after T06, and
flex-auth owes them a ping when access-engine serves the capabilities index.
Nine owners remain pending; T05 stays blocked.
FLEX-WP-0022-T01: re-asked tenant-engine what CheckRequest.tenant denotes on the
write API, stating that "none" is a complete answer. Their code copies tenant_id
onto both tenant and resource.id, but that is observation, not admission, and
encoding a rule from it would make flex-auth the author of their tenancy model.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 28468@bnt-lap001
Assistant-Session: c76569b2-6056-4dad-aea4-49cd7a018f5d
FLEX-WP-0020 T01-T03: fresh preflight is zero-blocker, repository-only
scope is FLEX-DEC-2026-013, concurrent work is FLEX-DEC-2026-014.
T04 handoff requests are posted; owner work-records are still required.
T06 stays behind the exact human confirm string and a post-commit preflight.
Assistant: grok
Assistant-Session: 01a0a6cb-0334-72c0-83b0-2df57474a0f6
FLEX-WP-0022-T03: the rules already refused a foreign tenant; the fixture
suites never varied the field. No policy or version change. Asked
tenant-engine to name the CheckRequest tenant relation for T01/T02.
Assistant: grok
Assistant-Session: 01a0a6cb-0334-72c0-83b0-2df57474a0f6
CI image 8007ede@sha256:6da9543d02ff556d5d5e33624599eb26b73ef365ed0e1ee2fac2ad7703b7dcba
now serves examples/informed-decision-sitting. T03 deployment is unchanged.
Native caller checks pass with synthetic identities; human bind stays with
INFD-WP-0002.
Assistant: grok
Assistant-Session: 01a0a6cb-0334-72c0-83b0-2df57474a0f6
Seven exact-record pins from the 2026-09-15 sitting-create receipt.
c01 is omitted. Identity bar matches T03. 147 local evaluator checks
pass. Deploy waits on a CI image that contains the new package.
Assistant: grok
Assistant-Session: 01a0a6cb-0334-72c0-83b0-2df57474a0f6
Set flavor on open workplans from origin/prose/status. Copy existing
depends_on aliases only. Do not promote residuals.
Assistant: grok
Assistant-Session: 01a09dc1-b21e-77e1-919e-fcad2f82b267
Detached Ed25519 over the canonical envelope with signature omitted.
Unsigned is stated, not implied. Testdata fixtures prove verify and
tamper failure without minting a production key. FLEX-WP-0025 is
finished with the validate check from the previous commit.
Assistant: grok
Assistant-Session: 01a09dc1-b21e-77e1-919e-fcad2f82b267
FLEX-WP-0025-T03: flex-auth validate flags input.*.attributes keys that
no sibling registry or manifest supplies. A broken testdata package
proves tests can pass while the ceiling remains caller-only.
Assistant: grok
Assistant-Session: 01a09dc1-b21e-77e1-919e-fcad2f82b267
FLEX-WP-0025-T01/T02: keep merged attributes, add registry/asserted
namespaces later, and declare the remaining ceiling keys so no
published allowlist is unbacked. T03 stays waiting on validate.
Assistant: grok
Assistant-Session: 01a09dc1-b21e-77e1-919e-fcad2f82b267
FLEX-WP-0023-T04: provenance.caller is additive (mode required;
principal/audience/not_after when a token was reviewed). TokenReview
keeps the JWT exp. request_digest is unchanged because the caller is
not binding material.
Assistant: grok
Assistant-Session: 01a09dc1-b21e-77e1-919e-fcad2f82b267
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
secrets-engine's first live request rejected our allow: binding.
request_digest is computed over material they never sent, because we
enrich subject and resource from the registry before hashing. Answering
that meant reading the enrichment path, which had a worse defect in it.
Enrichment was additive-if-absent — addAttribute wrote a registry value
only where the request had no value for that key. So where a caller
supplied a key, the caller's value won and the registry's never applied.
Every registry ceiling and allowlist was advisory. Verified against the
shipped ops-warden package, each one added key on an otherwise-denied
request:
max_ttl_hours: 99 registry says 8 -> allowed a 12h certificate
allowed_principals registry allowlist -> disallowed_principal bypassed
allowed_subjects registry allowlist -> unknown_subject bypassed
The third is the one to read twice: a subject the registry does not know
authorized itself by naming itself in the allowlist it was being checked
against.
Not remotely reachable today — the PEP builds the CheckRequest,
ops-warden sends no resource.attributes, and enforce admits one identity.
It is a defence-in-depth failure: any path that lets attacker-influenced
data into a CheckRequest field became a full policy bypass rather than a
bounded input problem. Callers sending resource.attributes is not
hypothetical; secrets-engine does it on every request.
Registry facts now win, and diagnostics.registry_overrode names every
displaced key, because a registry that silently discards a contradicting
claim hides that a caller asserted authority it did not have.
subject.type is carved out, and the reason is a finding of its own.
Making the registry win there denied every secrets-engine allow: the
registry's type is CARING vocabulary (Human, Agent, Automation, Service)
and the request's is the protected system's actor vocabulary (service,
adm, agt, atm). Two fields sharing a name; substituting one for the other
is translation rather than identity, which GH-DEC-2026-008 ruled against.
Note what surfaced it — the registry's type had been dead data since the
field existed, because the caller's value always won.
Also publishes binding.submitted_request_digest, over the request exactly
as sent. request_digest was published as the consumer replay test and
cannot be one. Nothing is lost hashing the pre-enrichment form:
enrichment is a function of the request and the snapshot, and
registry_snapshot_digest already pins the snapshot.
Existing pins do not move. All three replay fixtures' request_digest and
approval_binding_digest values are byte-identical — those requests
contradict no registry fact. A field to add, not a value to correct.
Regression tests verified failing against the old behaviour before being
kept. FLEX-DEC-2026-012; FLEX-WP-0025 carries the residual, that a policy
still cannot tell a fact from an assertion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
gate-house circulated security-layer-model v0.8 for assent. Assent given
with four findings; F1 is fail-open and blocking for calling the section
6.4 PEP obligations complete, though not for anyone's adoption — the
condition already exists under v0.7 and is not created by this version.
F1. "A decision from access-engine" is not a checkable predicate. 6.4
obligation 1 requires a PEP to hold one; obligation 2 supplies a test it
is emphatic is mechanical and not a judgement call. That test establishes
which request a decision is for and nothing about who issued it, because
every input to every digest a PEP can check is either sent by the caller
or published. A responder knowing the package id and version reproduces
all three exactly.
What makes it sharp is internal: 9.4 requires the approval object to
carry authenticated entries, and 6.4 obligation 5 then requires each
artifact be validated against its owning layer, naming the approval-claim
and DecisionEnvelope pair as the live instance. So the obligation is
unsatisfiable for half the pair it was written about — a PEP can validate
the approval's authenticity and cannot validate the decision's. The
asymmetry is argued nowhere.
Section 16 already carries this observation one layer up, about the
standard's own publication path having no digest or freeze discipline.
Applied to the artifact the standard regulates, it is F1. The gap was
visible from inside and got recorded against the wrong artifact.
F2 answers the absent-vs-unknown question gate-house flagged as ours.
Runtime behaviour must be identical — absent fails closed too, and for a
stronger reason, since it is the branch reached by discovering your model
of your own scope axis was wrong. But omitting the distinction makes
totality unfalsifiable: a map with an unknown catch-all satisfies 6.4
obligation 3 vacuously, and its drift test passes by exercising the
catch-all rather than the axis. Same defect we published as
FLEX-DEC-2026-008 — coverage counted rather than executed, in a stance
map instead of a fixture suite.
F3. "The published map MUST equal the shipped behaviour, and that
equality SHOULD be asserted by a test", in a paragraph arguing drift is
worse than no publication. The strongest obligation in 6.4 has the
weakest verification, and 13.1 shows four of five rows already test it.
F4. 13.1 marks ops-warden's unknown cell non-conformant and states
ops-mason's map as simply not published, which is a plainer violation of
the same obligation, unmarked in the same table.
Also answered their direct question: no, they did not over-read our
divergence report. Added that the ruling costs us nothing, since we are
not PEP-shaped, so our concurrence is weak evidence and ops-warden's
assent is worth more here.
FLEX-WP-0023-T05 and FLEX-WP-0024-T04 close. Notes T01-T03 landed from
Glas meanwhile with real receipts including an actually-expired token,
and that enforce authenticates the caller while leaving F1 untouched —
as their own note says.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
Updated by fix-consistency on 2026-09-06:
- workplan status: ready → active
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
secrets-engine probed the Service DNS name handed over in FLEX-WP-0021-T05
and found it resolves, from the workstation, to an unrelated public host.
Reproduced here: search ad.binect.de answers wildcard, so
flex-auth-secrets-engine.flex-auth.svc.cluster.local and
this-service-does-not-exist.flex-auth.svc.cluster.local both resolve to
80.158.43.29, while the trailing-dot FQDN correctly fails. A bare Service
name in a handover is not merely unreachable from there, it is a live
misdirection, and the handover was ours.
Had a deployment pointed at it, the CheckRequest body would have gone to
that host: subject, tenant, lane and resource ids, stage, field names,
purpose, plus the caller's bearer token.
Trailing-dot FQDN and "in-cluster only" now replace the bare name in the
example README, SCOPE.md, and the T05 note.
Their real question was how the response channel is authenticated, and
they declined to answer it locally because choosing a transport control
for our service is not a consumer's call. Right boundary, so the answer
is recorded here as FLEX-DEC-2026-010: it is not authenticated. Pins
serve plain HTTP, the envelope carries no signature, and a responder that
knows the package id and version can return a well-formed allow that
passes every check a consumer performs.
The part worth stating in the contract is that the digests do not help
and look like they do. Every input to request_digest,
policy_package_digest and registry_snapshot_digest is either sent by the
caller or published in this repo, so a forger reproduces all three
exactly. They establish integrity of the binding, never authenticity of
the source — and publishing more digests makes a forged envelope look
more authenticated, not less.
For secrets-engine specifically: fail-closed protects against a PDP that
is absent, not against one that lies. An unreachable PDP denies; a lying
PDP allows.
Third instance of one seam in three decisions. 008: a tenant carried
into the digest and never compared — visible, not enforced. 009: a caller
authenticated and never recorded — enforced, not visible. 010: a record
verifiable and unauthentic — checkable, but not evidence.
One nuance that changes the operator recommendation: kubectl port-forward
does authenticate the responder, transitively — no DNS name, one named
pod, API-server TLS. That is the exact reverse of the caller direction,
where it bypasses the NetworkPolicy. Independent properties pointing
opposite ways, so neither can be summarised as "the network protects it".
FLEX-WP-0024 carries signing; key custody routes through warden/OpenBao
rather than minting a key here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
glas-harness asked for a supported owner access path with authenticated
caller binding and lifetime, ruling out Service DNS and a permanent
operator token. Both refusals are correct and the answer needs no new
mechanism: a TokenRequest token is short-lived, audience-scoped, and
bound by exact sub to the ServiceAccount the deployed pin already names.
Two findings came out of designing it.
First, for an operator caller the pin's NetworkPolicy is not a partial
control, it is silent: kubectl port-forward is proxied to the pod's own
loopback and no policy selector is consulted. So under warn the operator
path is unauthenticated and unfiltered, and the only reason it is not
reachable is that nobody has forwarded the port. warn was safe for
ops-warden because a workload pin still admitted one pod; here the warn
window protects nothing while it runs. enforce is the deliverable.
Second, the ServiceAccount named by the deployed binding does not exist.
Namespace secrets-engine holds only default, so enforce today would deny
every request rather than authenticate one.
Third, and this is the contract one: the decision record has no caller
field. provenance carries evaluator, mode, policy and registry digests
and decision time; binding carries the normalized request. So the four
negative tests can all pass and no artifact retains that they passed for
the request that mattered. Same seam as FLEX-DEC-2026-008 one layer up —
there a tenant was carried into the digest and never compared, visible
but not enforced; here a caller is authenticated and never recorded,
enforced but not visible.
provenance.caller, not binding.caller: the same request from a different
authenticated caller must decide identically, so the caller is not
replay identity and must not move request_digest. FLEX-DEC-2026-009.
Live receipts are not included. kubectl create token is credential
minting and was refused in this session, correctly; the commands are
exact and the expectations read out of internal/callerauth/auth.go, but
nothing is claimed as verified that was not run.
Also records the operator's tenant:platform decision
(5ed3fb35-eca9-413a-82b9-95171ba85bf6) and verifies that v2 already
enforces exactly it — exact string equality, no alias, no normalisation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
secrets-engine.catalog-lane.lifecycle v1 contained no reference to
input.tenant — not in well_formed, not in the denial ladder, not in a
test. A rotate on lane:glas-primary under tenant:coulomb returned allow
against the deployed package (decision:066e629bbf0c0924).
Found while answering glas-harness's tenant-alignment request, which had
asked for wrong-tenant denial evidence. There was none to return.
Three covers failed the same way: every one of the 29 fixtures carried
tenant:platform, so the suite could not report on the field; T02's own
gate named "wrong-tenant deny" and was recorded done unmet; and the
engine hashes tenant into request_digest but never compares it. Four
other published packages carry the branch — this one was the outlier.
v2 adds wrong_tenant above wrong_system, three Rego tests and three
fixtures (28/28, 32/32). The absent-tenant test caught a second defect
in the first draft: a bare input.tenant != comparison is undefined on a
missing key, so the branch dropped and the ladder reported the wrong
rung. request_tenant := object.get(input, "tenant", "") fixes it.
v2 supersedes rather than amends v1 because the defect failed open: a
consumer pinned to _VERSION=v1 would keep receiving allows with no
signal the rule beneath the version string had changed. The earlier
dual-control correction stayed at v1 because it denied everything.
Replay envelopes regenerated at v2; both request_digest values are
byte-identical, so secrets-engine's digest join needs no re-pinning.
The sweep this prompted found tenant-engine unscoped on tenant as well —
deployed, and verified allowing tenant:coulomb. Not the same fix: its
request tenant names the target rather than the caller, so a constant
would break it. Recorded and carried by FLEX-WP-0022 rather than patched
unilaterally.
FLEX-WP-0021 closes at T05; the pin still serves v1 until a redeploy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
secrets-engine confirmed T03, and re-verifying against the regenerated
destroy fixture found something neither repository can fix alone: a
pdp_digest recorded at issue time can never equal the request_digest of a
request that carries the claim in its context, because the claim is part
of the context that is hashed. Embedding the claim changes the very
digest the claim would need to name.
Not fixture staleness. It holds for every dual-control request whose
claim travels in context -- the shape GH-DEC-2026-008 had just ruled
mandatory. Left unresolved that ruling was unimplementable for exactly
the case it was written for, and destroy would have been permanently
un-allowable in production, failing closed forever on a check that could
never pass.
flex-auth owns the canonical request digest, so the fix is ours.
binding.approval_binding_digest is the same material with
context.approval removed, emitted only when a claim was carried. An
approval issued against a claim-free Check records that Check's
request_digest; the claim-bearing request reproduces it here.
DELIBERATELY ADDITIVE, and the reason matters. The tempting fix is to
drop context.approval from request_digest entirely. That is wrong:
request_digest is the replay identity, and two requests differing only in
which approval was presented must not share one, because their decisions
differ -- one allows, the other denies dual_control_required. Collapsing
them would let an allow obtained with a valid claim be replayed against a
request carrying none. So request_digest still covers the claim and still
moves; approval_binding_digest deliberately does not, and is documented
as not a replay identity. The tests assert the two functions DISAGREE on
a claim-bearing request, which is approval-engine's formulation of how to
defend a distinction that looks like duplication.
The fixture now demonstrates the property rather than asserting it: its
claim's pdp_digest equals the envelope's approval_binding_digest with
pdp_path true, and changing the claim's contents moved request_digest
while leaving approval_binding_digest untouched. Two files a consumer can
diff.
Also picked up approval-engine's new required binding.pdp_path via the
cross-repo schema test added yesterday -- which is the test doing exactly
what it was built for, one day later.
T03 is done. secrets-engine's own digest-material defect, which our two
real envelopes caught, is recorded in the workplan.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
TWO FINDINGS, BOTH FROM READING OTHER REPOSITORIES RATHER THAN OURS.
The §13.1 stance register has a second row. secrets-engine published
pep-stance.yaml -- total over catalog stage plus unknown, runtime-read
and pinned to SHIPPED_STANCE by test. SCOPE.md claimed ops-warden's was
the estate's only published map and that the register's single row was
itself the finding; that is no longer true and is corrected.
docs/stance-register-review.md is the first exercise of the
aggregate-divergence capability flex-auth claimed on 2026-08-29 and then
recorded as unexercised because one row cannot diverge from anything.
Three findings:
The two maps take opposite stances on unknown -- ops-warden fail_open by
versioned build profile under ADR-0009, secrets-engine fail_closed. Both
conformant, neither a defect, and they disagree about the one case nobody
planned for. Reported as an observation for gate-house's register, not as
a request that either repository change: a PDP does not set a consumer's
stance, and §9.3's two-owner split is our own finding.
The rows are not comparable. ops-warden scopes by security-zone,
secrets-engine by catalog-stage. §6.4 permits both, but the register
cannot then answer what the estate's stance is for a z2 workload. Worth
recording before a third row arrives.
secrets-engine's map defines fail_closed in terms of a durable
ActionAuthorization record, which GH-DEC-2026-005 shelved. The stance is
unaffected -- only the artifact name is stale -- but the file is read at
runtime and pinned by test, so the stale name outlives a comment.
SEPARATELY, T04 IS BLOCKED AND THE REASON IS STRUCTURAL. The task assumed
the ops-warden/tenant-engine/user-engine pattern, where the pin's
default-deny NetworkPolicy admits one approved consumer workload.
secrets-engine has no Kubernetes deployment at all -- it is a CLI. There
is no pod selector to write, and inventing one would repeat the error
corrected in T02. Three possible shapes recorded in the workplan and
raised with them; callerAuth, not the NetworkPolicy, becomes the real
boundary if an operator CLI is the caller, so the FLEX-WP-0016 precedent
does not transfer unexamined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
Two real DecisionEnvelopes in examples/secrets-engine/replay/ for
secrets-engine to verify its digest join unchanged: a plain allow
(rotate, empty context) and the dual-control allow (destroy with a valid
approval-claim).
Both are included deliberately. input_claim_digests.context appears only
when the request carries a non-empty context, so a consumer asserting the
field is always present would pass on destroy and fail on rotate. One
fixture would have hidden that.
request_digest, policy_package_digest, registry_snapshot_digest and the
context claim digest are verified identical across two runs and are the
fields to pin. id, decision_time and the lifetime bounds move with the
clock; the README says so rather than leaving a consumer to discover it
by flake. lifetime.ttl is 15m from the package allow_ttl.
Emitted from flex-auth/local in standalone mode, not from a cluster pin.
T03 is progress, not done -- it closes when secrets-engine confirms their
validator accepts the records unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
secrets-engine delivered the action vocabulary T01 asked for: twelve
actions read out of cli.py, not the example vocabulary. The gate earned
its keep -- four would have been inferred wrongly, and revoke, the
obvious thirteenth, does not exist as an action at all. It gates as
deactivate, which is also reached from lifecycle deactivate.
docs/secrets-engine-action-vocabulary.md records the list and the four
traps. examples/secrets-engine/ carries the package, both manifests, a
loadable registry snapshot, 26 fixtures, five check requests, and a
README. validate -kind policy is valid with 22/22 Rego tests and 26/26
fixtures.
allow_ttl is 15m, stated in the package rather than inherited from the
engine default: these decisions authorize live secret operations, so the
reliance window belongs where a reviewer sees it. Per FLEX-DEC-2026-004
it is authority to issue, not authority to keep using what the operation
produced.
destroy is the dual-control case, gated on a context.approval claim
marked approved with two distinct approvers, repeated entries counting
once. flex-auth checks what the claim says and deliberately does not
re-derive its temporal validity, signature, or supersession -- those are
approval-engine's to assert and the PEP's to verify against the live
claim, per the split accepted in FLEX-DEC-2026-006. It stays in the
package though its handler raises before the gate, so the rule is
reviewed and fixtured before SECRETS-WP-0007-T04 opens the path.
Following the FLEX-WP-0010-T02 precedent the denial ladder has no
action_not_granted branch: one subject holding all twelve actions could
never reach it, and a rule that cannot fail reads as control that is not
there. Registering a second calling identity is the revisit trigger.
Not deployed. No flex-auth-secrets-engine pin exists yet (T04), so their
policy pin stays unset and fail-closed until T05.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
Two cross-repo questions arrived in the flex-auth inbox and both are
answered as decision records rather than as prose in a message.
FLEX-DEC-2026-004 answers ops-warden WARDEN-WP-0034-T05. A decision
lifetime shorter than the SSH certificate TTL is meaningful, but only as
authority to issue, never as authority to use an already-issued
certificate. The pre-sign gate is the only consumer of the shorter
lifetime: no replay past expires_at, fresh Check per sign. The lever that
shortens effective access is the requested TTL as a policy input, which
is already deployed as the ttl_out_of_bounds deny. ops-warden's section
9.7.2 window through certificate TTL is correct as written and correctly
owned by the PEP; flex-auth does not want that residue moved to the PDP.
docs/decision-input-freshness.md gains the same boundary as published
contract text, so the ruling is not only in the decision log.
FLEX-DEC-2026-005 answers secrets-engine. A real policy package is
expected and flex-auth authors it here as it does for every consumer; the
reserved coordinate is secrets-engine.catalog-lane.lifecycle v1 and it
does not exist yet. Their choice not to default the pin was correct and
is endorsed explicitly. POST /v1/check is deployed but has no
estate-wide address by design -- per-consumer cluster-local pins with
default-deny ingress -- so their 2026-09-06 probe found the design
working, not an outage.
FLEX-WP-0021 carries that work: obtain the real action vocabulary from
secrets-engine, publish the package with fixtures, confirm the digest
join against a real decision record, then stand up a
flex-auth-secrets-engine pin in warn without moving the other two pins.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
Close the remaining PDP obligations: mechanical layer declaration check,
registry-snapshot digest in provenance, explicit allow TTL, per-input-class
freshness deadlines, and the published decision-record contract. Document
the canonical request digest as the §6.4.2 replay test.
Assistant: grok
Assistant-Session: 01a06256-fb71-7102-b3a9-27e6734257d0
C-21 flagged the ready workplan as possibly stale: reviewed against 5753b47,
HEAD had moved. Checked rather than assumed — nothing since 5753b47 touches Go
or schemas. Every commit between is documentation or work-record only, and the
last implementation change is d402408 (2026-08-23).
reviewed_against_commit now names the implementation state reviewed rather than
the HEAD at review time, so it moves when the code moves, which is when the
review needs redoing. C-21 compares against HEAD and cannot distinguish a doc
commit from a code one, so it will keep warning softly on this plan; the record
is accurate and that is the trade taken deliberately.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012sgN4GH5ZYT8pJVkCR6dcP
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014348@bnt-lap001
Assistant-Session: a993abda-65a0-4ea8-8ccd-0fcd78c92ac0
