Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Het bouwen van beveiligde AI-agents is een gedeelde verantwoordelijkheid tussen Agent Framework en toepassingsontwikkelaars. Agent Framework biedt de bouwstenen ( abstracties, providers en indeling), maar ontwikkelaars zijn verantwoordelijk voor het valideren van invoer, het beveiligen van gegevensstromen en het configureren van hulpprogramma's die geschikt zijn voor hun scenario.
In dit artikel vindt u een overzicht van aanbevolen procedures voor het bouwen van veilige en beveiligde agents met Agent Framework.
Vertrouwensgrenzen begrijpen
Gegevens stromen door verschillende onderdelen wanneer een agent wordt uitgevoerd: gebruikersinvoer, chatgeschiedenisproviders, contextproviders, de LLM-service en functiehulpprogramma's. Elke grens waar gegevens uw toepassing binnenkomen of verlaten, vertegenwoordigt een potentieel kwetsbaarheid voor aanvallen.
Belangrijke vertrouwensgrenzen om rekening mee te houden:
- AI-service : ontvangt chatberichten (waaronder PII en systeeminstructies) en retourneert door LLM gegenereerde uitvoer.
- Chatgeschiedenisopslag : providers kunnen gespreksberichten laden en behouden via externe opslag.
- Contextservices : contextproviders kunnen gegevens ophalen of opslaan uit externe services (herinneringen, gebruikersprofielen, RAG-resultaten).
- Services geopend door tools — Functie-tools voeren door ontwikkelaars geleverde code uit die externe API's of databases kan aanroepen.
Alle externe servicecommunicatie wordt verwerkt door door ontwikkelaars gekozen client-SDK's. Agent Framework beheert geen verificatie-, versleutelings- of verbindingsgegevens voor deze services.
Beste praktijken
Functie-invoer valideren
De AI kan elke functie aanroepen die u als hulpmiddel opgeeft en de argumenten kiezen. Behandelt door LLM geleverde argumenten als niet-vertrouwde invoer, vergelijkbaar met gebruikersinvoer in een web-API.
-
Gebruik allow-listing : valideer invoer op basis van bekende goede waarden in plaats van bekende-slechte patronen te filteren. Controleer bijvoorbeeld of een bestandspad zich in een toegestane map bevindt in plaats van te controleren op
..doorkruisingsreeksen. - Type- en bereikbeperkingen afdwingen : controleer of argumenten van het verwachte type en binnen acceptabele bereiken (numerieke grenzen, tekenreekslengtelimieten, datumbereiken) zijn.
- Lengte van tekenreeksen beperken : maximale lengtes afdwingen voor tekenreeksargumenten om uitputting van resources of injectieaanvallen te voorkomen.
- Padkruising voorkomen : wanneer functies bestandspaden accepteren, kunt u deze omzetten in absolute paden en controleren of ze binnen toegestane mappen vallen.
- Gebruik geparameteriseerde query's ( als argumenten worden gebruikt in SQL-query's, shell-opdrachten of andere geïnterpreteerde contexten), gebruikt u geparameteriseerde query's of escapen, nooit tekenreekssamenvoeging.
Goedkeuring vereisen voor hulpprogramma's met een hoog risico
Standaard worden alle hulpprogramma's die aan een agent worden geleverd, aangeroepen zonder goedkeuring van de gebruiker. Gebruik het goedkeuringsmechanisme voor hulpmiddelen om bewerkingen met een hoog risico achter menselijke bevestiging te plaatsen.
Overweeg bij het bepalen welke hulpprogramma's goedkeuring vereisen:
- Neveneffecten : hulpmiddelen voor het wijzigen van gegevens, het verzenden van communicatie, het doen van aankopen of het hebben van andere bijwerkingen, moeten over het algemeen goedkeuring vereisen.
- Vertrouwelijkheid van gegevens : hulpprogramma's die toegang hebben tot gevoelige gegevens (PII, financiële gegevens, referenties) rechtvaardigen goedkeuring.
- Reversibiliteit — Onherstelbare operaties (verwijderen, versturen van e-mails) vormen een groter risico dan alleen-lezenquery's.
- Omvang van de impact : Tools met brede impact (bulkbewerkingen) moeten meer toezicht vereisen dan die met een beperkte reikwijdte.
Systeemberichten door ontwikkelaars beheerd houden
Chatberichten hebben een rol (system, user, assistant, tool) die bepaalt hoe de AI-service deze interpreteert. Inzicht in deze rollen is essentieel:
| Rol | Vertrouwensniveau |
|---|---|
system |
Hoogste vertrouwen — rechtstreeks het gedrag van LLM vormgeven. Mag nooit niet-vertrouwde invoer bevatten. |
user |
Niet-vertrouwd : kan promptinjectiepogingen of schadelijke inhoud bevatten. |
assistant |
Niet-vertrouwd : gegenereerd door de LLM, een extern systeem. |
tool |
Niet-vertrouwd : kan gegevens van externe systemen of door de gebruiker beïnvloede inhoud bevatten. |
Plaats geen invoer van eindgebruikers in system-role messages. Agent Framework wijst standaard niet-getypte tekst toe aan de user rol, maar wees voorzichtig bij het programmatiche maken van berichten.
Providers van software-uitbreidingen
Contextproviders en geschiedenisproviders kunnen berichten injecteren met elke rol, waaronder system. Verbind alleen vertrouwde providers.
Houd rekening met indirecte promptinjectie: als de onderliggende gegevensrepository is aangetast, kan kwaadwillende inhoud het gedrag van LLM beïnvloeden. Een document dat via RAG wordt opgehaald, kan bijvoorbeeld verborgen instructies bevatten waardoor de LLM afwijkt van het beoogde gedrag of gegevens exfiltreert via hulpprogrammaaanroepen.
LLM-uitvoer valideren en opschonen
LLM-antwoorden moeten worden behandeld als niet-vertrouwde uitvoer. De AI-service is een extern eindpunt dat Agent Framework niet bepaalt. Let op:
- Hallucinatie — LLM's kunnen plausibel klinkende maar feitelijk onjuiste informatie genereren. Behandel LLM-uitvoer niet als gezaghebbend zonder verificatie.
- Indirecte promptinjectie: gegevens die zijn opgehaald door hulpprogramma's, contextproviders of chatgeschiedenisproviders, kunnen tegenwerkende inhoud bevatten die is ontworpen om de LLM te beïnvloeden.
- Schadelijke nettoladingen : LLM-uitvoer kan inhoud bevatten die schadelijk is als deze wordt weergegeven of uitgevoerd zonder opschoning (HTML/JavaScript voor XSS, SQL voor injectie, shell-opdrachten).
Valideer en schoon de LLM-uitvoer altijd op voordat deze in HTML wordt weergegeven, voer deze uit als code, gebruik deze in databasequery's of geef deze door aan een beveiligingsgevoelige context.
Gevoelige gegevens in logboeken beveiligen
Agent Framework ondersteunt logboekregistratie en telemetrie via OpenTelemetry. Gevoelige gegevens worden alleen geregistreerd wanneer deze expliciet zijn ingeschakeld:
-
Logboekregistratie : op logboekniveau
Tracewordt de volledigeChatMessagesverzameling vastgelegd. Dit kan PII bevatten.Traceniveau mag nooit worden gebruikt in een productieomgeving. -
Telemetrie : wanneer
EnableSensitiveDatadeze is ingesteld, bevat telemetrie de volledige tekst van chatberichten, inclusief functie-aanroepen en resultaten. Schakel dit niet in in de live-omgeving.
Sessiegegevens beveiligen
Sessies (AgentSession) vertegenwoordigen gesprekscontext en kunnen worden geserialiseerd voor persistentie. Geserialiseerde sessies behandelen als gevoelige gegevens:
- Sessies kunnen verwijzen naar gespreksinhoud of sessie-id's.
- Het herstellen van een sessie van een niet-vertrouwde bron is gelijk aan het accepteren van niet-vertrouwde invoer. Een gecompromitteerde opslagback-end kan rollen wijzigen om het vertrouwen te vergroten.
- Sla sessies op in veilige opslag met de juiste toegangscontroles en encryptie.
Resourcelimieten implementeren
Agent Framework legt geen beperkingen op voor de lengte van invoer/uitvoer of aanvraagsnelheden, omdat het niet weet wat redelijk is voor uw scenario. U bent verantwoordelijk voor:
- Limieten voor invoerlengte : invoerlengte beperken om contextoverloop of DoS-aanvallen te voorkomen.
-
Limieten voor uitvoerlengten : gebruik door de service geleverde limieten (bijvoorbeeld
MaxOutputTokensin chatopties). - Snelheidsbegrenzing — gebruik hulpmiddelen om kostenoverschrijdingen en misbruik van gelijktijdige aanvragen te voorkomen.