Villkorlig åtkomst för agenter

Villkorlig åtkomst är en intelligent principmotor som hjälper organisationer att styra hur användare och agenter får åtkomst till företagsresurser. Den samlar realtidssignaler som användarens och agentens kontext, enhet, plats och sessionsriskinformation för att avgöra när åtkomsten ska tillåtas, blockeras eller begränsas eller fler verifieringssteg krävs.

Villkorsstyrd åtkomst för agenter kräver Microsoft Entra ID P1 eller P2 och en Microsoft Agent 365-licens för varje användare. Tillämpning av Agent 365-licensiering kommer snart. Nätverkskontroller för agenter kräver Microsoft Entra internetåtkomst. Mer information finns i Vad är Microsoft Entra agent-ID.

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

Så utvärderar villkorsstyrd åtkomst begäranden om agentåtkomst

För att få åtkomst till en företagsresurs, till exempel SharePoint fil, MCP-servrar eller Öppna API-tjänster, begär en användare eller agent först en åtkomsttoken från Microsoft Entra ID.

När en princip för villkorsstyrd åtkomst tillämpas utvärderar Microsoft Entra ID de konfigurerade principkraven innan token utfärdas. Om kraven uppfylls utfärdas en åtkomsttoken. Token visas sedan för målresursen, som validerar token och använder sina anspråk för att fatta auktoriseringsbeslut.

Följande diagram illustrerar den här processen.

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

Hur ämnen och målgrupper används

Microsoft Entra ID utfärdar en åtkomsttoken till ett ämne för en specifik målgrupp (resurs). Varje åtkomsttoken har exakt ett ämne och en målgrupp.

Ämne: Den identitet som tar emot token.

  • I scenarier med delegerad åtkomst representerar token användaren samtidigt som den identifierar det anropande programmet eller agenten.
  • I scenarier med endast program är programmet eller den autonoma agenten ämnet.
  • I agentens användarkontoscenarier är agentens användarkonto ämnet.

Målgrupp: Målresursen som token är avsedd för.

  • Resursen måste vara registrerad i Microsoft Entra ID.
  • Om ett ämne behöver åtkomst till flera resurser (till exempel flera MCP-servrar eller API:er) kräver det vanligtvis en separat åtkomsttoken för varje resurs, var och en med sin egen målgrupp och behörighet.

Principer för villkorsstyrd åtkomst utvärderas baserat på både det ämne som begär åtkomst och målgruppen som används.

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:

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

Det vanligaste åtkomstmönstret är OBO-flödet (on-behalf-of). I det här flödet loggar en användare in på ett agentprogram och agenten får åtkomst till underordnade resurser med hjälp av 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 användaren är ämnet i det här flödet riktar sig principer för villkorsstyrd åtkomst till användare och grupper, inte agentidentiteter.

Agenter som fungerar som ett 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 Villkorsstyrd åtkomst för autonoma agenter.

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. Varje agentidentitet härleds från en agentidentitetsritning, som definierar dess konfigurations- och styrningsmodell. Att tillämpa en princip på skissnivå omfattar automatiskt alla agentidentiteter som härleds från den, inklusive eventuella nya som läggs till i framtiden. Att inrikta sig på blueprinten för agentidentitet omfattar inte agenternas användarkonton.

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

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

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.

En fullständig genomgång av hur du skapar anpassade säkerhetsattribut och använder dem i en princip för villkorlig åtkomst finns i Villkorlig åtkomst för autonoma agenter.

Gränser och begränsningar för villkorlig åtkomst

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:

  • Principer som riktar sig till alla användare inkluderar inte agentens användarkonton.
  • 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.

Nästa steg