Ping Identity tar Runtime Identity till AWS, Google Cloud och Cloudflare för att säkra AI-agenter

När AI-agenter sprids i företagsmiljöer har en kritisk säkerhetslucka uppstått: traditionella identitetskontroller som bara sker vid inloggning är otillräckliga för agenter som agerar kontinuerligt och självständigt över molntjänster, API:er och kantinfrastruktur. Den 16 juni 2026 tillkännagav Ping Identity en uppsättning integrationer med Amazon Web Services (AWS), Google Cloud och Cloudflare för att täppa till denna lucka. Man utökar därmed sin Runtime Identity-tvingande funktion direkt in i plattformarna där agenter byggs, distribueras och opererar . Detta representerar en praktisk evolution från statisk autentisering till kontinuerlig, kontextmedveten auktorisering i ögonblicket för varje agenthandling.

Kärnskiftet: Från autentisering till runtime-auktorisering

Ping Identitys tillvägagångssätt bygger på en grundläggande insikt: AI-agenter är inte mänskliga användare, och de loggar inte bara in och slutar. De kedjar ihop API-anrop, använder verktyg och fattar beslut över distribuerade system. Denna verklighet kräver en säkerhetsmodell där identitet, delegering och policy kontrolleras kontinuerligt, vid runtime, för varje handling en agent utför .

För att möjliggöra detta behandlar Pings ramverk Identity for AI, som blev allmänt tillgängligt i mars 2026, AI-agenter som förstklassiga, icke-mänskliga identiteter. Ramverket erbjuder agentregistrering och livscykelhantering, OAuth 2.0-tokenutbyte för delegerad auktorisering samt centraliserad insyn i agenters aktivitet över olika miljöer .

Ny teknisk princip: delegering utan imitation

Centralt för alla tre integrationer är OAuth 2.0-tokenutbyte. När en mänsklig användare delegerar en uppgift till en agent imiterar agenten inte bara användaren med fullständiga rättigheter. Istället byter Pings infrastruktur den mänskliga användarens subjektstoken mot en ny, nedskalad token. Denna delegeringstoken bär med sig både den mänskliga användarens identitet (via act-fältet) och agentens egen identitet (via may_act-fältet), vilket skapar en säker ansvarskedja för varje efterföljande handling . Detta innebär att säkerhetsteam alltid kan svara på: vilken människa auktoriserade detta, vilken agent utförde handlingen, och vilka avgränsade rättigheter hade den?

AWS: Säkra agentidentiteter över molnarbetslaster

Ping Identitys integration med AWS är centrerad kring Amazon Bedrock AgentCore, den identitets- och behörighetshanteringstjänst som Amazon byggt specifikt för AI-agenter och automatiserade arbetslaster .

Hur det fungerar:

Pings identitetsleverantörer—PingOne, PingOne Advanced Identity Cloud och PingFederate—kan konfigureras på två sätt:

• Som en inbound-IdP för AgentCore Gateway och Runtime, som autentiserar slutanvändare och utfärdar avgränsade OAuth-token som agenter måste visa upp innan de når underliggande resurser .
• Som en outbound-behörighetsleverantör, vilket gör det möjligt för agenter att säkert hämta åtkomsttoken för tredjepartstjänster utan att exponera långlivade inloggningsuppgifter .

Praktiska funktioner:

• Unika agentidentiteter — Varje AI-agent får en distinkt identitet med associerad metadata. Administratörer kan tillämpa policyer för minsta möjliga behörighet över AWS-miljöer med flera konton .
• Styrning i realtid — Auktorisering tillämpas dynamiskt när agenter interagerar med API:er, verktyg och datalager, vilket anpassar agentbeteende efter företagspolicyer för känslig data, reglerade arbetslaster och operativa gränser .
• Övervakning — Amazon Bedrock AgentCore tillhandahåller in- och utgående autentiseringsloggar, medan Pings funktioner för agentdetektion gör det möjligt för organisationer att upptäcka, spåra och granska AI-agenter över sitt AWS-ekosystem .

Google Cloud: Inline-auktorisering för agent- och verktygstrafik

Integrationen med Google Cloud adresserar ett annat lager: trafiken mellan AI-agenter och de verktyg och MCP-servrar de anropar. Ping Identity integreras med Google Cloud Agent Gateway, en hanterad kontrollpunkt som fångar upp förfrågningar mellan agenter och verktyg och verkställer policy innan förfrågan når sin destination .

Hur det fungerar:

PingOne Authorize placeras inline i Agent Gateways trafikflöde via en ext_proc-integration. Varje förfrågan från en agent till en MCP-server eller ett verktyg utlöser en policyutvärdering i realtid: vem är den representerade användaren, vilken agent agerar, vilken resurs nås, och vilken handling försöker man utföra .

Praktiska funktioner:

• Kontinuerlig inline-auktorisering — Om en policy tillåter förfrågan släpps den igenom. Nekas den, blockeras förfrågan innan den når verktyget eller API:n. Ingen applikationskod behöver ändras .
• Finkorniga, avgränsade verktygspolicyer — Säkerhetsteam kan tillämpa kontextmedvetna regler som "vilken anställd som helst kan köpa en vara för 100 kr, men endast en chef kan godkänna ett inköp på 100 000 kr" utan att modifiera applikationen eller själva MCP-servern .
• Centraliserad policyhantering — Auktoriseringslogiken externaliseras från individuella MCP-servrar och agentimplementationer, vilket gör regler enklare att underhålla, granska och uppdatera i takt med att agentarkitekturer skalas upp .
• Fullständig observerbarhet — Agent Gateways loggar och spårnings-ID:n kombineras med Pings Runtime Identity-modell för att ge full spårbarhet: vilken användare delegerade, vilken agent anropade, vilket verktyg kördes, och vilken policy som tillät eller blockerade handlingen .

Cloudflare: Zero Trust-kontroll vid kanten

För organisationer som distribuerar AI-agenter över globalt distribuerad infrastruktur för Ping Identitys integration med Cloudflare identitetskontrollen ända ut till nätverkskanten. Cloudflares globala nätverk, som spänner över fler än 220 städer med GPU-drivna inferensnoder, opererar utanför den traditionella företagsperimetern .

Hur det fungerar:

Cloudflare Workers Model Context Protocol (MCP)-server fungerar som en OAuth-resursserver. Den delegerar autentisering till Pings identitetsleverantörer—PingOne DaVinci, PingOne Advanced Identity Cloud eller PingFederate—för att validera agenter innan de kan komma åt underliggande API:er .

Praktiska funktioner:

• Starka, avgränsade inloggningsuppgifter vid kanten — AI-agenter autentiserar sig via Cloudflare Workers OAuth Provider för att erhålla avgränsade token innan de anropar ett skyddat API. Oregistrerade eller oautentiserade MCP-klienter blockeras från att ansluta .
• Zero Trust-policy-tillämpning — Ping och Cloudflare tillämpar Zero Trust-policyer på all AI-agenttrafik som kommer åt modeller och företagsdata globalt, snarare än att förlita sig på en företagsperimeter som inte existerar i kantmiljöer .
• Granskning och insyn — Agentaktivitet över distribuerad kantinfrastruktur loggas och är granskningsbar, vilket ger säkerhetsteam insyn i vad varje agent kom åt, när, och med vems delegerade auktoritet .

Varför tre plattformar, och varför nu

De tre integrationerna är inte överflödiga—de adresserar distinkta arkitektoniska lager: AWS för molnarbetslasters identitet, Google Cloud för inline-trafikkontroll och Cloudflare för tillämpning vid kanten. Alla tre är byggda på den gemensamma Identity for AI-grunden, vilket innebär att organisationer kan tillämpa konsekvent auktoriseringslogik, tokenutbytesmönster och policyramverk oavsett var deras agenter körs .

Tidpunkten speglar en marknadsrealitet: företag distribuerar AI-agenter snabbare än vad säkerhetsteam kan anpassa traditionella identitetsverktyg. Integrationerna gör det möjligt för företag att centralisera auktorisering och policy-tillämpning istället för att bädda in fragmenterade kontroller i individuella agenter och API:er .

För säkerhetsarkitekter som arbetar med agentiska AI-distributioner är den praktiska frågan inte längre "är agenten autentiserad?" utan "i detta ögonblick, med denna kontext, är just denna handling auktoriserad?" Dessa integrationer gör den frågan besvarbar i realtid, i stor skala, över de plattformar där agenter faktiskt lever.