Hoe geeft een geheime broker een AI-agent inloggegevens zonder ze in prompts bloot te stellen?
Een geheime broker houdt inloggegevens buiten prompts door de werklast van de agent te authenticeren en alleen aan de grens van het externe verzoek beperkte autorisatie toe te voegen.
Een AI-agent voor thuis moet mogelijk een agenda lezen of een back-up uploaden, maar als API-sleutels in de prompt, het geheugen, de omgeving of de tooluitvoer worden geplaatst, kunnen ze via injectie toegankelijk worden. Een broker verifieert de identiteit van de werklast en de goedgekeurde taakcontext, verkrijgt een kortstondige inloggegevens, voegt die toe binnen een gecontroleerde proxy of tooladapter en retourneert alleen het resultaat van de service.
De identiteit van de werklast vervangt het bezit van een statische sleutel
De agent bewijst welk goedgekeurd proces, welke container, welk serviceaccount of welke ondertekende werklast het verzoek uitvoert. De broker koppelt die identiteit aan beleid in plaats van te vertrouwen op een bearer-sleutel die is opgeslagen op een plek waar gegenereerde code of modelcontext erbij kan.
Een analyse van de identiteit van werklasten voor agents legt attestation en machine-to-machine-authenticatie uit voor agents die geen permanente inloggegevens zouden moeten bezitten. Dankzij het identiteitsbewijs kan autorisatie afhangen van de runtime-werklast in plaats van van beweringen in het gesprek. Dit onderscheid blijft zichtbaar tijdens latere tests in huis.
Identiteit alleen geeft geen toegang tot elke service. Beleid koppelt de werklast nog steeds aan gebruiker, bestemming, bewerking, scope van de resource en tijdvenster. Het tussenresultaat moet controleerbaar blijven voordat automatisering het opvolgt.
De broker geeft een beperkte, kortstondige inloggegevens uit of injecteert die
Na goedkeuring van het beleid wisselt de broker identiteit in voor een token met beperkte scope of haalt die een geheim op in beveiligd geheugen. Een proxy voegt de autorisatieheader toe aan het uitgaande verzoek nadat de door het model gegenereerde parameters zijn gevalideerd.
Beveiligingsrichtlijnen voor kortstondige inloggegevens via een broker adviseren om te beginnen zonder inloggegevens en een broker te gebruiken om kortstondige tokens voor de specifieke taak te leveren. Dit beperkt zowel de blootstellingsduur als de bewerkingen die na een inbreuk beschikbaar zijn. Die grens moet afzonderlijk worden gemeten onder realistische gebruiksomstandigheden.
Het model ziet een toolschema en een opgeschoond antwoord, niet het token. Ook logs, fouten, traces, opdrachtregels en nieuwe pogingen moeten autorisatiemateriaal verwijderen, anders verplaatst de architectuur het lek alleen maar. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen concurreren om beperkte context.
Beleid en intrekking beperken misbruik van inloggegevens
Toegestane bestemmingen, beperkingen voor methoden, resource-identificatoren, goedkeuring door de gebruiker, snelheidslimieten, audience-claims, verloopmomenten en tokens voor eenmalig gebruik beperken hoe de geïnjecteerde bevoegdheid kan worden gebruikt. De broker kan toekomstige uitgifte intrekken zonder prompts of images opnieuw op te bouwen.
Een uitleg van de grens voor injectie van inloggegevens stelt dat elk geheim dat de contextwindow binnenkomt uitlekbaar wordt en dat het beheer van inloggegevens buiten de agent moet plaatsvinden. Dit patroon vermindert het risico op openbaarmaking en behoudt gecontroleerde geauthenticeerde aanroepen. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.
De faalgrens ligt bij te ruim brokerbeleid of een proxy die willekeurige, door de agent gekozen verzoeken ondertekent. Verborgen inloggegevens voorkomen niet dat een via een prompt geïnjecteerde agent legitieme bevoegdheden misbruikt. Daarom moeten verzoeksemantiek en neveneffecten nog steeds worden gevalideerd.
Volg één inloggegeven van identiteit tot verloop
Documenteer voor elke agenttool de identiteit van de werklast, de aanvragende gebruiker, de bestemming, de toegestane bewerking, de scope van de resource, de goedkeuringsstatus, de audience van het token, de levensduur, het injectiepunt, het verwijderen van gevoelige gegevens uit antwoorden, de auditidentificatie, de intrekkingsroute en het fallbackgedrag. Het resultaat moet daarom worden gecontroleerd aan de hand van het oorspronkelijke bewijsmateriaal.
Vergelijk deze controle met machtigingen voor agenttools. Test promptverzoeken om geheimen, dumps van de omgeving, omgeleide bestemmingen, hergebruik na het verlopen, verruimde resource-ID's, foutlogging, nieuwe pogingen van tools en een gecompromitteerd sandboxproces. Dit onderscheid blijft zichtbaar tijdens latere tests in huis.
Sluit alleen af wanneer onbewerkte inloggegevens nooit modelzichtbare gegevens binnenkomen en ongeautoriseerde verzoekvarianten bij de broker of proxy mislukken. Houd tokens kortstondig, beleid taakgericht en logs opgeschoond, en plaats onomkeerbare bewerkingen achter afzonderlijk gebonden goedkeuring. Het tussenresultaat moet controleerbaar blijven voordat automatisering het opvolgt.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Welke invloed heeft downsampling van tijdreeksen op anomaliedetectie in een slimme woning?
Ontdek hoe bucketbreedte, aggregatie, anti-aliasing, ontbrekende gegevens, gebeurtenisduur en retentie op meerdere schalen de detectie van afwijkingen in slimme woningen beïnvloeden.
Hoe combineert een bezettingsraster zwakke signalen van een slim huis?
Leer hoe ruimtelijke cellen, sensormodellen, log-odds-updates, verval, gecorreleerd bewijs en drempelwaarden zwakke signalen uit huis omzetten in bezettingsschattingen.
Hoe beïnvloedt fotometrische normalisatie het clusteren van privégezichten?
Bekijk hoe verlichtingscorrectie gezichtscrops, embeddings, clust afstanden, drempelwaarden, overnormalisatie en de evaluatie van privéfotozoekopdrachten verandert.
