Jak navrhnout účty služeb LLM pro produkční úlohy

Produkční úlohy LLM by se neměly ověřovat jako lidé. Úloha CI, backendová služba, agent runner, dávkový procesor nebo brána pro partnery potřebuje svou vlastní nelidskou identitu s jasným vlastníkem, úzkým rozsahem, rozpočtem, auditní stopou a cestou k ukončení. Bez tohoto modelu může jeden uniklý klíč představovat příliš mnoho systémů, offboarding neodebere přístup a zprávy o využití nedokážou vysvětlit, jaké pracovní zatížení způsobilo náklady nebo riziko.

Tato příručka poskytuje technickým a platformovým týmům praktický návrh správy účtů služeb LLM napříč rozhraními API poskytovatelů a interními bránami. Odděluje ověřená fakta o poskytovatelích od doporučení implementace a vyvolává předpovědi, kde se provozní model pravděpodobně vyvine.

Co je servisní účet LLM?

Fakt: Servisní účty jsou jiné než lidské identity používané aplikacemi a pracovní zátěží, nikoli jednotlivými uživateli. OpenAI API projekty podporují servisní účty a klíče API v rozsahu projektu. Anthropic popisuje servisní účty jako pojmenované nelidské identity v rámci organizace. Google Cloud IAM popisuje servisní účty jako nehumánní uživatele pro aplikace a pracovní zátěž.

Pro systémy LLM by měl účet služby představovat hranici pracovní zátěže: jedna back-endová služba, jedna rodina pracovních postupů CI, jedno běhové prostředí agenta, jeden dávkový kanál nebo jedna integrační vrstva API partnera. Neměl by představovat osobu, celou společnost nebo každou aplikaci v prostředí.

Užitečný záznam servisního účtu odpovídá na pět otázek:

• Která aplikace nebo pracovní postup vlastní tuto identitu?
• V jakém prostředí může běžet?
• Který tým je odpovědný za náklady, přístup a incidenty?
• Jaké modely, koncové body, nástroje, datové zásady a oblasti jsou povoleny?
• Jak se pověření otočí, zruší nebo nahradí federací?

Kdy vytvořit servisní účet

Vytvořte servisní účet, když je volajícím operační software, nikoli člověk. Mezi běžné příklady patří úlohy CI/CD, které spouštějí evals, produkční služby API, pracovníci zpracovávající dokumenty, kopiloti zákaznické podpory, fronty autonomních agentů, plánované úlohy obohacení a interní vývojářské platformy, které zprostředkovávají LLM přístup mnoha týmům.

Nevytvářejte nový servisní účet pro každého vývojáře, každý místní experiment nebo každou výzvu. Lidský průzkum patří za uživatelskou identitu a krátkodobá vývojová oprávnění. Atribuci na úrovni výzvy a na úrovni funkcí lze zachytit jako metadata požadavku pod identitou pracovní zátěže.

Jednoduché rozhodovací pravidlo funguje dobře:

• Pokud může volající běžet bez dozoru, použijte servisní účet.
• Pokud volající obsluhuje produkční provoz, použijte servisní účet pro jednotlivé úlohy a prostředí.
• Pokud volající jedná za zákazníka nebo partnera, oddělte identitu pracovní zátěže od identity delegovaného tenanta.
• Pokud je volající člověk, který používá konzoli nebo notebook, neschovávejte to za produkční servisní účet.

Začněte inventářem identity

Migrace by měla začít inventářem, nikoli rotací klíčů. Týmy často zjistí, že jeden klíč poskytovatele používají produkční služby, pracovní úlohy, místní skripty, kanály eval a opuštěné integrace. Otočením klíče nejprve vzniká riziko, aniž by došlo ke zlepšení vlastnictví.

Vytvořte inventář pomocí těchto kategorií:

• Klíče poskytovatele ve vlastnictví člověka API.
• Účty služeb pro pracovní zátěž.
• Identity CI/CD.
• Interní klíče vydané bránou.
• Klíče delegované partnerem nebo zákazníkem.
• Pověření pro nouzové rozbití skla.
• Neznámé klíče, které se stále používají.

Pro každé pověření, poskytovatele záznamů, projekt nebo pracovní prostor, vlastníka klíče, spotřebovávající aplikaci, prostředí nasazení, tajné umístění, povolené modely, vlastníka výdajů, naposledy viděné časové razítko a riziko odvolání. Tento inventář se stává zdrojem pravdy pro LLM API správu klíčů, ale servisní účty by měly být modelovány jako prvotřídní identity pracovní zátěže spíše než jen další štítek klíče.

Používejte jeden servisní účet na hranici pracovní zátěže

Hlavní volbou návrhu je granularita. Příliš málo servisních účtů vytváří sdílený rádius výbuchu. Příliš mnoho vytváří provozní hluk. Správná jednotka je nejmenší hranice pracovní zátěže, která má odlišné vlastnictví, oprávnění, nákladový profil nebo potřeby reakce na incidenty.

Používejte samostatné servisní účty pro:

• Produkční a neprodukční prostředí.
• Různé aplikace vlastněné různými týmy.
• Služby zaměřené na zákazníky versus interní zakázky.
• Interaktivní cesty požadavků versus asynchronní dávkové procesory.
• Běhové moduly agentů, které mohou volat nástroje nebo spouštět smyčky.
• Partner API povrchy, které odhalují delegovaný přístup.

Praktický vzor pojmenování je:

llm-sa-{app}-{env}-{team}-{purpose}

Příklady:

llm-sa-supportbot-prod-cx-chat
llm-sa-contracts-stg-legal-extract
llm-sa-evals-ci-platform-regression
llm-sa-agentrunner-prod-eng-tools

Do názvu účtu nekódujte tajemství, jména zákazníků, osobní jména ani čísla dočasných lístků. Místo toho vložte měnitelné podrobnosti do značek nebo metadat.

Namapovat účty poskytovatelů na model identity brány

Fakt: Možnosti poskytovatele se liší. OpenAI podporuje servisní účty v API projektech a účty projektových služeb jsou jedinečné pro projekt, kde byly vytvořeny. Pracovní prostory Anthropic mohou obsahovat členy, servisní účty, klíče API a limity zdrojů. Anthropic Federace identit zátěže umožňuje úlohám používat podepsané tokeny identity namísto statických Anthropic přihlašovacích údajů, přičemž limity atribuce a sazby jsou při konfiguraci vázány na pracovní prostor.

Doporučení: Udržujte model servisního účtu na úrovni brány, i když existují nativní servisní účty poskytovatele. Identita brány by měla být stabilním interním objektem, ke kterému se připojují zásady, výkaznictví, rozpočty a důkazy auditu. Pověření poskytovatele jsou pak detaily implementace namapované pod nimi.

Například:

internal_service_account:
  id: sa_01h_supportbot_prod
  name: llm-sa-supportbot-prod-cx-chat
  owner_team: customer_experience
  environment: production
  app: supportbot
  allowed_models:
    - provider: openai
      model_family: gpt-4.1
    - provider: anthropic
      model_family: claude-sonnet
  data_policy: no_training_required
  monthly_budget_usd: 2500
  provider_bindings:
    openai_project: proj_supportbot_prod
    anthropic_workspace: ws_supportbot_prod

Toto mapování je důležité u multimodelové AI API brány, protože poskytovatelé na vyšší úrovni odhalují různé struktury účtů, fakturační pole, oprávnění modelu a možnosti federace. Jediná vrstva interní identity umožňuje týmům vynutit si jednu smlouvu o zásadách a přitom zachovat kontext specifický pro poskytovatele pro řešení problémů.

Úzce rozsah oprávnění

Servisní účet by se měl řídit tím, co potřebuje pracovní vytížení, nikoli tím, co umožňuje klíč poskytovatele. Minimálně definujte rozsah napříč těmito dimenzemi:

• Hranice poskytovatele: kteří poskytovatelé a projekty nebo pracovní prostory poskytovatelů mohou být použity.
• Hranice modelu: povolené rodiny modelů, verze, náhledové modely a záložní modely.
• Hranice koncového bodu: chat, odpovědi, vkládání, dávka, soubory, doladění, asistenti, nástroje nebo rozhraní API pro správu.
• Hranice prostředí: vývoj, příprava, produkce, izolovaný prostor nebo partner.
• Data boundary: zásady uchovávání, region, třída citlivých dat a povolené stavové funkce.
• Hranice rozpočtu: měkká upozornění, pevná omezení, limity za minutu a měsíční limity.
• Hranice sítě: akceptované zdrojové sítě, identity pracovního zatížení nebo platformy nasazení.

Administrativní API oprávnění by téměř nikdy neměla být dostupná pro účty runtime služeb. Oddělte automatizaci zajišťování od úloh odvození. Backendová služba, která odesílá výzvy, by také neměla být schopna vytvářet nové klíče poskytovatele, měnit rozpočty nebo udělovat přístup k modelu.

Pokud je to praktické, upřednostněte federaci před statickými klíči

Fakt: Anthropic dokumentuje federaci identit zátěže jako způsob, jak úlohy používat podepsané tokeny identity namísto statických Anthropic přihlašovacích údajů. Google Cloud varuje, že klíče servisních účtů spravovaných uživateli představují bezpečnostní rizika, pokud nejsou spravovány pečlivě, a doporučuje bezpečnější alternativy, kde je to možné. OWASP doporučuje centralizované tajné úložiště, auditování tajných požadavků a použití, rotaci, odvolání a vypršení platnosti, kde je to možné.

Doporučení: U cloudových služeb a systémů CI/CD, kde existuje podpora poskytovatelů, upřednostňujte federaci identit pro pracovní zátěž nebo krátkodobou výměnu tokenů. Statické klíče API používejte pouze v případě, že je federace nedostupná, není podporována cestou poskytovatele, kterou potřebujete, nebo je provozně neodůvodněná pro pracovní zátěž s nízkým rizikem.

Federační postup obvykle vypadá takto:

1. Úloha běží v cloudu, CI nebo principu poskytovatele identity.
2. Úloha získá podepsaný token identity od tohoto poskytovatele identity.
3. Poskytovatel LLM nebo interní brána ověřuje vydavatele, publikum, předmět a nároky.
4. Brána mapuje token na interní servisní účet.
5. Brána vydá krátkodobou relaci nebo přímo autorizuje požadavek LLM.

Ověřte více než vydavatel. Zkontrolujte publikum, předmět, cestu k úložišti nebo pracovní zátěži, prostředí, deklarace větve nebo nasazení, pokud jsou k dispozici, a životnost tokenu. Federace přesouvá riziko ze statického úniku tajemství na konfiguraci poskytovatele identity. Neúmyslný přístup mohou stále udělovat slabé nároky, široké zásady důvěryhodnosti nebo tolerantní prostředí CI.

Vyžadovat atribuční metadata u každého požadavku

Servisní účty identifikují pracovní zátěž, ale neměly by být jediným polem přiřazení. Požadavky produkčního LLM potřebují dostatek metadat k rychlému zodpovězení provozních otázek.

Vyžadovat tato pole na bráně:

• service_account_id
• app
• environment
• owner_team
• deployment_id nebo verze vydání
• request_purpose, například chat, extrahování, klasifikace, hodnocení nebo agent_tool_use
• tenant_id nebo případně identifikátor zákazníka
• workflow_id nebo identifikátor úlohy pro asynchronní práci

Tato pole podporují LLM API připisování nákladů, reakci na incidenty, rozhodnutí o limitu sazby a odsouhlasení faktur poskytovatele. Zabraňují také běžnému režimu selhání, kdy je každý požadavek ze sdíleného klíče označen pouze jako „backend“.

Připojit rozpočty a upozornění k identitám pracovní zátěže

Servisní účty často běží bez obsluhy. To dělá kontrolu nákladů důležitější, nikoli méně. Uživatel si může všimnout nekontrolované konverzace. Naplánovaný agent nebo opakovaný pokus o dávkovou úlohu může přes noc přečerpat rozpočet.

Nastavte rozpočty ve více vrstvách:

• Pokud je podporován rozpočet projektu nebo pracovního prostoru poskytovatele.
• Měsíční rozpočet na úrovni brány na servisní účet.
• Detekce anomálie krátkého okna pro náhlé výkyvy.
• Maximální odhadovaná cena na žádost nebo na zakázku.
• Samostatné limity pro produkční, pracovní, CI a vyhodnocovací zátěž.

Pro různé prahové hodnoty použijte různé akce. U 50 procent upozorněte tým vlastníků. Na 80 procent, vyžadovat potvrzení. Na 100 procent buď zablokujte nekritické požadavky, přejděte na levnější schválené modely nebo požadujte explicitní přepsání. Správné chování závisí na tom, zda je pracovní zátěž zaměřená na zákazníka, interní, dávková nebo kritická pro bezpečnost.

Navrhněte pracovní postup životního cyklu

Servisní účet bez ovládacích prvků životního cyklu se stává dalším nespravovaným tajemstvím. Definujte pracovní postup před širokým přijetím.

Požadavek

Žadatel musí uvést název aplikace, prostředí, tým vlastníka, obchodní účel, očekávanou měsíční útratu, klasifikaci dat, požadavky na model, požadavky na koncový bod a zda je možná federace.

Schválení

Schválení by mělo přijít od týmu vlastníka a platformy nebo zásad zabezpečení. Úlohy s vysokým rozpočtem, citlivými daty, partnery nebo nástroji by měly vyžadovat přísnější kontrolu než nízkorizikové úlohy interní sumarizace.

Provisioning

Vytvořte interní servisní účet, vazbu poskytovatele, rozpočet, modelové zásady, jímku auditu a tajný nebo federační trust. Kde je to možné, poskytování prostřednictvím automatizace místo ruční práce s konzolí.

Tajné doručení

Pokud je vyžadován statický klíč, doručte jej pouze centralizovanému správci tajných informací nebo platformě nasazení. Neposílejte klíče prostřednictvím chatu, lístků, místních souborů nebo stránek dokumentace.

Recenze

Kontrolujte servisní účty s pevnou kadenci. Potvrďte tým vlastníka, poslední použití, oprávnění, rozpočet, přístup k modelu, zásady dat a zda lze statické klíče nahradit federací.

Zakázat a smazat

Před smazáním deaktivujte nepoužívané servisní účty. Tím se vytvoří okno obnovy, pokud byla vynechána závislost pracovní zátěže. Po období karantény smažte účet a zrušte všechna vázání a tajemství poskytovatele.

Přihlásit události, které potřebují auditoři a respondenti

Protokoly auditu by měly pokrývat aktivitu v řídicí i datové rovině. Přihlaste se minimálně:

• Vytvoření, aktualizace, deaktivace a smazání servisního účtu.
• Vytvoření, čtení, rotace a zrušení pověření.
• Vytvoření trustu federace a změny zásad nároků.
• Změny oprávnění, přístupu k modelu, přístupu ke koncovému bodu a zásad dat.
• Každý požadavek LLM s účtem služby, tenantem, modelem, poskytovatelem, využitím tokenu, odhadovanou cenou, stavem a účelem požadavku.
• Události prahu rozpočtu, blokování s pevným limitem a ruční přepisy.
• Správce API volání, která ovlivňují projekty poskytovatelů, pracovní prostory, servisní účty nebo klíče.

Odešlete tyto události do neměnného nebo neoprávněně chráněného auditního streamu. Uchovávejte telemetrii požadavků s vysokou kardinalitou odděleně od dlouhodobých auditních důkazů, pokud to pomáhá řídit náklady na úložiště, ale zachováváte klíče spojení potřebné pro vyšetřování.

Plán migrace ze sdílených klíčů

Nahrazování sdílených klíčů lze provádět postupně. Vyhněte se migraci velkého třesku, pokud není klíč již kompromitován.

1. Identifikujte nejvytíženější sdílené klíče. Pořadí podle útraty, návštěvnosti, přístupu k modelu a neznámého vlastnictví.
2. Seskupit volající do hranic pracovního zatížení. Používejte protokoly, zdrojová úložiště, proměnné nasazení, uživatelské agenty a síťová zdrojová data.
3. Vytvářejte účty služeb s rozsahem. Začněte s produkčními úlohami, které mají jasné vlastníky a vysoké výdaje nebo vysoké riziko.
4. Směrovat přes bránu. Pokud by přímá migrace poskytovatele trvala déle, zachovejte dočasně starý klíč poskytovatele za bránou.
5. Dual-run attribution. Porovnejte provoz, náklady, chyby, latenci a fakturaci poskytovatele, než se úplně přerušíte.
6. Střídat volající. Aktualizujte tajné klíče nasazení, proměnné CI a konfiguraci aplikace po jednom.
7. Odvolat sdílený klíč. Pokud je poloměr výbuchu nejasný, dejte nejprve do karantény, poté zrušte po okně pozorování.

Cílem není pouze otáčet klíčem. Cílem je nahradit nejednoznačný přístup identitou, zásadami, rozpočtem a důkazy vlastněnými pracovní zátěží.

Explicitní kompromisy

Více servisních účtů zlepšuje kontrolu, ale zvyšuje administraci. Konvence pojmenování, metadata vlastnictví, úklidové úlohy a kontrolní pracovní postupy jsou to, co udržuje model použitelný.

Federace snižuje riziko statického tajemství, ale přidává závislost na poskytovateli identity. Výměna tokenů může selhat kvůli změnám vydavatele, posunu nároku, zkreslení hodin nebo změnám konfigurace CI. Navrhněte jasné režimy selhání a upozornění.

Ovládací prvky nativní poskytovatele jsou cenné, ale nekonzistentní. Někteří poskytovatelé vystavují projekty, pracovní prostory, účty služeb, rozpočty nebo federace odlišně. Vrstva identity na úrovni brány poskytuje konzistentní zásady a přehledy, ale musí si zachovat kontext pro kvóty, fakturaci a šetření podpory.

Krátkodobá pověření zlepšují zabezpečení, ale zvyšují složitost běhu. Pečlivě ukládejte tokeny do mezipaměti, respektujte vypršení platnosti a vyhněte se tomu, aby každý požadavek LLM závisel na pomalém volání řídicí roviny.

Centralizované vynucování zlepšuje řízení, ale zvyšuje odpovědnost platformy. Pokud brána vlastní zásady, rozpočty a atribuci, musí být dobře pozorovatelná a provozně vyspělá.

Kontrolní seznam implementace

• Vytvořte inventář lidských klíčů, identit pracovního zatížení, identit CI, klíčů partnerů a přihlašovacích údajů.
• Definujte konvenci pojmenování pomocí aplikace, prostředí, týmu vlastníka a účelu.
• Použijte jeden servisní účet na hranici produkčního zatížení.
• Propojte každou identitu s úzkými projekty nebo pracovními prostory poskytovatelů.
• Omezit rodiny modelů, koncové body, oblasti, datové zásady a rozpočty.
• Pokud je to podporováno, preferujte federaci nebo krátkodobou výměnu tokenů.
• Statické klíče ukládat pouze v centralizované správě tajných klíčů.
• Vyžadovat u každého požadavku metadata atribuce.
• Nastavte rozpočty servisních účtů a upozornění na anomálie.
• Protokolovat přihlašovací údaje, oprávnění, požadavky, rozpočet a události zrušení.
• Nepoužívané účty před jejich smazáním deaktivujte.
• Migrujte sdílené klíče podle pracovní zátěže a poté zrušte staré přihlašovací údaje.

Závěr

Řízení servisního účtu LLM je provozním modelem pro produkční přístup AI. Zacházejte s každým bezobslužným volajícím jako s identitou pracovní zátěže s vlastníkem, účelem, hranicí oprávnění, rozpočtem a životním cyklem. Používejte nativní servisní účty poskytovatelů tam, kde pomáhají, preferujte federaci tam, kde je to praktické, a normalizujte identitu na bráně, aby bylo možné OpenAI, Anthropic, Gemini a interní systémy řídit konzistentně.

Predikce: Platformy LLM se budou i nadále odklánět od obecných statických klíčů k modelům služeb-účet a pracovní zátěže-identity. Týmy, které nyní zavedou čisté vlastnictví pracovní zátěže, budou mít později snazší cestu k federaci poskytovatelů, připravenosti na audit, partnerské API správě a spolehlivé kontrole nákladů.

Související čtení

• API klíčové řízení pro týmy