knowledge(security): a guarded Text credential seam is legitimate when SecretText cannot flow end to end

[Nabil BA-MOH (NavNab)]

What

One community knowledge file (security) with good/bad samples: a Text credential seam guarded by [NonDebuggable], encryption at rest and a statement-scoped, justified analyzer suppression is not a defect when the value cannot stay SecretText up to the sink — and the half conversion a naive "use SecretText" finding produces is the real defect.

Admission test

A capable LLM reviewing a Text seam (an injectable transport interface whose test double asserts where the credential travels, or a legacy Text-only consumer) reliably demands SecretText. Acting on that produces one of two broken outcomes, both observed in a real cloud app: a SecretText parameter immediately Unwrap()-ed to call the seam (on-premises only, so not viable for the cloud target), or a seam retyped to SecretText whose test double can no longer pin the credential's placement. This file is negative knowledge in the sense of skills/write.md: it tells the reviewer what not to flag, why, and gives the detection signal for the half conversion instead.

It complements — does not restate — nondebuggable-required-when-unwrapping-secrettext.md (which covers the unavoidable on-premises Unwrap) and secrettext-with-httpclient.md (the preferred path when the sink is secret-aware); both are cross-referenced.

Checks

• validate_frontmatter.py: 0 errors, 0 warnings. Test-KnowledgeIndex.ps1: PASSED (deterministic, full coverage).
• 28 lines, one concern, samples referenced by filename, ids 50540–50541 (unused in the corpus).
• Test-ReviewFixtures.ps1 could not be run locally (a .NET assembly-load crash that reproduces on the untouched upstream tree — environment, not content); relying on CI for it.

[Nabil BA-MOH (NavNab)]

@microsoft-github-policy-service agree company="Asio Services"

[Jesper Schulz-Wedde (JesperSchulz)]

The negative guidance is too broad for the sample it uses.

The “good” seam is a custom interface owned by the app, so it can carry SecretText end to end; AL interfaces support SecretText parameters, and a test double can still assert which parameter/path received a value and whether it is empty via SecretText.IsEmpty() without exposing the credential. Testability alone should not justify converting a secret to Text.

Please narrow this exception to a genuinely unmodifiable Text-only sink (for example, a legacy dependency the app cannot retype) and make the good sample demonstrate that boundary. Keep the guidance that a secret-aware API or owned interface must remain SecretText; otherwise agents may suppress a valid LC0043/security finding whenever a test double exists.

[Jesper Schulz-Wedde (JesperSchulz)]

The prior blocker remains on the unchanged head, and deterministic routing adds a second issue:

• The “good” seam is still an app-owned interface. Runtime 12 compiles SecretText interface parameters, SecretText.IsEmpty(), and immediate Text→SecretText wrapping via SecretStrSubstNo; runtime 13+ also retrieves SecretText directly from IsolatedStorage. Please demonstrate a genuinely unmodifiable Text-only legacy sink and state that owned/secret-aware seams remain SecretText.
• For ApiKey: Text, al-security-review also worklists the higher-precedence microsoft/knowledge/security/secrettext-for-credentials.md; the new contradictory community article is then suppressed by layer precedence. Align the higher-precedence guidance so this narrow exception can route deterministically instead of being inert.

There are no author replies or commits addressing the earlier review yet.