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
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
