Ren value-preserving label-relabel av de to norske header-labelene til engelsk på 51 ref-filer (22 bærer begge). Ny testet ren primitiv relabelHeaderDialect() (header-blokk-scoped, kollisjons-/multiforekomst-guard) + manifest-drevet driver relabel-dialect.mjs (frosset 51-fil-manifest, hard per-fil-invariant, idempotent, isMain-guard). **Dato:** bevisst UTE (body-template-felle → Enhet 2). Premiss-korreksjon i roadmap R22: tredje Dato-dialekt (16), 0 bold-duplikater (ikke 4), 1 datoløs (ikke 5), category-none = vindus-artefakt. test-relabel-dialect 11/11; diff +73/-73 0 linjer utover label; suite 782/782 exit 0.
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 Cosmo Skyberg](#for-cosmo-skyberg)
|
|
|
|
## 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 Cosmo Skyberg
|
|
|
|
### 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
|