fix: the address we published was a misdirection, and the channel is unauthenticated

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

docs/decision-record-contract.md

@@ -56,3 +56,28 @@ See [`canonical-request-digest.md`](canonical-request-digest.md) and
 This is contract version 1. Additive optional fields may appear. Removing or
 redefining a required field requires a new `contract_version` value and a new
 schema id.
+
+## What this record does not prove: who answered
+
+**A consumer must not read digest recomputation as verification of the
+responder.** Recomputing `binding.request_digest`,
+`provenance.policy_package_digest`, and `provenance.registry_snapshot_digest`
+and finding all three correct says nothing about who produced the envelope.
+
+Every input to those digests is either sent by the caller or published: the
+request material is what the caller just transmitted, and both the package and
+registry digests are computable from files in this repo. A responder that knows
+the package id and version can reproduce all three exactly. The digests
+establish **integrity of the binding**, never **authenticity of the source**.
+
+`flex-auth.decision-record.v1` carries no signature today, and pins serve plain
+HTTP. So the response channel is unauthenticated, stated as a stance rather than
+left as an assumption (`FLEX-DEC-2026-010`). For a fail-closed consumer the
+distinction that matters is this: **fail-closed protects against a PDP that is
+absent, not against one that lies.** An unreachable PDP denies; a lying PDP
+allows.
+
+A detached signature over the canonical envelope is the intended fix
+(`FLEX-WP-0024`). Until it lands, responder authenticity comes from the channel
+alone — and of the available channels only `kubectl port-forward` supplies it,
+by targeting one named pod over the API server's TLS with no DNS name resolved.

docs/operator-caller-access-path.md

@@ -11,6 +11,41 @@ half transfers unexamined, and `glas-harness` ruled out the two shortcuts by
 name — **Service DNS is not connectivity, and a permanent operator token is not
 an identity**. Both refusals are correct.
 
+## The address itself is a hazard from a workstation
+
+`secrets-engine` probed the address this repo handed them, and flex-auth
+reproduced it:
+
+```text
+$ getent hosts flex-auth-secrets-engine.flex-auth.svc.cluster.local
+80.158.43.29   flex-auth-secrets-engine.flex-auth.svc.cluster.local.ad.binect.de
+
+$ getent hosts this-service-does-not-exist.flex-auth.svc.cluster.local
+80.158.43.29   this-service-does-not-exist.flex-auth.svc.cluster.local.ad.binect.de
+
+$ getent hosts flex-auth-secrets-engine.flex-auth.svc.cluster.local.
+(no resolution)
+```
+
+`resolv.conf` carries `search ad.binect.de`, which answers wildcard. A name for a
+service that does not exist resolves to the same address as one that does, which
+is the proof that this is suffix expansion and not a record. So on this
+workstation **every `*.svc.cluster.local` name resolves to one unrelated public
+host**, and the bare Service name flex-auth published was not merely unreachable
+from there — it was a live misdirection.
+
+Had a deployment pointed at it, the CheckRequest body would have gone to that
+host: subject, tenant, lane and resource ids, stage, declared field names,
+purpose, plus the caller's bearer token. No secret values, but a structural map
+of the estate's credential lanes and a credential. `secrets-engine` declined to
+mitigate it locally on the grounds that choosing a transport control for
+flex-auth's service is not a consumer's call. That is the correct boundary and
+the same one that kept them from authoring a tenant mapping.
+
+**Publish the trailing-dot FQDN, and say in-cluster only.** The trailing dot
+makes resolution fail instead of succeeding at the wrong place, which is the
+behaviour a fail-closed consumer needs from a name.
+
 ## The two gates are not one gate
 
 `FLEX-WP-0021-T04` noted that `callerAuth` "becomes the real boundary" for an
@@ -118,6 +153,45 @@ it should be. The commands above are exact and the expectations are derived from
 `internal/callerauth/auth.go`, not guessed; running them is an operator action.
 Nothing below the design line is claimed as verified.
 
+## Which end of the channel is authenticated
+
+`callerAuth` authenticates the **caller to the PDP**. Nothing authenticates the
+**PDP to the caller**, and `secrets-engine` was right to ask rather than assume.
+
+Stated plainly, because a stance is only a stance if it is recorded: the pin
+serves plain HTTP on `:8080` and `flex-auth.decision-record.v1` carries no
+signature. **A responder that knows the package id and version — both published
+in this repo — can return a well-formed `effect: allow` that passes every check
+a consumer performs.**
+
+The trap worth naming is that the digests look like they help and do not. A
+consumer that recomputes `request_digest`, `policy_package_digest`, and
+`registry_snapshot_digest` and finds them all correct has verified nothing about
+who answered, because **every input to those digests is either sent by the
+caller or published**: the request material is what the caller just transmitted,
+and both package and registry digests are computable from files in a repo. A
+forger reproduces all three exactly. The digests establish integrity of the
+binding, never authenticity of the source, and reading a matching digest as
+evidence of a genuine PDP is the same visible-but-not-verifying seam as
+`FLEX-DEC-2026-008`.
+
+Consequence for a fail-closed consumer, which is the part that matters:
+**fail-closed protects against a PDP that is absent, not against one that
+lies.** A forged allow defeats the posture entirely rather than degrading it.
+
+`FLEX-DEC-2026-010` records the stance and `FLEX-WP-0024` carries the fix. One
+nuance belongs here, though, because it changes the operator recommendation:
+
+**A `kubectl port-forward` path does authenticate the responder, transitively.**
+It resolves no DNS name, targets one named pod explicitly, and runs over the
+API server's TLS with the operator's cluster credentials. So for the operator
+shape the port-forward is not merely a workaround for reachability — it is
+currently the *only* path where the consumer knows it is talking to the real
+pin. That is the reverse of the caller direction, where the port-forward
+bypasses the `NetworkPolicy` entirely. The two properties are independent and
+point opposite ways, which is why they have to be stated separately rather than
+summarised as "the network protects it".
+
 ## What the record will not show
 
 Even with all four negatives passing, **the decision record does not say who