Villkorlig åtkomst för agenter

Villkorsstyrd åtkomst för agenter är ett tillägg till principmotorn för villkorsstyrd åtkomst som styr hur agenter får åtkomst till resurser som skyddas av Microsoft Entra ID. Den samlar realtidssignaler som användarens och agentens kontext, enhet, plats och riskinformation för att avgöra när åtkomsten ska tillåtas, blockeras eller begränsas eller fler verifieringssteg krävs.

Genom att förstå agentens åtkomstmönster kan du rikta in dig på rätt identitet. En agent kan agera för en inloggad användares räkning, använda sin egen agentidentitet eller använda sitt eget agentanvändarkonto.

Läs mer om villkorsstyrd åtkomst för agenter:

Krav och licensiering

Microsoft Entra ID villkorlig åtkomst för agenter kräver något av följande licensplaner:

  • Microsoft 365 E7, som innehåller Agent 365 och Microsoft Entra-sviten.
  • Microsoft Agent 365-licens i kombination med minst Microsoft Entra P1 eller Microsoft 365 E3.

Mer information finns i Microsoft Agent 365-abonnemang och priser.

Så utvärderar villkorsstyrd åtkomst agentåtkomst

För att få åtkomst till en resurs, till exempel en SharePoint-fil, MCP-server eller Open API-tjänst, begär en användare eller agent en åtkomsttoken från Microsoft Entra ID.

När en princip för villkorsstyrd åtkomst tillämpas utvärderar Microsoft Entra ID principkraven innan den utfärdar token. Om kraven uppfylls utfärdar Microsoft Entra ID tokenen. Målresursen validerar token och använder sina anspråk för att fatta auktoriseringsbeslut.

Diagram som visar dataåtkomstmönster för agentidentiteter.

Varje åtkomsttoken har ett ämne och en målgrupp:

  • Ämne: Identiteten som tar emot token.
    • I delegerad åtkomst representerar token användaren samtidigt som den identifierar det anropande programmet eller agenten.
    • Vid åtkomst med endast program är agentens identitet subjektet.
    • Vid agentanvändaråtkomst är agentens användarkonto subjektet.
  • Målgrupp: Målresursen som token är för, som måste registreras i Entra ID. Om ett ämne har åtkomst till flera resurser behöver det vanligtvis en separat token för varje resurs.

Villkorlig åtkomst utvärderar både det ämne som begär åtkomst och målgruppen som nås. Den utvärderar principer när Microsoft Entra ID utfärdar eller förnyar en åtkomsttoken. Vissa resurser stöder också kontinuerlig åtkomstutvärdering, vilket kan framtvinga tillämpning nästan i realtid vid specifika händelser.

Hur beslut om villkorsstyrd åtkomst fattas

Principer för villkorsstyrd åtkomst fungerar som if-then-instruktioner:

  • Om villkoren som definieras i en princip uppfylls tillämpas de konfigurerade åtkomstkontrollerna.
  • Om de nödvändiga kontrollerna är uppfyllda beviljas åtkomst.
  • Om de nödvändiga kontrollerna inte uppfylls nekas åtkomst.

En organisation kan till exempel kräva multifaktorautentisering innan en användare kan ge en agent åtkomst till sin e-post. På samma sätt kan en organisation konfigurera en princip för att blockera åtkomst från agenter som identifierats som högriskagenter.

När villkorlig åtkomst utvärderas

Villkorlig åtkomst utvärderas varje gång Microsoft Entra ID utfärdar eller förnyar en åtkomsttoken. Vissa resurser stöder också kontinuerlig åtkomstutvärdering, vilket kan framtvinga tillämpning nästan i realtid vid specifika händelser.

Agentåtkomstmönster

Agenter kan komma åt Microsoft Entra-skyddade resurser med något av följande mönster:

Om agenten Åtkomstmönster Principmål Guidance
Åtkomst till underordnade resurser för en inloggad användare Å OBO:s vägnar, även kallat delegerad åtkomst Användare och grupper Agentens OAuth-flöden: för annans räkning
Får åtkomst till resurser med en egen agentidentitet och ingen inloggad användare Endast programautentisering, även kallat klientautentiseringsuppgifter eller åtkomst enbart för appen Agentidentitet eller ritning för agentidentitet Skydda autonoma agenter med villkorsstyrd åtkomst
Åtkomst till resurser via ett eget användarkonto Agentanvändaråtkomst Agentens användarkonto Säkra agenter som fungerar som användare med villkorsstyrd åtkomst

En agent kan använda mer än ett åtkomstmönster. Skapa separata principer för varje tokenämne som agenten använder. En princip som riktar sig mot en agentidentitet gäller inte för agentens användarkonto och en princip som riktar sig mot agentens användarkonto gäller inte för agentidentiteten.

Agenter som agerar för en användares räkning

Det vanligaste åtkomstmönstret är OBO-flödet (on-behalf-of). I OBO-flödet loggar en användare in på ett agentprogram. Agenten kommer åt underordnade resurser med användarens identitet och delegerade behörigheter. När en agent till exempel läser dina e-postmeddelanden får den åtkomst till din postlåda på dina vägnar. Mer information om hur OBO-flödet fungerar för agenter finns i Agent OAuth flows: On-behalf-of.

Anmärkning

Ombudsflödet kallas även delegerad åtkomst. "On-behalf-of" beskriver autentiseringsflödet, inte agenttypen. Dessa interaktiva agenter omfattar ett användargränssnitt för mänsklig interaktion. Alla agenter kan använda det här flödet när en inloggad användare finns och agenten måste komma åt resurser med användarens identitet och behörigheter.

I det här flödet kan agenten inte återanvända användarens ursprungliga token eftersom den utfärdades för en annan målgrupp. I stället använder agenten OBO-flödet för att utväxla token med Microsoft Entra ID och hämta en ny token som är begränsad till målresursen. Det här tokenutbytet utvärderas också av villkorsstyrd åtkomst, så att administratörer kan tillämpa detaljerade kontroller över vilka resursagenter som kan komma åt för användarens räkning.

Eftersom den inloggade användaren är subjektet för tokenen i det här flödet utvärderar Villkorlig åtkomst principer som tilldelats användaren, oavsett om användaren riktas direkt, via en grupp eller via en annan användarinriktningsmekanism som stöds. Att välja en agentidentitet som principsubjekt omfattar inte agentbegäranden som görs för användarens räkning.

Agenter som fungerar som program

Agenter kan komma åt resurser utan en inloggad användare. I det här fallet kommer agenten åt resursen med sin egen identitet. Det här flödet kallas även för flöde för klientautentiseringsuppgifter eller endast åtkomst till appar. Alla typer av agenter kan använda det här flödet. Mer information om hur agenter autentiserar med sin egen identitet finns i Agent OAuth-flöden: Autonoma appar.

Det här flödet gäller i följande vanliga scenarier:

  • Autonoma agenter som arbetar självständigt körs i bakgrunden, svarar på händelser eller körs enligt ett schema.
    • Till exempel en agent som genererar en daglig rapport och skickar resultatet till en grupp anställda.
    • I det här scenariot finns det ingen användare närvarande och agenten fungerar på egen hand.
  • Interaktiva agenter som använder sin egen identitet har inte alltid åtkomst till resurser för en användares räkning. ibland använder de sin egen identitet.
    • Om en agent till exempel anropar en SMS-tjänst i backend som användarna inte har åtkomst till, gäller inte OBO-flödet, och agenten autentiserar direkt som sig själv.
  • Agenter som publiceras på webben för offentligt bruk autentiserar inte användaren eller stöder inte delegering av användarens kontext till företagsresurser.

I dessa scenarier begär agenten en åtkomsttoken med sin egen agentidentitet och autentiseringsuppgifter som hanteras via agentidentitetsritningen. Token utfärdas till agentidentiteten (inte användaren). Därför begränsas principer för villkorsstyrd åtkomst till agentidentiteten i stället för användaren. Stegvis principkonfiguration finns i Skydda autonoma agenter med villkorsstyrd åtkomst.

Agenter som fungerar som användare

Ibland räcker det inte att en agent utför uppgifter åt en användare eller arbetar med sin egen identitet. I vissa scenarier har en agent sin egen agents användarkonto som fungerar som en digital arbetare med en egen postlåda, åtkomst till chatt och möjligheten att delta i samarbetsarbetsflöden som gruppmedlem.

I den här modellen skapar en administratör ett användarkonto i katalogen och länkar det till agentens identitet. Därifrån är det som alla andra användarkonton. Licenser kan tilldelas för åtkomst Microsoft 365 resurser, till exempel en postlåda och kalender. Kontot kan läggas till i administrativa enheter och säkerhetsgrupper precis som ett mänskligt användarkonto.

Agenter som använder det här flödet betraktas också som autonoma agenter eftersom de inte innehåller något användargränssnitt för mänsklig interaktion. I den här modellen utfärdas åtkomsttoken till agentens användarkonto (tokenämnet) och principen utvärderas mot agentens användarkonto, inte agentidentiteten. Stegvis principkonfiguration finns i Villkorsstyrd åtkomst för autonoma agenter. Mer information om agentanvändarens OAuth-flöde finns i OAuth-flöde för agentanvändare.

Agenter som körs på hanterade slutpunkter som Windows 365 Molndatorer för agenter kan också omfattas av enhetsefterlevnad och kompatibla nätverkskontroller. Använd villkoret Agentkörningsmiljöer (förhandsversion) för att begränsa dessa principer till endast slutpunktsbaserade sessioner. Mer information finns i Kräv en kompatibel enhet för agenternas användarkonton.

Principer för villkorlig åtkomst och agentidentitetsritningar

Förutom de specifika agentåtkomstmönstren kan du även välja agentidentitetsritningar för att tillämpa principer för villkorsstyrd åtkomst på en klass med agenter. En agentidentitetsritning definierar konfigurations- och styrningsmodellen för agentidentiteter som skapats från den. En princip som riktar sig mot en skiss gäller för alla agentidentiteter som skapats från den skissen, inklusive agentidentiteter som skapats senare.

Följande diagram visar att endast agentidentiteter som är associerade med skissen "A" beviljas åtkomst. alla andra agenter exkluderas och blockeras.

Diagram som visar en princip för villkorsstyrd åtkomst som tillämpas på agentidentiteter från en skiss.

Tänk dig till exempel ett projekt där du har flera agenter, var och en med sitt eget syfte. Vissa arbetar självständigt, medan andra samarbetar med andra agenter (A2A) för att slutföra uppgifter. Om de alla skapas under samma mall tillämpas en enda policy på den mallen för att säkerställa konsekventa åtkomstkontroller i hela samlingen.

Attributdriven villkorlig åtkomst

I takt med att antalet agentidentiteter ökar blir det ohållbart att hantera var och en för sig i alla policyer. Med anpassade säkerhetsattribut kan du kategorisera agentidentiteter och resurser med affärsspecifika etiketter och sedan rikta in dig på attributen i principer för villkorsstyrd åtkomst. Principer gäller automatiskt för varje agent med matchande attribut, inklusive de som läggs till i framtiden.

Diagram som visar flödet för villkorsstyrd åtkomst för agentidentiteter.

Ett principexempel finns i Tillåt godkända agenter med hjälp av anpassade säkerhetsattribut.

Gränser och begränsningar

Principer för villkorsstyrd åtkomst gäller inte när:

  • En agentidentitetsritning hämtar en token för Microsoft Graph för att skapa en agentidentitet eller agentens användarkonto.
    • Agentritningar har begränsade funktioner. De kan inte agera oberoende för att få åtkomst till resurser och är bara involverade i att skapa agentidentiteter och agenters användarkonton.
    • Agentuppgifter utförs alltid med agentens identitet.
  • En agentidentitetsritning eller agentidentitet utför ett mellanliggande tokenutbyte vid slutpunkten AAD Token Exchange Endpoint: Public (resurs-ID: fb60f99c-7a34-4190-8149-302f77469936).
    • Token som är begränsade till AAD Token Exchange Endpoint: Public kan inte anropa Microsoft Graph.
    • Agentflöden skyddas eftersom villkorlig åtkomst skyddar tokenförvärv från agentidentiteten eller agentens användarkonto.
  • Standardinställningar för säkerhet är aktiverade.
  • Villkorlig åtkomst skyddar endast resurser som skyddas av Microsoft Entra ID. Om en agent till exempel kommer åt resurser med hjälp av en API-nyckel kringgås pipelinen för Microsoft Entra ID autentisering och tokenutfärdning helt och hållet och principer för villkorsstyrd åtkomst gäller inte för dem.

Följande konfigurationer stöds inte för närvarande:

  • Policyer som omfattas via tilldelningen "Användare" gäller inte för agentanvändarkonton. Den här gränsen gäller om principen riktar sig till alla användare, valda användare, grupper, katalogroller eller externa användare. För att skydda agentanvändarkonton skapar du en policy som riktar sig till "Agentanvändare".
  • Ange omfång för en princip för villkorsstyrd åtkomst för att inkludera eller exkludera agentens användarkonto baserat på deras gruppmedlemskap.
  • En princip för villkorsstyrd åtkomst som riktar sig till agentidentiteter gäller inte för agentens användarkonto.
  • En princip för villkorsstyrd åtkomst som riktar sig till agentidentiteter med hjälp av agentidentitetsritningen omfattar endast agentidentiteten, inte agentens användarkonto.

Om du i stället vill begränsa principer till agentanvändare, under Tilldelningar>Användare, agenter eller arbetsbelastningsidentiteter, väljer du Agenter och riktar sedan in dig på alla agentanvändare eller specifika agentanvändare.