Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:
1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
`Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
132 bokføres til R13b/R14.
Tre korreksjoner av premisser som sto i ordren og STATE:
«ca 320 produkt» -> 451 (case-sensitivt nett manglet 327 lowercase
TOC-ankre + 99 identifikatorer; sann nevner 1 638)
«169 headinger» -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
internt inkonsistent med sin egen topp-variant (204)
«417 matcher ingen
populasjon» -> 417 er cosmo-headinger utenfor kodefences; briefens
nevner var reell hele tiden
Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.
TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.
Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.
Verifisering (alle 7 kriterier fra ordren):
G1 persona på heading-linjer 401 -> 0
G2 døde fragmentlenker 1 -> 1 (pre-eksisterende, unntatt)
G3 produkt-forekomster 451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
de 3 kun-produkt-filene byte-identiske
nettet validert begge veier injisert persona feller G1; genitiv feller G1;
produkt-heading og de 3 filene passerer
hele diffen 802 heading-linjer + 654 TOC-linjer, ANNET = 0
linjeantall 728 lagt til = 728 slettet
suite 1120/1120 (1097 + 23 nye)
validate-plugin 250 PASS / 0 FAIL
stikkprøve 10 filer, alle 5 skills, inkl. de 3 mest
produkt-tunge (26/20/19) — kun heading+TOC
Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
254 lines
9.8 KiB
Markdown
254 lines
9.8 KiB
Markdown
# MAESTRO 7-lags sikkerhetsmodell for multiagent AI-systemer
|
|
|
|
**Last updated:** 2026-02
|
|
**Category:** Norwegian Public Sector AI Governance
|
|
**Status:** Established Practice
|
|
**Formål:** Strukturert sikkerhetsmodell for multiagent-orkestrering — brukes av ros-analysis-agent for dybdevurdering av agent-baserte systemer
|
|
**Type:** methodology
|
|
|
|
---
|
|
|
|
## Innhold
|
|
|
|
- [Oversikt](#oversikt)
|
|
- [De 7 lagene](#de-7-lagene)
|
|
- [Defense-in-depth for multiagent-systemer](#defense-in-depth-for-multiagent-systemer)
|
|
- [MAESTRO-sjekkliste for ROS-analyse](#maestro-sjekkliste-for-ros-analyse)
|
|
- [Referanser](#referanser)
|
|
- [For arkitekten](#for-arkitekten)
|
|
|
|
## Oversikt
|
|
|
|
MAESTRO (Multi-Agent Environment Security Threat and Risk Operations) er et 7-lags sikkerhetsrammeverk utviklet av OWASP for å adressere unike sikkerhetsutfordringer i multiagent AI-systemer. Rammeverket bygger på defense-in-depth-prinsippet og gir et systematisk verktøy for å identifisere, vurdere og mitigere risiko i hvert lag av en agent-arkitektur.
|
|
|
|
I norsk offentlig sektor er MAESTRO særlig relevant for:
|
|
- Foundry Agent Service-baserte systemer med verktøytilgang
|
|
- Copilot Studio-agenter med actions/plugins og multi-agent orkestrering
|
|
- Power Automate agentflows med autonom beslutningstaking
|
|
- Microsoft 365 Copilot med extensions og personlige agenter
|
|
|
|
---
|
|
|
|
## De 7 lagene
|
|
|
|
### Lag 1: Foundation Model
|
|
|
|
**Beskrivelse:** Det underliggende AI-modellaget — selve språkmodellen eller multimodalmodellen som agenten er bygget på.
|
|
|
|
**Nøkkelrisikoer:**
|
|
- Inherent bias og hallusinasjon i modellvekter
|
|
- Modellens evne til å bli manipulert via prompt injection
|
|
- Jailbreak-sårbarhet varierer mellom modellgenerasjoner
|
|
|
|
**Mapping til trusselbibliotek:** T-INP-01, T-INP-03, T-DAT-03, T-MOD-01, T-MOD-02
|
|
|
|
**Microsoft-kontroller:**
|
|
- Azure AI Content Safety (content filters, prompt shields)
|
|
- Modellvalg fra Azure AI Model Catalog med sikkerhetsvurdering
|
|
- System message hardening og rolleavgrensning
|
|
|
|
---
|
|
|
|
### Lag 2: Data & Knowledge
|
|
|
|
**Beskrivelse:** Datakildene agenten har tilgang til — RAG-indekser, kunnskapsbaser, databaser, filsystemer og API-er som mater agentens kontekst.
|
|
|
|
**Nøkkelrisikoer:**
|
|
- Data poisoning og RAG-forgiftning (PoisonedRAG-teknikker)
|
|
- Datalekkasje via retrieval-mekanismer
|
|
- Utdatert eller korrupt kunnskapsbase
|
|
- Manglende document-level tilgangskontroll
|
|
|
|
**Mapping til trusselbibliotek:** T-DAT-01, T-DAT-02, T-DAT-04, T-DAT-06, T-SUP-03
|
|
|
|
**Microsoft-kontroller:**
|
|
- Azure AI Search security trimming og document-level RBAC
|
|
- Purview sensitivity labels og data classification
|
|
- Content hashing for integritetsvalidering
|
|
- Automatisk re-indeksering med datakvalitetskontroll
|
|
|
|
---
|
|
|
|
### Lag 3: Agent Core
|
|
|
|
**Beskrivelse:** Agentens kjernelogikk — system prompt, instruksjoner, beslutningsregler, og minnemekanismer som styrer agentens atferd.
|
|
|
|
**Nøkkelrisikoer:**
|
|
- System prompt-manipulasjon og lekkasje
|
|
- Agent scheming og strategisk misalignment
|
|
- Uautorisert endring av agentinstruksjoner
|
|
- Minneforurensing i langtidssamtaler
|
|
|
|
**Mapping til trusselbibliotek:** T-OUT-01, T-DAT-05, T-AGT-06, T-INP-04
|
|
|
|
**Microsoft-kontroller:**
|
|
- Protected system messages i Microsoft Foundry
|
|
- PIM-basert tilgangskontroll for agentkonfigurasjon
|
|
- Session-resett etter definert antall omganger
|
|
- Agent behavior monitoring via Azure Monitor
|
|
|
|
---
|
|
|
|
### Lag 4: Tools & APIs
|
|
|
|
**Beskrivelse:** Verktøyene agenten kan kalle — API-er, filsystem, databaser, e-post, og andre eksterne tjenester som agenten kan interagere med.
|
|
|
|
**Nøkkelrisikoer:**
|
|
- Overdrevne verktøytillatelser (excessive agency)
|
|
- Eksfiltrering via tillatte tool-kall
|
|
- Uønskede irreversible sideeffekter
|
|
- MCP/Skills supply chain-forgiftning
|
|
|
|
**Mapping til trusselbibliotek:** T-AGT-01, T-OUT-05, T-AGT-03, T-SUP-04, T-SUP-06
|
|
|
|
**Microsoft-kontroller:**
|
|
- Minste privilegium for agent tool-tilgang
|
|
- Human-in-the-loop for destruktive actions
|
|
- Entra Agent ID-signering for plugins
|
|
- Output-validering mellom tool-kall
|
|
|
|
---
|
|
|
|
### Lag 5: Orchestration
|
|
|
|
**Beskrivelse:** Orkestrasjonslaget som koordinerer multiple agenter — inkludert agent-til-agent-kommunikasjon, oppgavefordeling og resultatsammenstilling.
|
|
|
|
**Nøkkelrisikoer:**
|
|
- Agentkjede-forgiftning (en kompromittert agent forgifter nedstrøms)
|
|
- Ressursutarming via ukontrollerte agent-loops
|
|
- Uautorisert inter-agent kommunikasjon
|
|
- Manglende validering mellom agentlag
|
|
|
|
**Mapping til trusselbibliotek:** T-AGT-02, T-AGT-04
|
|
|
|
**Microsoft-kontroller:**
|
|
- Foundry Agent Service med Agent-to-Agent (A2A) protokoll
|
|
- Signert agent-til-agent-kommunikasjon via Entra Agent ID
|
|
- Timeout og maksimum iterasjoner per agent-run
|
|
- Output-sanitering mellom agentlag i orchestrator
|
|
|
|
---
|
|
|
|
### Lag 6: Deployment
|
|
|
|
**Beskrivelse:** Produksjonsmiljøet der agenten kjører — infrastruktur, nettverk, tilgangskontroll og driftskonfigurasjon.
|
|
|
|
**Nøkkelrisikoer:**
|
|
- Sårbare avhengigheter i agent-runtime (Python/npm-pakker)
|
|
- Utilstrekkelig nettverkssegmentering
|
|
- Manglende overvåking og logging av agentaktivitet
|
|
- Kapasitetsgrenser og throttling ved peak-belastning
|
|
|
|
**Mapping til trusselbibliotek:** T-SUP-02, T-AVL-01, T-AVL-02, T-AVL-04, T-AGT-05
|
|
|
|
**Microsoft-kontroller:**
|
|
- Microsoft Defender for DevOps (dependency scanning)
|
|
- Azure Virtual Network isolering for agent-tjenester
|
|
- Azure Monitor diagnostics med agent-spesifikke metriker
|
|
- PTU (Provisioned Throughput Units) for kapasitetsgaranti
|
|
|
|
---
|
|
|
|
### Lag 7: Ecosystem
|
|
|
|
**Beskrivelse:** Det bredere økosystemet av aktører — brukere, leverandører, regulatorer, og andre systemer som interagerer med agent-systemet.
|
|
|
|
**Nøkkelrisikoer:**
|
|
- Kompromitterte tredjeparts-tjenester og leverandører
|
|
- Manglende governance for personlige AI-agenter
|
|
- Utilstrekkelig leverandørgjennomgang (TPRM)
|
|
- Regulatorisk non-compliance (AI Act, GDPR)
|
|
|
|
**Mapping til trusselbibliotek:** T-SUP-01, T-SUP-05, T-AGT-07, T-PRI-01, T-PRI-03
|
|
|
|
**Microsoft-kontroller:**
|
|
- Admin consent-policyer i Entra ID
|
|
- DLP-policyer for Copilot og Power Platform
|
|
- Microsoft EU Data Boundary
|
|
- Leverandørvurdering per NSM veileder
|
|
|
|
---
|
|
|
|
## Defense-in-depth for multiagent-systemer
|
|
|
|
Fem forsvarslinjer som bør implementeres i ethvert multiagent-system:
|
|
|
|
### Forsvarslinje 1: Input-sanitering
|
|
- Validér og sanitér all input til agenter fra brukere og andre agenter
|
|
- Implementer Prompt Shields for alle inngangspunkter
|
|
- Begrens kontekstvindulengde for å redusere multi-turn-angrep
|
|
|
|
### Forsvarslinje 2: Inter-agent validering
|
|
- Valider output fra hver agent før den sendes videre til neste
|
|
- Implementer type-sjekking og schema-validering på agent-meldinger
|
|
- Krev digital signatur (Entra Agent ID) for all agent-til-agent-kommunikasjon
|
|
|
|
### Forsvarslinje 3: Policy enforcement
|
|
- Definer eksplisitte policyer for hvilke verktøy hver agent kan bruke
|
|
- Implementer rate limiting per agent og per verktøy
|
|
- Krev human-in-the-loop for alle irreversible handlinger
|
|
|
|
### Forsvarslinje 4: Output-kontroll
|
|
- Valider all agent-output mot innholdspolicyer (Content Safety)
|
|
- Implementer PII-deteksjon og redaksjon i output-pipeline
|
|
- Verifiser at output er grounded i godkjente kilder
|
|
|
|
### Forsvarslinje 5: Sandbox og isolering
|
|
- Kjør agenter i isolerte sandboxer med minimal systemtilgang
|
|
- Implementer nettverkssegmentering mellom agent-tjenester
|
|
- Bruk separate identiteter per agent (ikke delt service principal)
|
|
|
|
---
|
|
|
|
## MAESTRO-sjekkliste for ROS-analyse
|
|
|
|
Bruk denne sjekklisten i Fase 5 (Sårbarhetsanalyse) for systemer med AI-agenter:
|
|
|
|
| Lag | Sjekkpunkt | Status |
|
|
|-----|-----------|--------|
|
|
| 1. Foundation Model | Content Safety og Prompt Shields aktivert | [OK/Gap/N/A] |
|
|
| 2. Data & Knowledge | Document-level RBAC og datakilde-validering | [OK/Gap/N/A] |
|
|
| 3. Agent Core | Protected system messages og konfig-RBAC | [OK/Gap/N/A] |
|
|
| 4. Tools & APIs | Minimal tool-scope og plugin-godkjenning | [OK/Gap/N/A] |
|
|
| 5. Orchestration | Inter-agent validering og timeout-grenser | [OK/Gap/N/A] |
|
|
| 6. Deployment | Dependency scanning og agent-logging | [OK/Gap/N/A] |
|
|
| 7. Ecosystem | Leverandørvurdering og agent-governance | [OK/Gap/N/A] |
|
|
|
|
---
|
|
|
|
## Referanser
|
|
|
|
- OWASP MAESTRO (Multi-Agent Environment Security Threat and Risk Operations), 2025
|
|
- Apollo Research — "Frontier Models are Capable of In-Context Scheming", 2025
|
|
- ToxicSkills — "Jailbreaking LLMs via MCP Skills", USENIX Security 2025
|
|
- PoisonedRAG — "Knowledge Poisoning Attacks to Retrieval-Augmented Generation", USENIX Security 2025
|
|
- ClawHavoc — "Unveiling the Threats of MCP", ArXiv 2025
|
|
- MCPTox — "A Large-Scale Study on MCP Security", 2025
|
|
- Pillar Security — MCP Security Audit, 2025
|
|
- Microsoft Entra Agent ID documentation, 2025
|
|
- Foundry Agent Service GA documentation, 2025
|
|
|
|
---
|
|
|
|
## For arkitekten
|
|
|
|
### Bruk av MAESTRO i kundedialog
|
|
|
|
MAESTRO-rammeverket brukes når kunden har eller planlegger et agentbasert AI-system. Integrer det i ROS-analysen slik:
|
|
|
|
1. **Fase 4 (Trusselidentifisering):** Bruk lag-mappingen til å identifisere relevante trusler systematisk — gå gjennom hvert av de 7 lagene og sjekk om tilhørende trusler er relevante
|
|
2. **Fase 5 (Sårbarhetsanalyse):** Bruk MAESTRO-sjekklisten som supplement til den generelle sårbarhetsanalysen
|
|
3. **Fase 7 (Tiltaksplan):** Strukturer tiltak per forsvarslinje (defense-in-depth)
|
|
|
|
### Når er MAESTRO relevant?
|
|
|
|
- **Alltid relevant:** Systemer med Foundry Agent Service, Copilot Studio autonome agenter, Power Automate agentflows
|
|
- **Delvis relevant:** Enkle chatboter med verktøytilgang (bruk lag 1-4)
|
|
- **Ikke relevant:** Statiske modeller uten verktøytilgang eller agent-funksjonalitet (standard RAG-chatbot uten actions)
|
|
|
|
### Typiske gap i norsk offentlig sektor
|
|
|
|
1. **Inter-agent validering mangler** — agenter kommuniserer uten output-sjekk mellom lag
|
|
2. **Delt service principal** — alle agenter bruker samme identitet, umulig å skille i audit trail
|
|
3. **Ingen agent-inventory** — IT-avdelingen vet ikke hvilke agenter som er aktive
|
|
4. **Overdrevne tool-tillatelser** — agenter har tilgang til 10x flere verktøy enn nødvendig
|