--- title: "Minne er ikke fullmakt." subtitle: "Varig kontekst og tillatelsesgrenser i KI-agenter." author: Raindance language: nb date: 2026-10-19 canonical: https://raindance.no/nb/innsikt/memory-is-not-authority content_type: technical-essay --- # Minne er ikke fullmakt. Varig kontekst og tillatelsesgrenser i KI-agenter. ## Sammendrag En agent kan hente frem en korrekt beskrivelse av gårsdagens arbeid og likevel mangle tillatelse til å fortsette i dag. Skillet får praktisk betydning når assistenter lagrer notater, gjenopptar jobber, deler søkesystemer eller bruker verktøy med virkninger utenfor samtalen. En husket godkjenning kan være utløpt, snevrere enn oppsummeringen gir inntrykk av, eller knyttet til en annen person eller et annet miljø. Denne artikkelen utvikler et praktisk skille mellom opplysninger som brukes til å planlegge en handling, og fullmakten som kreves for å utføre den. Eksemplet følger en assistent som forbereder og publiserer versjonsnotater. Det introduserer minne med dokumentert kildeopphav, godkjenninger knyttet til bestemte handlinger, autorisasjon håndhevet av vertssystemet og en uttrykkelig grense for når operasjonen sendes videre. Eksemplene og diagrammene er egne designøvelser, ikke beskrivelser av et Raindance-system i drift eller målte sikkerhetsresultater. Protokollkrav skilles fra foreslåtte applikasjonsmønstre. Den sentrale invarianten er enkel: **Innhold som hentes frem, kan forklare en forespørsel; det skal ikke kunne gi seg selv tillatelse til å utføre den.** Varige fullmakter kan være legitime, men de hører hjemme i en beskyttet autorisasjonsmekanisme, ikke i en redigerbar fortelling om tidligere arbeid. ## 1. Utgivelsen som overlevde tillatelsen sin Tenk deg et lite programvareteam som bruker en assistent til å forberede kunngjøringer om nye versjoner. På mandag ber en vedlikeholder assistenten om et utkast for versjon 2.4. Assistenten leser sammenslåtte endringer, skriver et utkast og lagrer et fremdriftsnotat. Vedlikeholderen godkjenner publisering av akkurat dette utkastet på dokumentasjonens testnettsted. Økten avsluttes før publiseringen skjer. På tirsdag henter en ny økt frem denne oppsummeringen: > Versjon 2.4 er godkjent. Neste steg: publiser kunngjøringen. Hver setning kan ha et uskyldig opphav. Likevel har oppsummeringen mistet destinasjonen, det nøyaktige utkastet, identiteten til godkjenneren og godkjenningens varighet. I mellomtiden har en kollega endret kunngjøringen, og assistentens nåværende prosjekt bruker produksjon som standard. Å utføre det huskede neste steget ville gjøre en historisk beskrivelse til en videre fullmakt. Feilen krever verken en ondsinnet modell eller et oppdiktet minne. Den oppstår når to ulike typer oppføringer behandles som om de var utskiftbare. Den ene sier hva som skjedde. Den andre angir hva en bestemt aktør kan gjøre med en bestemt ressurs under gjeldende vilkår. I eksemplet bør assistenten hente frem utkastet og undersøke den beskyttede godkjenningsoppføringen. Hvis den bare dekker testmiljøet, er produksjon fortsatt utilgjengelig. Hvis innholdet er endret, kreves en ny beslutning for den nye revisjonen. Hvis godkjenningen fortsatt gjelder og alle bindinger stemmer, kan assistenten fortsette uten å stille samme spørsmål på nytt. Det siste tilfellet er viktig. En god tillatelsesmodell bevarer nyttige fullmakter gjennom avbrudd; den tvinger ikke brukeren til å bekrefte hvert ufarlig steg igjen. Den tekniske oppgaven er å bevare omfanget presist og håndheve det konsekvent. Skillet gjør også brukeropplevelsen tydeligere. En gjenopptatt assistent kan si at godkjenningen for testmiljøet fortsatt gjelder, vise den uendrede revisjonen og fortsette. Når destinasjonen endres, kan den forklare nøyaktig hvilken grense som er endret. En generell forespørsel om å «godkjenne igjen» skjuler begrunnelsen og gjør grundig gjennomgang vanskeligere. ## 2. Skill informasjon, hensikt og fullmakt I denne modellen brukes tre kategorier. **Informasjon** beskriver observasjoner eller antakelser: Utkastet finnes, en test feilet, brukeren foretrekker kortfattet språk. **Hensikt** beskriver et ønsket resultat: Forbered en kunngjøring, undersøk en feil. **Fullmakt** tillater en avgrenset operasjon: Publiser revisjon 7 av utkastet til testnettstedet før en bestemt frist. Ett dokument kan inneholde alle tre typer utsagn. At de står i samme dokument, gir dem ikke de samme tillitsegenskapene. En sak som hentes frem, kan uttrykke forfatterens hensikt uten å autorisere den nåværende assistenten til å utføre den. En oppgavebeskrivelse kan fastsette et mål samtidig som produksjonstilgang fortsatt mangler. Anthropic beskriver komprimering og varige notater som teknikker for å ta med nyttig kontekst gjennom langvarig arbeid. Dette forklarer hvordan en senere økt kan hente tidligere opplysninger, men etablerer ikke i seg selv et tillatelsessystem. I vår modell behandles oppsummeringer som planleggingsgrunnlag med uttrykkelig kildeopphav. [1: Anthropic om kontekststyring](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) Sikkerhetsgrunnlaget er eldre enn agentene. Saltzer og Schroeder beskriver minste privilegium, tilgang som standard krever tillatelse, og kontroll av tilgang fremfor å anta at den gjelder ubegrenset. Her anvender vi disse prinsippene på en bestemt grense: en assistents foreslåtte verktøyhandling. Det er en arkitektonisk anvendelse av etablerte ideer, ikke en ny sikkerhetsmekanisme i seg selv. [2: Saltzer og Schroeders grunnleggende beskyttelsesprinsipper](https://web.mit.edu/Saltzer/www/publications/protection/Basic.html) En autorisasjonsdatabase husker også opplysninger. Det nyttige skillet går derfor ikke mellom midlertidig og varig lagring, men mellom **hvem som kan opprette en fullmakt, hva den er bundet til, og hvilken betrodd komponent som validerer den**. Et modellskrevet JSON-objekt med `approved: true` får ingen autoritet bare fordi syntaksen ligner en ekte oppføring. ## 3. Gi minnet et opphav og en grense Et fremdriftsnotat bør gjøre det mulig å rekonstruere betydningen. For publiseringseksemplet kan en kompakt oppføring se slik ut: ```json { "kind": "observation", "tenant_id": "studio-example", "project_id": "docs-staging", "statement": "A maintainer approved draft revision 7 for staging.", "source": { "type": "conversation_event", "id": "event-481", "observed_at": "2026-10-19T09:00:00Z" }, "derived_by": "summary-job-12", "review_after": "2026-10-20T09:00:00Z", "expires_at": "2026-11-19T09:00:00Z", "trust": "derived-context", "authorization_reference": "approval-93" } ``` Dette er et eksempel på et applikasjonsskjema. Identifikatorene er fiktive. Referansen peker mot en godkjenningstjeneste; den er ikke en innehaverlegitimasjon og skal ikke avsløre en hemmelighet. Tjenesten kontrollerer uavhengig om den autentiserte klienten får lese godkjenningen. Kildeidentifikatoren gjør det mulig for vertssystemet å skille en direkte hendelse fra en oppsummering av en oppsummering. `review_after` betyr at utsagnet bør kontrolleres før man bygger videre på det; `expires_at` styrer hvor lenge notatet beholdes. Ingen av tidsstemplene avgjør hvor lenge godkjenningen gjelder. `trust` er metadata som settes og beskyttes av innlesingskoden, ikke en merkelapp et vilkårlig importert dokument kan tildele seg selv. I denne applikasjonen filtrerer søkekomponenten på autentisert organisasjon og prosjekt før den returnerer tekst. Modellen leverer ikke den autoritative organisasjonsidentifikatoren. En forespørsel som navngir et annet prosjekt, kan avvises før søket, slik at et forbudt dokument aldri når modellens kontekst. Bruk samme grense for kildeoppslag, mellomlagrede utdrag, søkeindekser og eksporterte oppsummeringer. Her finnes en nyttig asymmetri. Sletting av et notat skal ikke i det skjulte tilbakekalle en ellers gyldig fullmakt; tilbakekalling av en fullmakt skal ikke kreve at man finner alle kopier av et notat. Separate livsløp gjør begge operasjoner håndterlige. Hvor lenge et minne beholdes, hvor ferske opplysningene er og når tillatelsen utløper, er ulike spørsmål. ## 4. Legg beslutningen utenfor modellen Assistenten lager et handlingsforslag. En kontrollport i vertssystemet fastslår den autentiserte identiteten, validerer forespørselen og innhenter en gjeldende autorisasjonsbeslutning. En snevert avgrenset verktøyadapter forsøker deretter den tillatte operasjonen. Legitimasjonen forblir i vertssystemet og adapteren, og legges ikke inn i modellens hentede kontekst. ![Minne og hentede dokumenter gir informasjon til planleggeren. Et handlingsforslag må gjennom vertssystemets autorisasjonskontroll, som sjekker identitet, policy og godkjenninger før verktøyadapteren når ressursen.](/innsikt/diagrams/memory-authority-nb.svg) Diagrammet skiller informasjonsflyten fra autorisasjonsflyten. Et dokument kan påvirke hvilken handling planleggeren foreslår, men har ingen direkte vei til den beskyttede ressursen. Den samme kontrollen behandler rimelige forslag, feil og bevisst skadelige forslag. Skillet må finnes i kjørbare kontroller; bokser i et diagram eller instruksjoner i en prompt skaper det ikke. NISTs nulltillitsarkitektur skiller policybeslutninger fra håndheving og unngår å gi tillit utelukkende ut fra nettverksplassering. Eksemplet vårt bruker dette skillet på applikasjonsnivå: Kontrollporten vurderer tilgangen, og adapteren håndhever begrensningene. Dette betyr ikke at skissen er en komplett implementering i samsvar med NIST. [3: NIST SP 800-207](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf) I MCPs versjonerte arkitektur håndterer verten autorisasjonsbeslutninger, samtykkekrav og grenser mellom klienter. At en server annonserer et verktøy, betyr at protokollfunksjonen finnes, ikke at enhver bruk er tillatt. Applikasjonspolicy og ressursserverens egne kontroller er fortsatt nødvendige. [4: MCP-arkitektur, 2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/architecture) For publiseringsassistenten ville et generelt skall med ubegrensede produksjonsnøkler undergrave modellen. Det kunne gi en alternativ vei utenom publiseringsadapteren. Oppsettet må også begrense slike alternative veier: filsystemtilgang, underprosesser, utgående forespørsler og legitimasjon. En presis kontrollport hjelper bare hvis handlingene med reelle konsekvenser faktisk må gjennom den. ## 5. Godkjenn operasjonen som faktisk skal utføres Publiseringsgodkjenningen bør binde den menneskelige beslutningen til et uforanderlig forslag. Forslaget må som minimum angi organisasjon, utførende aktør, handling, destinasjon og nøyaktig innholdsrevisjon. Det må også inneholde utløpstid, relevant policyversjon og en unik operasjonsidentifikator. Vertssystemet tildeler verdiene fra validert tilstand. En gjennomgang bør vise de vesentlige opplysningene fremfor å spørre om assistenten kan «fortsette». I eksemplet: Publiser revisjon 7 av kunngjøringen for versjon 2.4 til testnettstedet på vegne av den identifiserte vedlikeholderen. Godkjenningsoppføringen lagrer denne beslutningen gjennom et autentisert grensesnitt. Et verktøyresultat eller et hentet avsnitt kan ikke opprette den samme oppføringen. RFC 9396 beskriver strukturerte autorisasjonsdetaljer som kan uttrykke mer finmaskede forespørsler enn brede tilgangsområder. Det er et nyttig standardisert forbilde for å beskrive en konkret handling og dens mål. Godkjenningsmodellen her er applikasjonsspesifikk; den implementerer ikke RFC-en bare fordi den bruker strukturerte felt. [5: OAuth-forespørsler med detaljerte autorisasjonskrav](https://www.rfc-editor.org/rfc/rfc9396.html) En hash av det gjennomgåtte innholdet kan binde godkjenningen til nøyaktig innhold, forutsatt at serveren definerer en stabil, kanonisk representasjon. Den må dekke alle sikkerhetsrelevante felt, også destinasjon og vedlegg. Hashen fastslår ikke hvem som godkjente noe; den koblingen kommer fra en beskyttet godkjenningsoppføring. Brukeren skal gjennomgå forståelig innhold, ikke forventes å tolke en hash. ![Et forslag vurderes og kan godkjennes. Utløpte, tilbakekalte eller endrede forslag kan ikke sendes. En gyldig godkjenning kan autorisere én identifisert operasjon, med fullført, mislykket eller usikkert utfall.](/innsikt/diagrams/approval-lifecycle-nb.svg) Den utførende aktøren og godkjenneren trenger ikke være samme identitet. En tjenestekonto kan publisere på vegne av en vedlikeholder. Godkjenningstjenesten må kontrollere at vedlikeholderen kan delegere operasjonen, binde fullmakten til riktig tjenesteidentitet og beholde begge identiteter for etterprøvbarhet. Et visningsnavn kopiert fra en samtale kan ikke etablere denne delegeringen. En stående fullmakt kan bruke samme logikk med et bevisst videre omfang, som å publisere godkjente utkast til ett testnettsted i én arbeidsdag. Applikasjonen må representere dette omfanget uttrykkelig. Brede brukerpreferanser, husket entusiasme og tidligere vellykkede kall er ikke erstatninger for en fullmakt. ## 6. Kontroller autorisasjonen igjen ved utsending Følgende pseudokode viser en kontrollport for eksemplet. Den forutsetter et beskyttet godkjenningslager, en betrodd sesjon og en transaksjon som serialiserer relevante oppdateringer av policy, tilbakekallinger, godkjenninger og operasjoner. Dette er omfattende implementeringskrav, ikke egenskaper pseudokoden gir av seg selv. ```text function reservePublication(session, rawRequest): actor = authenticate(session) request = validateAndCanonicalize(rawRequest) transaction(serializable): policy = loadCurrentPolicy(actor.tenant) require policy.allows(actor, request) require request.tenant == actor.tenant operation = loadOperation(request.operationId) if operation exists: require operation.matches(actor, request) return authorizedOperationStatus(actor, operation) approval = loadApprovalForUpdate(request.approvalId) require approval.state == "approved" require approval.expiresAt > trustedNow() require approval.matches(actor, request, policy.version) require approval.remainingOperations > 0 consumeOneOperation(approval) return createReservedOperation(actor, request) function dispatch(operationId): operation = claimOnceAndRevalidate(operationId) if operation is denied: return denied return publicationAdapter.publish( operation.immutablePayload, idempotencyKey = operation.id ) ``` Grenen for gjentatte operasjoner er bevisst en vei til status, ikke en ny tillatelse til utførelse. En gjenbrukt operasjonsidentifikator med annet innhold eller annen identitet avvises. Å lese et gammelt resultat krever også gjeldende autorisasjon; en operasjonskvittering skal ikke gi tilgang til opplysninger aktøren ikke lenger får lese. Komponenten som sender operasjonen videre, validerer på nytt fordi det kan gå tid mellom reservasjon og utførelse. Definer beslutningen om utsending som punktet der en tilbakekalling kan komme for sent til å hindre en ekstern effekt. En tilbakekalling registrert før dette punktet må blokkere utsending under den valgte konsistensmodellen. En senere tilbakekalling kan stoppe nye operasjoner, men kan ikke pålitelig trekke tilbake en allerede akseptert forespørsel. Et krasj i en worker gir enda en grense. At en jobb er tatt, beviser ikke at den eksterne tjenesten mottok den. At workerens reservasjon er utløpt, beviser heller ikke at publiseringen mislyktes. En ny worker bør hente frem samme operasjon og avklare status. En lokal reservasjon hindrer vanlig samtidig utsending, men kan ikke alene garantere én ekstern effekt gjennom krasj og nye forsøk. Kontrollporten gjør ikke en databasetransaksjon atomisk sammen med en ekstern publiseringstjeneste. Hvis tjenesten publiserer og svaret forsvinner, er operasjonens utfall usikkert. Behold identifikatoren, hent autoritativ status når det er mulig, og bruk leverandørens dokumenterte idempotensmekanisme ved nye forsøk. Hvis trygg avklaring ikke finnes, må saken undersøkes fremfor å opprette en ny operasjon automatisk. Se [artikkelen om svar som forsvinner](/nb/innsikt/the-response-was-lost). ## 7. Behandle hentede instruksjoner som opplysninger, ikke fullmakter Tenk nå at assistenten leser en utgivelsessak som ber den publisere direkte til produksjon. I scenarioet er saken nyttig kildemateriale, men forfatteren er ikke den autentiserte godkjenneren. Vertssystemet kan beholde setningen som dokumentasjon på en forespørsel uten å behandle den som tillatelse. En mer subtil variant lagrer instruksjonen i en tilsynelatende nyttig oppsummering. Ved neste kjøring forsvinner det eksterne opphavet, og teksten ligner assistentens egen plan. I eksemplet må kildeopphavet bevares gjennom oppsummering, og importerte instruksjoner vises som kildeinnhold. Dette gjør feil lettere å undersøke; det beviser ikke at planleggeren vil ignorere alle ondsinnede instruksjoner. Den avgjørende testen er om et feilaktig forslag slipper gjennom. Kontrollporten vår avviser produksjonspublisering uten en samsvarende fullmakt, uansett hvor overbevisende modellen forklarer forslaget. Separate verktøy for lesing, utkast og publisering lar assistenten fortsette nyttig arbeid mens handlingen med større konsekvenser fortsatt er utilgjengelig. Leseoperasjoner trenger også policy. En assistent som får lese et privat utkast, får ikke nødvendigvis sende det til en annen tjeneste. I denne modellen kontrollerer publiseringsadapteren destinasjonen og tillatt dataklasse fremfor å godta en vilkårlig URL. Verktøyresultater utelater legitimasjon og returnerer bare materialet den aktuelle operasjonen trenger. For OAuth-beskyttede integrasjoner anbefaler RFC 9700 å begrense tokenets privilegier og tiltenkte mottakere. MCPs autorisasjonsspesifikasjon fra 2025-06-18 krever at servere validerer at et token er beregnet på dem, og forbyr å videresende klientens token til underliggende tjenester. Dette er grenser for legitimasjon, ikke bevis på at et bestemt menneske har godkjent en bestemt publisering. [6: Anbefalt sikkerhetspraksis for OAuth](https://www.rfc-editor.org/rfc/rfc9700.html#section-2.3), [7: MCP-autorisasjon, 2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization) ## 8. Test overganger, ikke bare velvillige samtaler Publiseringseksemplet gir konkrete tester som ikke avhenger av å overtale en modell. Send strukturerte forespørsler direkte til kontrollporten og kontroller både beslutningen og at forbudte eksterne effekter uteblir. | Scenario | Påkrevd resultat i denne modellen | | --- | --- | | Gyldig godkjenning, uendret utkast til testmiljø | Én identifisert operasjon kan sendes | | Minnet sier godkjent, men ingen fullmakt finnes | Publisering avvises | | Godkjent forespørsel for testmiljø retter seg mot produksjon | Publisering avvises | | Utkastet endres etter gjennomgang | Tidligere godkjenning kan ikke autorisere det | | Godkjenningen utløper mens jobben står i kø | Utsending avvises | | Godkjenningen tilbakekalles før utsending | Utsending avvises | | En annen organisasjon gjenbruker godkjenningsidentifikatoren | Ingen godkjenningsdata eller handling blir tilgjengelig | | To workere sender samme operasjon | Høyst én reservasjon opprettes | | Leverandørens svar forsvinner | Status blir usikker; ingen ny operasjon konstrueres | Test grensen for innhenting separat: organisasjonsfiltrering før konteksten bygges, kontroll av kildetilgang, adskilte mellomlagre og sletting. Bruk deretter ende-til-ende-tester av agenten for å se om assistenten forklarer avslag, beholder oppgavens kontekst og stiller et konkret spørsmål når ny godkjenning trengs. Ta med en bevisst kappløpstest: Stans en worker etter reservasjon, trekk tilbake godkjenningen og la den fortsette. Forventet resultat følger den dokumenterte utsendingsgrensen. Tester av bare sekvensielle normalforløp ville oversett nettopp tidsrommet som gjør tilbakekalling vanskelig. Gjenta med et endret utkast og med en erstattet policyversjon. En ende-til-ende-test der modellen avviser en innskutt instruksjon, er nyttig dokumentasjon om akkurat den kjøringen. Den er ikke det samme som en håndhevet garanti. En direkte test av kontrollporten kan derimot vise at en bestemt forbudt operasjon avvises selv når modellen ber om den. Hold disse typene bevis adskilt i rapporteringen. Revisjonslogger bør knytte operasjonsidentifikatoren til autentisert aktør, beslutning, policyversjon, godkjenningsreferanse og utfall. De trenger ikke kopiere alle prompter eller private dokumenter. I eksemplet er et konsist beslutningsspor mer nyttig enn en ukritisk samtalelogg når man undersøker hvorfor revisjon 7 nådde testmiljøet. ## 9. Varighet uten arvet tillatelse En ny modellkjøring kan lese et gammelt notat og fortsette en arbeidsflyt. Kontinuiteten viser tilgang til lagrede opplysninger; den viser ikke uavbrutt utførelse, personlig identitet eller uavhengighet fra vertssystemet. Applikasjonen bør forklare hva den faktisk bevarer: dokumenter, oppføringer, legitimasjon, køer eller kjørende prosesser. Den foreslåtte modellen har kostnader. Finmaskede godkjenninger krever gjennomtenkte grensesnitt. Sterke garantier for tilbakekalling krever koordinering. Avgrensede adaptere må vedlikeholdes, og noen eksterne tjenester gir svak støtte for å avklare usikre effekter. Disse avveiningene bør være synlige, ikke skjult bak et løfte om autonom pålitelighet. I en liten applikasjon kan man begynne med én handling med reelle konsekvenser og definere hele tillatelsesgrensen. Dokumenter hva en gyldig fullmakt betyr, hvor den kontrolleres, når tilbakekalling trer i kraft og hvordan et usikkert utfall håndteres. Gjør minnet nyttig nok til å rekonstruere oppgaven, uten å gi det makt til å autorisere seg selv. I publiseringseksemplet kan assistenten huske utkastet, begrunnelsen og vedlikeholderens tidligere beslutning. Publiseringstjenesten stiller fortsatt det snevrere spørsmålet som betyr noe ved utførelsen: Får denne aktøren publisere dette innholdet til denne destinasjonen nå? ## Referanser Primærkildene ble kontrollert 19. oktober 2026. MCP-henvisningene gjelder uttrykkelig spesifikasjonen fra 2025-06-18 og beskrives ikke som siste utgave. Koden, skjemaene, testtilfellene og arkitekturdiagrammene er egne illustrative modeller og krever vurdering av den konkrete implementeringen før produksjonsbruk. 1. Anthropic Applied AI team. [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents). 29. september 2025. Kontekststyring, komprimering og varige notater. 2. Jerome H. Saltzer og Michael D. Schroeder. [The Protection of Information in Computer Systems: Basic Principles](https://web.mit.edu/Saltzer/www/publications/protection/Basic.html). Proceedings of the IEEE, 1975. Grunnleggende beskyttelsesprinsipper, tilgjengelig hos MIT. 3. Scott Rose, Oliver Borchert, Stu Mitchell og Sean Connelly. [Zero Trust Architecture, NIST SP 800-207](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf). August 2020. Komponenter for policybeslutning og håndheving, særlig del 3. 4. Model Context Protocol. [Architecture](https://modelcontextprotocol.io/specification/2025-06-18/architecture). Spesifikasjon fra 2025-06-18. Vertens ansvar og forhandling om protokollfunksjoner. 5. Torsten Lodderstedt, Justin Richer og Brian Campbell. [RFC 9396: OAuth 2.0 Rich Authorization Requests](https://www.rfc-editor.org/rfc/rfc9396.html). Mai 2023. Strukturerte og finmaskede autorisasjonsdetaljer. 6. Torsten Lodderstedt, John Bradley, Andrey Labunets og Daniel Fett. [RFC 9700: Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/rfc/rfc9700.html). Januar 2025. Begrensning av tokenprivilegier og tiltenkte mottakere, særlig del 2.3. 7. Model Context Protocol. [Authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization). Spesifikasjon fra 2025-06-18. HTTP-autorisasjon, validering av tiltenkt mottaker og separat legitimasjon mot underliggende tjenester.