Hur ger en hemlig förmedlare en AI-agent autentiseringsuppgifter utan att exponera dem i instruktionerna?
En hemlig förmedlare håller autentiseringsuppgifter borta från prompter genom att autentisera agentens arbetsbelastning och endast injicera begränsad behörighet vid gränsen för externa förfrågningar.
En AI-agent i hemmet kan behöva läsa en kalender eller ladda upp en säkerhetskopia, men om API-nycklar placeras i dess prompt, minne, miljö eller verktygsutdata kan de nås genom injicering. En förmedlare verifierar arbetsbelastningens identitet och godkänd uppgiftskontext, hämtar en kortlivad autentiseringsuppgift, bifogar den i en kontrollerad proxy eller verktygsadapter och returnerar endast tjänstens resultat.
Arbetsbelastningens identitet ersätter innehav av en statisk nyckel
Agenten bevisar vilken godkänd process, container, tjänstekonto eller signerad arbetsbelastning som gör förfrågan. Förmedlaren kopplar identiteten till policyer i stället för att lita på en bäraresnyckel som lagras där genererad kod eller modellkontext kan läsa den.
En analys av arbetsbelastningsidentitet för agenter förklarar attestering och maskin-till-maskin-autentisering för agenter som inte bör ha permanenta autentiseringsuppgifter. Identitetsbeviset gör att auktorisering kan baseras på arbetsbelastningen vid körning i stället för på påståenden i konversationen. Denna skillnad förblir synlig under senare tester i hemmet.
Identitet ger inte ensam åtkomst till alla tjänster. Policyn kopplar fortfarande arbetsbelastningen till användare, destination, åtgärd, resursomfattning och tidsfönster. Mellanresultatet måste förbli granskningsbart innan automatiseringen fortsätter.
Förmedlaren utfärdar eller injicerar en snäv, kortlivad autentiseringsuppgift
Efter policygodkännande byter förmedlaren identiteten mot en begränsad token eller hämtar en hemlighet i skyddat minne. En proxy lägger till auktoriseringshuvudet i den utgående förfrågan efter att de modellgenererade parametrarna har validerats.
Säkerhetsvägledning för kortlivade autentiseringsuppgifter via en förmedlare rekommenderar att börja utan autentiseringsuppgifter och använda en förmedlare som tillhandahåller kortlivade token för den specifika uppgiften. Detta begränsar både exponeringstiden och vilka åtgärder som är tillgängliga efter en kompromettering. Denna gräns bör mätas separat under realistiska driftförhållanden.
Modellen ser ett verktygsschema och ett sanerat svar, inte token. Loggar, fel, spårningar, kommandorader och återförsök måste också maskera auktoriseringsmaterial, annars flyttar arkitekturen bara läckan. Den praktiska konsekvensen blir tydlig när flera källor konkurrerar om ett begränsat kontextutrymme.
Policy och återkallande begränsar missbruk av autentiseringsuppgifter
Listor över tillåtna destinationer, metodbegränsningar, resursidentifierare, användargodkännande, hastighetsbegränsningar, målgruppsanspråk, giltighetstid och engångstoken begränsar hur den injicerade behörigheten kan användas. Förmedlaren kan återkalla framtida utfärdanden utan att bygga om prompter eller avbildningar.
En förklaring av gränsen för injicering av autentiseringsuppgifter hävdar att varje hemlighet som kommer in i kontextfönstret kan exponeras och placerar hanteringen av autentiseringsuppgifter utanför agenten. Mönstret minskar risken för utlämnande samtidigt som kontrollerade autentiserade anrop bevaras. Detta beroende bör förbli tydligt i det slutliga gränssnittet.
Felgränsen är en alltför bred förmedlarpolicy eller proxy som signerar godtyckliga förfrågningar valda av agenten. Dolda autentiseringsuppgifter hindrar inte en promptinjicerad agent från att missbruka legitim behörighet, så förfrågningarnas semantik och bieffekter behöver fortfarande valideras.
Följ en autentiseringsuppgift från identitet till utgång
För varje agentverktyg ska du dokumentera arbetsbelastningens identitet, begärande användare, destination, tillåten åtgärd, resursomfattning, godkännandestatus, tokenmålgrupp, livslängd, injiceringspunkt, maskering av svar, granskningsidentifierare, återkallningsväg och reservbeteende. Resultatet måste därför kontrolleras mot det ursprungliga underlaget.
Jämför kontrollen med behörigheter för agentverktyg. Testa promptförfrågningar efter hemligheter, dumpningar av miljön, omdirigerade destinationer, återanvändning efter att giltighetstiden löpt ut, utökade resursidentifierare, felloggning, återförsök med verktyg och en komprometterad sandboxprocess. Denna skillnad förblir synlig under senare tester i hemmet.
Godkänn endast när råa autentiseringsuppgifter aldrig kommer in i data som är synliga för modellen och obehöriga varianter av förfrågningar stoppas vid förmedlaren eller proxyn. Håll token kortlivade, policyerna uppgiftsspecifika och loggarna maskerade, och placera oåterkalleliga åtgärder bakom ett separat bundet godkännande. Mellanresultatet måste förbli granskningsbart innan automatiseringen fortsätter.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Vad är embeddingdrift, och när behöver ett privat sökindex byggas om?
Avkoda modell-, förbehandlings-, korpus- och frågeförskjutning; skilj övervakning från inkompatibilitet och avgör när ett privat index behöver byggas om.
Vad är tokeniseringskompatibilitet, och varför kan den göra att modellbyte slutar fungera?
Avkoda ordförrådsidentitet, semantik för specialtoken, chattmallar, cachade token, adaptrar och kompatibilitetskontroller för lokal modellväxling.
Vad är modellresidens, och när bör en lokal AI-tjänst ha vikterna inlästa?
Förstå viktpersistens, cachenivåer, kalla starter, utfasning, multiplexering, minnesbelastning och när en AI-tjänst i hemmet bör hållas varm.
