jsonscraper

Apollo lanserer GraphOS Agent Services: Tilgang for KI-agenter kan begrenses på feltnivå

Tjenesten styrer tillatelser til bedriftsdata og logger hvordan reglene håndheves. Tilgang til forhåndsversjonen ordnes gjennom Apollo.

7. oktober 2026 lanserte Apollo GraphQL GraphOS Agent Services i en forhåndsversjon som styrer KI-agenters tilgang til bedriftens API-er. Administratorer kan tillate, maskere eller blokkere enkeltfelt. Tilgang ordnes med bistand fra Apollo.

Illustrasjon til nyhet om styring av KI-agenters tilgang til bedriftens data
Illustrasjonen er laget med KI; den er ikke et fotografi fra en hendelse.

Dette lanserte Apollo

Ifølge selskapets beskrivelse ligger Agent Services mellom agenten og de interne systemene: Tjenesten gjør forespørsler om til API-kall, håndterer legitimasjon og håndhever begrensninger. Apollo trekker fram fire funksjoner: søk etter data og verktøy, identitetsstyring, tilgangspolicyer og revisjon. Disse er oppført i den offisielle kunngjøringen av tjenesten.

Pressemeldingen distribuert via PR Newswire ble publisert 7. oktober kl. 12.02 amerikansk østkysttid – kl. 19.02 i Moskva. Dette er tidspunktet da kunngjøringen ble publisert; nøyaktig tidspunkt for når tilgangen åpnes, er ikke oppgitt.

Hvorfor begrense agentens tilgang

Et praktisk scenario Apollo beskriver, er at én agent arbeider med ulike ansatte. I eksempelet på selskapets blogg ber en kundestøttemedarbeider og en finansanalytiker om informasjon om en omstridt faktura. Begge får tilgang til fakturaen, men kundens kredittgrense er bare tilgjengelig for analytikeren. Forskjellen bestemmes av klassifiseringen av feltet og tilgangspolicyen.

Tilnærmingen kan være nyttig for team som kobler agenter til kunde-, finans- og andre interne tjenester: Tillatelser kan defineres for bestemte data og ta hensyn til hvem som ga agenten oppgaven. Apollo opplyser også om en pilot hos Intuit. GraphOS er allerede i ordinær drift der, mens den nye Agent Services testes i en forhåndsversjon. Selskapet knytter piloten til analyse av markedsføringsutgifter; kunngjøringen inneholder ingen kvantitative resultater for besparelser.

Slik fungerer reglene

Ifølge dokumentasjonen for tilgangsregler angir en regel en bruker eller gruppe, den kallende applikasjonen, dataene som skal beskyttes, og resultatet av kontrollen. Felt klassifiseres med tagger; en regel kan gjelde en tagg eller en tjeneste. Det finnes tre virkninger: returnere verdien, skjule innholdet eller nekte tilgang.

Ved avslag finnes det flere alternativer: Fjerne feltet helt fra svaret, returnere en feil eller tillate at det bes om ekstra tilgang. Hvis et felt har flere tagger, har den strengeste virkningen prioritet: Avslag går foran maskering, og maskering går foran tillatelse.

En viktig detalj ved oppsettet er at Apollo i administratorveiledningen advarer om at tjenesten foreløpig ikke kontrollerer bruker- eller gruppeidentifikatoren hos identitetsleverandøren. En skrivefeil gjør at regelen ikke lenger samsvarer med forespørsler, uten at det gis noen tydelig melding. Derfor bør det å kontrollere det faktiske resultatet for hver rolle inngå i piloten.

Ifølge Apollos beskrivelse av arkitekturen avgjør policy-motoren tilgang uten at en språkmodell deltar. Der står det også at felt uten en klassifiseringstagg ikke er begrenset. Samtidig anbefaler oversikten over dokumentasjonen å blokkere feltene i den tilkoblede tjenesten før tillatelser gis. Disse formuleringene gjør det nødvendig å kontrollere den konkrete konfigurasjonen: Teamet bør teste tilgangen til både taggede og ikke-taggede felt separat.

Revisjon og tilgjengelighet

Veiledningen for Monitor beskriver en logg over forespørsler med tidspunkt, klient, verktøy, operasjon, berørt tjeneste og resultatet av regelhåndhevingen. For hver forespørsel kan man se hvilke regler som ble utløst, og hvilke felt som ble maskert eller blokkert.

Det finnes en viktig begrensning i revisjonsfunksjonen: visningen av svaret viser strukturen og endrede felt, men ikke verdiene som den opprinnelige tjenesten returnerte. Kontroll av det konkrete innholdet i svaret må planlegges separat. CSV-eksporten omfatter forespørslene som er lastet inn på den gjeldende loggsiden.

Kildene bruker ulike betegnelser på tilgangsfasen. I blogginnlegget fra 7. oktober kunngjør Apollo en offentlig forhåndsversjon og tilbyr en venteliste. Dokumentasjonen for tjenesten omtaler fasen som en privat forhåndsversjon og krever hjelp fra en Apollo-medarbeider for å få tilgang. Siden oppgir ingen dato for siste oppdatering, så det er ikke mulig å fastslå i hvilken rekkefølge formuleringene ble tatt i bruk.

Den praktiske veien videre er nå å avtale en pilot med Apollo. De undersøkte kildene oppgir verken tidspunkt for en stabil lansering eller pris for Agent Services. Før tilkobling bør teamet definere hvilke felt agenten skal få tilgang til, hvem som eier tillatelsene, og hvilke testforespørsler som skal brukes for hver rolle.

People

No people listed for this article yet.

Keep readingCloudflare lanserte Web Search API: nettsøk for agenter via AI Gateway
Read the next article

Gjør det du leser til en fungerende integrasjon

Utforsk jsonscrapers API-er for sosiale data, test forespørsler og bygg neste arbeidsflyt.

Utforsk API-er