feat(ms-ai-architect): idx-33 renvasket mot levende CAF, idx-36 var to instanser ikke en companion [skip-docs]

idx-33 RESOLVED SOM CHECKED-AND-CLEAR, ingen KB-edit. Entryen sa selv at et
premiss var umaalt: whether the CAF attribution is itself supported has not
been checked. Maalt 2026-08-13 mot levende Cloud Adoption Framework Secure AI
via microsoft-learn MCP: alle fire elementene i anker-linja staar paa sida
(Azure Resource Graph for asset inventory, managed identities + virtual
networks, APIM for MCP-endepunkter, Purview IRM for prompt-based data
exfiltration). Attribusjonen holder.

Stempel-dekningen maalt FOERST (#29), og den peker motsatt vei av idx-26i:
den fila hadde null stempler, saa klassen kunne ikke overfoeres. Her finnes
5 x (Verified MCP 2026-04) og ett av dem sitter PAA anker-linja, saa klassen
gjelder og testen blir om stempelet er fortjent. Det er det.

Kryss-fil-paastanden adjudisert under #33 - sveip lokaliserer, kilden
adjudiserer. Entryens fire filer er maalt til TRE (incident-response,
data-leakage-prevention, norge-ai-strategy); alle attribuerer til CAF og
alle er dekket. r11-pilot-results 9.5 skrev at least four og enumererte
selv tre. #33 tjente dessuten sin plass paa en fjerde fil:
ai-security-scoring-framework.md:135 parer Azure Resource Graph med Defender
for Cloud - samme produktpar som VAR defekten her - og er KORREKT der, fordi
den fila siterer defender-for-cloud/resource-graph-samples. Samme streng,
annen kilde, motsatt dom. Bokfoert checked-and-clear.

idx-36 ANVENDT, to editer i samme fil, samme commit (#32-formen).
Subtraksjonen verifisert mot kilden fila selv kaller Authoritative guide:
#2a targeted poisoning = Critical, #2b indiscriminate = Important, #10
backdoor = Critical. Raden ga Critical til begge variantene.

ENTRYENS EGET ANKER PEKTE PAA FEIL LINJE. Koea ankret paa Oker severity bar
(spm. 4, physical domain) - som ikke siterer poisoning-raden og ikke er
defekt. Evidensen sier prose at 310; lest ordrett ut av 957ebef^ er
pre-edit 310 = Backdoored models og data poisoning er Critical-severity
trusler (spm. 3, post-edit 309). anchors-feltet staar urort som historisk
record; korreksjonen ligger i resolution.

OG FRAMINGEN SNUDDE: 9.5 holdt idx-36 tilbake fordi tabellen ville bli mer
presis enn prosaen som siterer den - companion-editen som KONSEKVENS av
editen. Maalt mot kilden over-paastaar l.309 allerede i dag. Tabell-editen
skaper ikke feilen, den avdekker den. To instanser av EN defekt, ikke en
out-of-envelope companion.

Enumerasjon lukket foer anvendelse: 8 poisoning-linjer, kun 38 og 309 baerer
severity-paastand. Cond 3 (slipp dekningen vs legg til rad) ratifisert som
slipp - fila blir taus om indiscriminate, ikke usann. Prosa-editen er en
INNSETTING, saa apply-o2-ratified.mjs kunne ikke skrive den: begge editer
haandlagt med hel-linje-unikhet sjekket foerst (1 treff hver) og diff lest i
kontekst etterpaa. Fila uendret paa 368 linjer.

NY ENTRY idx-33a reist, ikke roert: l.213 under Defender-blokka dropper
identity og legger til AI models mot levende AISPM-side, og filas 8 kilder
inneholder ingen Defender AISPM-kilde - stemplet blokka siterer utenfor
filas egen kildeliste. Koea: 59 entries (4 aapne, 55 resolved).

Suite 1052/1052. check-g7-queue exit 0.

[skip-docs]: ren KB-korrektur, ingen endring i kommandoer/agenter/skills/hooks.
This commit is contained in:
Kjell Tore Guttormsen 2026-08-13 23:06:44 +02:00
commit 878292f467
2 changed files with 20 additions and 6 deletions

View file

@ -39,13 +39,14 @@
"id": "idx-33",
"file": "skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md",
"class": "replacement",
"status": "open",
"status": "resolved",
"raised": "2026-08-03",
"summary": "The idx 33 subtraction removed AI asset inventory via Azure Resource Graph and the Purview Insider Risk Management bullet from an unsupported Defender for Cloud AISPM attribution. Correct — but the same capabilities survive in this file under Cloud Adoption Framework Secure AI attribution, stamped 'Verified MCP 2026-04', and are asserted in four other corpus files. The edit's benefit is corpus-wide smaller than the single line suggested. Whether the CAF attribution is itself supported has not been checked.",
"evidence": "docs/r11-pilot-results.md §9.5 (cross-corpus check), §9.6",
"anchors": [
"Oppdatert 2026-04: inkluderer nå AI asset inventory via Azure Resource Graph"
]
],
"resolution": "Operator-ratified 2026-08-13, form: RESOLVE AS CHECKED-AND-CLEAR. No KB edit. The entry named one premise as unmeasured; measuring it cleared the anchor, and measuring the entry's OWN count found it overstated.\n\nTHE UNMEASURED PREMISE, NOW MEASURED. The entry says \"whether the CAF attribution is itself supported has not been checked\". Checked 2026-08-13 by fetching the live Cloud Adoption Framework Secure AI page (cloud-adoption-framework/scenarios/ai/secure) via microsoft-learn MCP. All four elements the anchor attributes to it are stated on that page: (1) \"Use Azure Resource Graph to discover AI resources across subscriptions\" under \"Create a complete AI asset inventory\"; (2) \"Implement managed identities ... Use virtual networks to isolate AI communications\" under \"Secure all AI communication channels\"; (3) \"Deploy Azure API Management to secure Model Context Protocol (MCP) server endpoints\", same section; (4) \"Microsoft Purview Insider Risk Management ... can also help with prompt-based data exfiltration and identification of risky AI behavior patterns\" under \"Assess AI data risks throughout your workflows\". THE CAF ATTRIBUTION IS SUPPORTED. The anchor at line 356 stands as written.\n\nSTAMP COVERAGE MEASURED FIRST, per the #29 discipline - AND IT POINTS THE OPPOSITE WAY FROM idx-26i. That entry was cleared because its file carried ZERO stamps, so a \"specificity under a verification marker\" class could not transfer for want of a marker. Here the markers exist and one sits ON the anchor line: 5 x \"*(Verified MCP 2026-04)*\" (lines 128, 133, 210, 356, 366) plus \"**Confidence Level:** Verified\" (line 364); zero \"**Confidence:**\". The class therefore DOES apply, which makes the test whether the stamp is earned rather than whether it reaches. Measured against the live CAF page, it is earned on the anchor line, and on lines 133 and 366 (APIM/MCP endpoints) as well. Absence of stamps is not the only clearing condition; a stamp that survives its own source check is another.\n\nCROSS-FILE CLAIM ADJUDICATED UNDER #33 - SWEEP LOCATES, SOURCE ADJUDICATES. The entry says the capabilities \"are asserted in four other corpus files\". Rather than treat the string hits as the finding, the source EACH file attributes to was looked up. skills/**/*.md yields ~13 hits for \"Azure Resource Graph\" and ~30 for \"Insider Risk Management\"; under CAF attribution the population is THREE other files, not four: ai-incident-response-procedures.md (lines 48, 505, 575), data-leakage-prevention-ai.md (line 780), norge-ai-strategy-government.md (lines 150, 152). Each attributes to CAF Secure AI, and the live page supports each. THE COUNT IN THIS ENTRY IS CORRECTED 4 -> 3. Its source, r11-pilot-results.md 9.5, wrote \"at least four other files\" and then enumerated exactly these three; the entry inherited the miscount.\n\nTHE #33 FORM EARNED ITS KEEP ON A FOURTH FILE. ai-security-scoring-framework.md:135 reads \"Azure Resource Graph for security assessments (Defender for Cloud)\" - the same product pairing that WAS the defect in this file, where Azure Resource Graph was claimed as a Defender for Cloud AISPM capability. It is CORRECT there: that file's own Kilder list (line 485) cites defender-for-cloud/resource-graph-samples, fetched this session and confirmed to be \"Azure Resource Graph sample queries for Microsoft Defender for Cloud\" - i.e. Resource Graph as the query surface over Defender's security assessments, not as a Defender capability for discovering AI workloads. Same string, different source, opposite verdict. Booked here as CHECKED-AND-CLEAR so a future sweep does not re-book it. nsm-grunnprinsipper-ai-mapping.md:103,424 attribute to the NSM mapping with no CAF claim and are independently true.\n\nWHAT THIS LEAVES OF THE ENTRY. The 957ebef subtraction stands as CORRECT: the deleted bullets attributed Azure Resource Graph and Purview Insider Risk Management to Defender for Cloud AISPM, and the live CAF page assigns Resource Graph to Azure governance and IRM to Purview, while giving Defender for Cloud the separate job of identifying generative AI workloads. The survivors are not a residue of a defect - they are the same capabilities correctly attributed. 9.5's observation that the edit's corpus-wide benefit is smaller than the single line suggests survives as a note about REVIEW COST for this edit class; it was never a claim that the survivors were wrong, and measurement confirms they are not."
},
{
"id": "idx-26",
@ -105,13 +106,14 @@
"id": "idx-36",
"file": "skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md",
"class": "multi-locator",
"status": "open",
"status": "resolved",
"raised": "2026-08-03",
"summary": "Applying idx 36 alone yields a severity table more precise than the prose that cites it, so a companion edit is required for the prose to match the narrowed table. Held back from 957ebef as out of envelope.",
"evidence": "docs/r11-pilot-results.md §9.4, §9.5",
"anchors": [
"Øker severity bar; krever mer robust adversarial defenses"
]
],
"resolution": "Operator-ratified 2026-08-13, applied the same session, TWO in-place edits in one file. Resolved together with idx-33 (same file), per the #32 precedent of taking co-located instances in one commit.\n\nTHIS ENTRY'S OWN ANCHOR IS THE WRONG LINE - the #32 class, an entry whose recorded referent is not the thing the entry is about. The anchors array records \"Oker severity bar; krever mer robust adversarial defenses\", which is question 4, Physical Domain Impact. That prose does not cite the poisoning row and is NOT defective (the cited source gives Adversarial Example in the Physical domain severity Critical). The evidence this entry names says otherwise and says it precisely: 9.4 and 9.5 both locate the companion edit at \"the prose at 310\". Read verbatim out of 957ebef^, pre-edit line 310 is \" - *Hvorfor:* Backdoored models og data poisoning er Critical-severity trusler.\" - question 3, Supply Chain Dependencies, post-edit line 309. The anchors array is LEFT AS RECORDED rather than rewritten, because it is the historical record of what was booked; the correction lives here.\n\nTHE SUBTRACTION VERIFIED AGAINST THE SOURCE THE FILE ITSELF CALLS AUTHORITATIVE. Line 355 lists security/engineering/threat-modeling-aiml as the \"**Authoritative guide** for STRIDE adaptation to AI/ML\". Fetched live 2026-08-13: \"#2a Targeted Data Poisoning ... Severity: Critical\"; \"#2b Indiscriminate Data Poisoning ... Traditional Parallels: Authenticated Denial of service against a high-value asset ... Severity: Important\"; \"#10 Backdoor Machine Learning ... Severity: Critical\". The row gave the single shared cell Critical to both variants, so it overclaimed for the indiscriminate one. The O2 return record (r11-o2-returns/batch-06.json, idx 36) reproduces this correctly.\n\nCOND 3 WAS THE ONLY REAL HUMAN CONDITION AND THE OPERATOR ANSWERED IT. The return record states it exactly: the confirmed value (Important) cannot be swapped in place because one Severity cell serves the whole row, so preserving the variant would require ADDING a row, and a human had to confirm that dropping the coverage is acceptable rather than mandating that rewrite. Ratified: DROP THE COVERAGE. The file now says nothing at all about the indiscriminate variant - silent, not wrong - rather than gaining a row whose need nobody measured.\n\nTHE FRAMING INVERTED ON MEASUREMENT, AND THAT IS THE REUSABLE PART. 9.5 held idx 36 back because \"applying it alone yields a severity table more precise than the prose that cites it\" - i.e. the companion edit was cast as a CONSEQUENCE of the edit, an out-of-envelope second locator. Measured against the live source, line 309 asserts Critical for data poisoning UNQUALIFIED and was therefore already unsupported BEFORE any edit: the source says indiscriminate is Important today and said so in 2019. The table edit does not make the prose wrong; it exposes prose that was wrong on its own. So this was never a single-locator problem with an awkward companion - it was TWO INSTANCES OF ONE DEFECT in one file, which is exactly the shape #32 governs, and it was applied as one commit accordingly.\n\nENUMERATION CLOSED BEFORE APPLYING, so the companion set is provably complete: grep -n \"oisoning\" over the file returns 8 lines (25, 38, 70, 91, 166, 245, 309, 320). Only 38 and 309 carry a severity claim; 25, 70, 91, 166, 245 and 320 name poisoning without asserting a severity. Line 345 (\"Critical-severity trussel med lav attack complexity\") is a generic prioritisation rule naming no threat, and line 170 (\"higher severity bar\") is the physical-domain row, source-supported. The set is {38, 309} and nothing else.\n\nFORM AS APPLIED. Line 38 -> \"| **Tampering** | Data Poisoning (targeted), Backdoored Models | Critical | Training data validation, anomaly detection, RONI defense, bagging |\" - character-for-character the proposed_remainder in the return record, deletion of the 15 characters \"/indiscriminate\" only. Line 309 -> \" - *Hvorfor:* Backdoored models og targeted data poisoning er Critical-severity trusler.\" The prose form is an INSERTION of one word, not a deletion, so apply-o2-ratified.mjs could not have written it and did not: both edits were made by hand with whole-line uniqueness checked first (each target string occurred exactly once) and the diff read in context afterwards. The inserted word is the table's own qualifier, so prose and table now say the same thing; the deletion-only alternative (\"Backdoored models er Critical-severity trusler.\") was offered and declined because it would have dropped poisoning out of the supply-chain rationale entirely. File length unchanged at 368 lines - both edits are in place."
},
{
"id": "idx-18",
@ -1021,6 +1023,18 @@
"- Copilot Studio generative AI toolkit: Pre-built \"AI disclosure\" topic"
],
"resolution": "Operator-ratified 2026-08-13 under form #32, in the same commit as idx-27c and idx-27d, because it is the same defect class and adjudicating it separately would have left the file asserting a surface we had just measured as nonexistent. DELETED rather than replaced - there is no corrected artefact name, and the verified Copilot Studio disclosure (the standard transparency message) is already documented at lines 218 and 425 in this same file, so restating it here would duplicate rather than repair. The remaining \"Customization\" list (Adaptive cards: Template for transparency notices) was read after the edit and stands."
},
{
"id": "idx-33a",
"file": "skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md",
"class": "replacement",
"status": "open",
"raised": "2026-08-13",
"summary": "Surfaced while resolving idx-33, in the very block idx-33's subtraction edited, and booked rather than fixed because it is a separate claim with a separate source. Under \"### Microsoft Defender for Cloud - AI Security Posture Management\", the bullet list is stamped \"**Capabilities:** *(Verified MCP 2026-04)*\" and its third bullet reads \"Security recommendations for AI models, data stores, network isolation\". The live Defender AISPM page (defender-for-cloud/ai-security-posture, fetched 2026-08-13) enumerates the recommendation surface as \"recommendations on identity, data security, and internet exposure\". The file DROPS identity and ADDS \"AI models\" - a substituted enumeration under a verification stamp, the shape 9.8 records as the dropped-qualifier pattern. Two caveats keep this a CANDIDATE and not a confirmed defect: \"data stores\"/\"network isolation\" are defensible renderings of \"data security\"/\"internet exposure\" (the page's IaC checks do include private endpoints and endpoint restriction), and the page does say Defender \"assesses AI workloads\", which is not nothing for \"AI models\". SEPARATE AND FIRMER: this file's Kilder list carries 8 sources and NONE of them is a Defender for Cloud AISPM page, so the whole stamped block at 208-221 has no cited referent in the file it lives in - the stamp asserts verification against a source the file never names. Resolving this should decide the bullet AND whether a stamped block may cite outside the file's own source list.",
"evidence": "idx-33 resolution (live CAF + Defender AISPM fetches, 2026-08-13); docs/r11-pilot-results.md 9.5, 9.8; 957ebef (the subtraction that left this block)",
"anchors": [
"- Security recommendations for AI models, data stores, network isolation"
]
}
]
}