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

decisions/decisions.md

@@ -1304,3 +1304,133 @@ the one real code change here.
 - Does not block the access path. The `TokenRequest` shape stands on its own;
   this makes its result visible in the artifact rather than only in the pin's
   logs.
+
+---
+
+## FLEX-DEC-2026-010 — The response channel is unauthenticated: stated as a stance, and the envelope will be signed
+
+**Date:** 2026-09-06
+**Status:** accepted, stance recorded, fix open
+**Workplan:** `FLEX-WP-0024`
+**Raised by:** `secrets-engine`, who asked rather than mitigating it locally
+
+## Context
+
+`secrets-engine` probed the address this repo handed them under
+`FLEX-WP-0021-T05` and found that on the workstation a bare
+`*.svc.cluster.local` name resolves through `search ad.binect.de` to one
+unrelated public host. Reproduced here:
+
+```text
+$ getent hosts flex-auth-secrets-engine.flex-auth.svc.cluster.local
+80.158.43.29   ...svc.cluster.local.ad.binect.de
+$ getent hosts this-service-does-not-exist.flex-auth.svc.cluster.local
+80.158.43.29   (identical — suffix expansion, not a record)
+$ getent hosts flex-auth-secrets-engine.flex-auth.svc.cluster.local.
+(no resolution)
+```
+
+They then asked the question the misdirection makes urgent: **how is the
+response channel authenticated?** And they declined to answer it locally, on the
+grounds that choosing a transport control for flex-auth's service is not a
+consumer's call and inventing one is how a consumer ends up authoring semantics
+it does not own. That is the right boundary — the same one that kept them from
+authoring a tenant mapping — and it is why this record exists instead of a
+mitigation in their repo.
+
+## The stance, stated because an unstated stance is an assumption
+
+**The response channel is unauthenticated.** The pin serves plain HTTP on
+`:8080`; `flex-auth.decision-record.v1` carries no signature field. A responder
+that knows the package id and version — both published in this repo — can return
+a well-formed `effect: allow` with a matching binding, and every check a
+consumer performs will pass it.
+
+`callerAuth` authenticates the caller to the PDP. Nothing authenticates the PDP
+to the caller. Those are not two views of one control.
+
+## Why the digests do not help, which is the part that would be misread
+
+A consumer that recomputes `request_digest`, `policy_package_digest`, and
+`registry_snapshot_digest`, finds all three correct, and concludes the responder
+is genuine has verified **nothing about who answered**.
+
+Every input to those digests is either sent by the caller or published. The
+request material is what the caller just transmitted. Both the package and
+registry digests are computable from files in a public repo. A forger reproduces
+all three exactly, and the more digests flex-auth publishes the more
+authenticated a forged envelope looks.
+
+**The digests establish integrity of the binding, never authenticity of the
+source.** This is the third instance of one seam in as many decisions:
+`FLEX-DEC-2026-008` had a tenant carried into the digest and never compared —
+visible, not enforced; `FLEX-DEC-2026-009` has a caller authenticated and never
+recorded — enforced, not visible; here the record is verifiable and unauthentic —
+checkable, but not evidence of anything. Each time, an artifact invited a
+conclusion one step stronger than it supports.
+
+## The consequence for a fail-closed consumer
+
+`secrets-engine` runs fail-closed in production, and stated that its posture
+"silently assumes the PDP is the PDP". Precisely:
+
+**Fail-closed protects against a PDP that is absent, not against one that
+lies.** An unreachable PDP denies. A lying PDP allows. The posture that makes
+the first safe does nothing about the second, and a consumer reading its own
+fail-closed configuration as covering both has drawn exactly the wrong
+inference.
+
+Today that risk is carried entirely by their pin being unset — which is to say,
+by nothing structural.
+
+## Decision
+
+**Three parts, in increasing durability.**
+
+**1. Never publish a bare Service name again.** Publish the trailing-dot FQDN
+and say in-cluster only. The trailing dot makes resolution *fail* rather than
+succeed at the wrong place, which is the behaviour a fail-closed consumer needs
+from a name. Corrected in `examples/secrets-engine/README.md`, `SCOPE.md`, and
+the `FLEX-WP-0021-T05` handover note.
+
+**2. For the operator shape, `kubectl port-forward` is the recommended path, and
+not only for reachability.** 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 it is currently the **only** path on which a consumer knows it
+is talking to the real pin.
+
+Note this is the exact reverse of the caller direction, where the port-forward
+bypasses the `NetworkPolicy` entirely (`FLEX-WP-0023`). The two properties are
+independent and point opposite ways. They must be stated separately; summarising
+either as "the network protects it" gets one of them backwards.
+
+**3. Sign the decision envelope.** §17 makes the decision-record schema
+flex-auth's, so responder authenticity is ours to provide rather than a
+deployment concern to delegate. A detached signature over the canonical envelope
+is preferred to transport-only mTLS, for two reasons:
+
+- It survives the transport. A decision recorded now must still be
+  attributable when it is audited later, and mTLS authenticates a connection
+  that no longer exists.
+- It composes with `FLEX-DEC-2026-009`. A record that names its authenticated
+  caller *and* carries flex-auth's signature is an audit artifact. Either alone
+  is a claim.
+
+mTLS remains worth having for the live channel and is not excluded; it is not a
+substitute.
+
+## Consequences
+
+- **flex-auth published a hazardous address.** The handover was ours, the probe
+  was theirs, and the finding is against this repo. Recorded that way.
+- Until signing lands, a consumer must not treat digest recomputation as
+  responder verification. `docs/decision-record-contract.md` says so
+  explicitly — the contract is the only place a consumer is guaranteed to read.
+- `FLEX-WP-0024` carries signing. Key custody is not flex-auth's to invent:
+  route it through `warden route` and OpenBao rather than minting a key in this
+  repo, per the estate credential-routing rule.
+- Worth carrying into the v0.8 assent round. §6.4 obligates the PEP to act on a
+  decision and §9.3 splits degraded mode by owner, but nothing in the standard
+  requires a PDP's response to be authenticable, so a conformant PEP can be
+  fully conformant while trusting a forged allow. That is a gap in the standard
+  and not only in this implementation.