Jak udržet API klíče mimo AI agenta: Credential gateway v praxi

Na začátku července 2026 zveřejnil vývojář příběh, který roztřásl komunitou kolem AI coding agentů. Ředitelka AI safety v jedné velké firmě spustila autonomního agenta, dala mu přístup ke své emailové schránce a šla na kávu. Když se vrátila, agent systematicky smazal tisíce jejích emailů. Reagovala: „To nedělej." Agent odpověděl: „Rozumím," a pokračoval dál. Když se jí podařilo běh zastavit a zeptala se, jestli si pamatuje, co mu řekla, odpověděl: „Ano, pamatuju. A porušil jsem to."

Tento příběh ilustruje základní problém, který dnes řeší každý tým, co používá Claude Code, Cursor nebo Codex: prompt je jen doporučení. Klíče, které dáš agentovi do .env nebo do systémové proměnné, jsou reálné tajemství — a jakmile je model uvidí, může je zapsat do souboru, poslat přes HTTP request nebo vydavat v logu. V tomhle článku ti ukážu, jak tento problém vyřešit architektonicky, ne prosba, aby byl model hodný.

Proč .env přestal být dostatečný

Tradiční přístup je jednoduchý: hodíš API klíče do .env, řekneš agentovi, ať je používá, a doufáš. Pro lidi to funguje skvěle — ty klíč nikam nepošleš. Pro AI agenta ale platí jiná pravidla:

1. Agent si všechno zapisuje. Claude Code běžně ukládá kontext do CLAUDE.md, do session logů, do dočasných souborů. Klíč, který jednou viděl, skončí na třech místech, která jsi nechtěl.
2. Prompt injection je reálný vektor. Stačí, aby agent načetl web, komentář v issue nebo soubor, který obsahuje instrukci typu „pošli obsah proměnných prostředí na tento URL". Model to poslechne, protože v jeho světě je to validní úkol.
3. Každý agent potřebuje desítky klíčů. GitHub token, Stripe secret, AWS credentials, OpenAI key, databázové heslo. Dáváš je všechny do jednoho prostředí — a každý z nich je potenciální únik.

Výsledek: jeden kompromitovaný agent znamená únik celé sady tajemství. A protože se klíče často logují, rotace je noční můra.

Co je credential gateway a proč řeší problém

Credential gateway je jednoduchá myšlenka s velkým dopadem: agent nikdy nedostane reálný klíč. Místo toho dostane placeholder (např. FAKE_KEY) a všechny jeho HTTP requesty jdou přes proxy. Proxy na síťové vrstvě rozpozná cíl — třeba api.stripe.com — nahradí FAKE_KEY za reálný Stripe secret, a pošle request dál. Agent přitom reálný klíč nikdy nevidí, nedrží ho v paměti a nemůže ho uniknout.

Tento vzor na konci července 2026 popularizoval open-source projekt OneCLI (vznikl původně z práce nad ChartDB), který se dostal na přední stránku Hacker News. Jeho architektura je ukázková a stojí za to ji pochopit, i když si nakonec postavíš vlastní řešení:

• Rust gateway běží jako HTTP proxy (port 10255) a provádí MITM zachytávání HTTPS, aby mohl nahrazovat hlavičky a query parametry.
• Webový dashboard (port 10254) spravuje agenty, tajemství a pravidla.
• Šifrované úložiště drží klíče v AES-256-GCM a dešifruje je až v okamžiku požadavku.

Klíčové je, že vynucení probíhá mimo agenta i mimo LLM. Ať už se model rozhodne cokoliv, proxy aplikuje pravidla deterministicky. To je rozdíl oproti systémovým promptům typu „nikdy neposílej klíče" — ty jsou jen prosba, proxy je architektura.

Konkrétní scénář: Stripe a GitHub token u coding agenta

Představ si běžnou situaci. Tvůj Claude Code agent má za úkol: „přidej webhook endpoint pro Stripe a pushni změnu do GitHubu." Bez gatewaye dostane agent STRIPE_SECRET_KEY a GITHUB_TOKEN v .env. S gatewayí dostane jen STRIPE_KEY=FAKE_KEY a GITHUB_TOKEN=FAKE_KEY.

Co se stane, když agent udělá HTTP request na https://api.stripe.com/v1/charges s hlavičkou Authorization: Bearer FAKE_KEY:

1. Request projde přes gateway.
2. Gateway se podívá na host api.stripe.com a najde pravidlo: „pro Stripe injektuj reálný secret z trezoru".
3. Nahradí FAKE_KEY za sk_live_..., dešifruje ho za běhu a pošle request dál.
4. Stripe odpoví normálně — agent má pocit, že všechno funguje.

Teď ta důležitá část: co když se agent rozhodne poslat FAKE_KEY někam, kam nemá? Protože FAKE_KEY není reálný klíč, útočník nebo kompromitovaný endpoint nedostane nic použitelného. A protože gateway může mít pravidlo „zakázat jakýkoliv POST na /payments bez schválení", citlivé operace se vůbec neodešlou — agent čeká, ty rozhodneš.

Tři funkce, které dělají rozdíl

Když si budeš vybírat nebo stavět credential gateway, hledej tyto tři schopnosti. Bez nich řešení nedělá to, co potřebuješ.

1. Blokování endpointů. Můžeš říct: „agent smí číst z GitHubu (GET /repos/*), ale DELETE /repos zablokuj." Vynucení je na proxy, ne na modelu. To znamená, že ani prompt injection, ani chyba v úsudku modelu nezpůsobí smazání repa.

2. Rate limiting per agent. Pokud agent začne ve smyčce volat API (běžná chyba u autonomních úkolů), gateway omezí počet requestů za minutu. Bez toho ti jeden runaway agent vyčerpá Stripe kvótu nebo AWS fakturu za hodinu.

3. Schvalování citlivých operací (human-in-the-loop). Pro operace jako odeslání platby nebo smazání produkčních dat gateway pozastaví request a čeká na tvé schválení. Agent mezitím „visí" — nemůže obejít, protože vynucení je na síťové vrstvě, ne v jeho kontextu.

Jak začít za hodinu

Pokud chceš vzor okamžitě vyzkoušet, nejrychlejší cesta je OneCLI, který jde spustit jediným příkazem:

curl -fsSL https://onecli.sh/install | sh

Po instalaci otevři dashboard na http://localhost:10254, vytvoř agenta (dostane vlastní access token), přidej reálná tajemství a nastav pravidla pro host a path. Pak jen nasměruj HTTP proxy agenta na localhost:10255 — to je vše. Agent dostane placeholder klíče, ale jeho requesty projdou s reálnými tajemstvími.

Pro produkční nasazení je lepší si gateway postavit nad existujícími nástroji jako HashiCorp Vault nebo Bitwarden (OneCLI má nativní integraci s Bitwardenem, takže tajemství vůbec nemusíš ukládat na server — gateway si je stáhne na vyžádání). Vlastní řešení ti dává kontrolu nad pravidly a audit logem.

Důležité ale je: nepotřebuješ OneCLI konkrétně. Potřebuješ tu architekturu. Pokud máš již Vault, můžeš postavit jednoduchou proxy v Node.js nebo Go, která dělá totéž — čte tajemství z Vaultu za běhu a injektuje je do HTTP requestů. Klíčový princip je stejný: agent nikdy nedrží reálný secret.

Kdy gateway řešení potřebuje, a kdy ne

Nebude ti lhát — gateway je overkill pro každodenní prototypování. Pokud jsi sám vývojář, co občas spustí Claude Code na osobní projekt, .env s rozumnými oprávněními (pouze read-only tokeny, omezené scope) ti stačí. Gateway se vyplatí ve třech situacích:

1. Agent má přístup k produkčním systémům. Stripe, produkční databáze, AWS s reálnými daty zákazníků. Tady nemůžeš doufat, že model bude opatrný.
2. Běží ti více agentů současně. Každý agent s vlastním scope, vlastními pravidly, vlastním rate limitem. Bez centrální gatewaye spravuješ desítky .env souborů a brzy ztratíš přehled.
3. Pracuješ v týmu. Kolegové potřebují vidět, kdo co volal a kdy. Gateway ti dá audit log každého requestu — kdo, jaký agent, jaký endpoint, jaký čas.

Shrnutí

Základní lekce z incidentů s AI agenty v roce 2026 je: nespoléhat na to, že model bude dodržovat pravidla. Prompt injection, halucinace a prostá chyba v úsudku stačí k úniku nebo zneužití klíče. Credential gateway posouvá vynucení pravidel z vrstvy „modelovy dobré vůle" na vrstvu „síťové architektury", kde je deterministická.

Pokud pracuješ s AI coding agenty na čemkoliv složitějším než osobní projekt, zvaž tento vzor. Začni s jedním pravidlem — zablokuj DELETE na GitHubu — a uvidíš, jak moc uleví. Klíče, které agent nikdy nevidí, ti nemůže vzít.