GitHub Copilot rozdeľuje telemetriu identity, promptov a nástrojov do samostatných prepínačov

Telemetria agentov dostáva jemnejšie hranice

GitHub rozšíril podnikovú telemetriu Copilotu o samostatné priradenie aktivity ku konkrétnemu používateľovi a o päť nezávislých tried zachytávaného obsahu. Nové nastavenie telemetry.capture.identity môže do dát OpenTelemetry doplniť prihlasovacie meno účtu GitHub, názov lokálneho používateľského účtu operačného systému a názov zariadenia. Dôležité je, že identitu možno zapnúť bez zberu promptov, odpovedí alebo obsahu nástrojov. GitHub tým oddeľuje otázku „kto agenta použil“ od otázky „čo presne agent spracoval“, ktoré boli pri audite podnikových AI nástrojov často spojené do jedného príliš širokého rozhodnutia.

Identifikačný zber je predvolene vypnutý a zostáva oddelený od existujúceho pseudonymného identifikátora používateľa. Jemné ovládanie je podľa GitHubu dostupné v Copilot CLI, aplikácii GitHub Copilot a reláciách vo VS Code využívajúcich Agent Host. Podnikoví správcovia môžu nastavenia presadzovať centrálne; explicitná spravovaná hodnota má prednosť pred lokálnou konfiguráciou, nastavením SDK aj premennými prostredia. To je podstatné pre organizácie, ktoré nechcú, aby si jednotliví vývojári sami rozšírili rozsah zaznamenávania nad schválenú úroveň.

GitHub zároveň rozdelil obsahovú telemetriu na triedy prompts, responses, toolArguments, toolOutput a policyDetail. Prvá môže obsahovať používateľské, systémové aj vývojárske prompty spolu s podporovaným vstupným kontextom. Druhá zahŕňa odpovede asistenta a podporovaný obsah uvažovania. Argumenty nástrojov môžu niesť príkazy, schémy, identifikátory nástrojov, MCP serverov, pluginov a hookov. Výstupy nástrojov zahŕňajú výsledky aj podrobnosti chýb. Posledná trieda môže zachytiť surové údaje o uplatnenej politike, napríklad cesty v sandboxovanom súborovom systéme.

Auditovateľnosť bez povinného zberu promptov

Najpraktickejšou zmenou je možnosť pripísať udalosti používateľovi bez automatického zaznamenania samotného pracovného obsahu. Bez identity môže bezpečnostný tím vidieť chybný alebo podozrivý beh agenta, ale len ťažko ho spojiť s konkrétnym účtom či zariadením. Plný zber promptov a výstupov by túto medzeru odstránil, zároveň by však vytvoril kópiu zdrojového kódu, interných dokumentov a príkazov v observability systéme. Oddelený prepínač identity umožňuje zvoliť užší kompromis: evidovať zodpovednosť za aktivitu, pričom detailný obsah zostane vypnutý.

To neznamená, že identifikačná telemetria je bez rizika. Kombinácia prihlasovacieho mena, lokálneho účtu a názvu zariadenia je osobným a prevádzkovým údajom, ktorý môže odhaliť organizačnú štruktúru alebo pomenovanie interných staníc. Organizácia preto potrebuje stanoviť účel spracovania, prístupové práva, dobu uchovávania a pravidlá pre export. V európskom prostredí treba navyše posúdiť právny základ a primeranosť monitorovania zamestnancov. Technický fakt, že zber je predvolene vypnutý, nenahrádza internú politiku ani transparentné informovanie ľudí, ktorých aktivita sa priraďuje k identite.

OpenTelemetry je vhodným transportným a modelovacím základom, pretože ide o dodávateľsky neutrálny rámec na generovanie, zber a export metrík, logov a trás. Trasa skladá jednotlivé operácie do súvislosti a jej segmenty môžu niesť atribúty opisujúce vykonanú činnosť. Pri AI agentovi tak možno sledovať priebeh relácie, volania nástrojov alebo chyby bez toho, aby observability platforma bola pevne viazaná na jediného dodávateľa. Štandardizovaný formát však automaticky neurčuje, ktoré atribúty sú bezpečné. O rozsahu, filtrovaní a cieľovom úložisku stále rozhoduje prevádzkovateľ.

Obsahové prepínače môžu otvoriť citlivé dáta

GitHub výslovne upozorňuje, že zachytávanie promptov, nástrojov a detailov politík môže obsahovať zdrojový kód, celé súbory, príkazy, výsledky nástrojov a cesty z pracovného priestoru alebo používateľského profilu. Riziko preto nevzniká len pri promptoch. Argument nástroja môže obsahovať SQL dopyt, URL interného systému alebo názov tajného úložiska; výstup môže priniesť obsah súboru či chybové hlásenie s citlivou cestou. Aj zdanlivo technický atribút politiky môže prezradiť rozloženie pracovného prostredia. Každú triedu je preto vhodné posudzovať samostatne namiesto jedného všeobecného súhlasu so „zberom telemetrie“.

Všetkých päť obsahových tried je predvolene vypnutých. Staršie nastavenie captureContent zostáva k dispozícii ako súhrnná skratka pre tieto triedy, ale nikdy nezapína identitu. Spätná kompatibilita je praktická, no pri migrácii môže byť zdrojom omylov. Administrátor by nemal predpokladať, že historické nastavenie presne vyjadruje nový zamýšľaný rozsah. Bezpečnejší postup je explicitne určiť hodnotu každého prepínača, zdokumentovať dôvod jeho zapnutia a overiť, ktoré dáta sa skutočne objavujú na schválenom zbernom koncovom bode.

Pre bezpečnostné tímy môže byť rozdelenie užitočné pri vyšetrovaní incidentov. Bežne môže zostať aktívna iba prevádzková telemetria a prípadne identita. Detailnejšia trieda sa môže povoliť pre obmedzenú skupinu, konkrétny projekt alebo časovo ohraničenú diagnostiku, ak to podporuje spôsob centrálnej správy. Samotné oznámenie však neuvádza mechanizmus automatického maskovania tajomstiev ani garanciu, že zachytený obsah bude pred exportom redigovaný. Pri návrhu zberu preto treba predpokladať, že povolená trieda môže odoslať surový citlivý obsah, a podľa toho chrániť celý dátový tok.

Praktický postup pre firmy

Slovenská organizácia by mala začať inventárom: ktoré klienty Copilotu používa, kam smeruje OpenTelemetry export a kto má prístup k výsledným dátam. Nasleduje minimálny profil, pri ktorom sa zapínajú iba atribúty potrebné na konkrétny auditný alebo prevádzkový cieľ. Ak postačuje agregované sledovanie výkonu a chýb, identita aj obsah môžu zostať vypnuté. Ak je potrebná individuálna zodpovednosť, možno zvážiť identitu bez promptov. Zber odpovedí, argumentov a výstupov nástrojov by mal vyžadovať prísnejšie schválenie, kratšiu retenciu a obmedzený okruh príjemcov.

Rovnako dôležitý je zberný systém. OpenTelemetry môže dáta poslať do rôznych backendov, takže bezpečnostný výsledok závisí od konfigurácie kolektora, šifrovania prenosu, autentifikácie, geografického umiestnenia úložiska a ďalších exportov. Organizácia by mala skontrolovať aj zálohy, diagnostické kópie a prístup servisných účtov. Ak sa citlivý obsah dostane do observability platformy, musí sa s ňou zaobchádzať podobne ako s repozitárom či produkčnými logmi, nie ako s neškodným panelom metrík.

Nové ovládanie nerieši všetky otázky dohľadu nad agentmi, ale odstraňuje dôležitú voľbu „všetko alebo nič“. Správca môže oddeliť identitu od pracovného obsahu a obsah rozdeliť podľa typu. Skutočný prínos vznikne iba vtedy, keď firmy ponechajú predvolené vypnutie ako východisko a každé rozšírenie podložia konkrétnym účelom. Bez tejto disciplíny môže podrobnejšia telemetria síce zlepšiť vyšetrovanie chýb, ale zároveň vytvoriť nové úložisko kódu, promptov, príkazov a osobných údajov, ktoré bude potrebné chrániť rovnako dôsledne ako systémy, z ktorých pochádzajú.