Jak dostat API klíče od klienta k agentovi, aby nezůstaly v chatu
Necháte klienta vložit klíč do portálu BriefGate jako položku typu secret a pak ho vyzvednete přes get_intake_results — agent dostane čitelnou hodnotu přesně jednou a nikdy neskončí v historii chatu, slackovém vlákně ani v e-mailu, na jehož smazání byste museli pamatovat.
Proč jsou ty obvyklé cesty problém
Kódovací agent, který staví klientovi web, dřív nebo později potřebuje něco, co má jen klient: tajný klíč ke Stripe, token k Mapbox, API klíč k Google Maps, přístup ke službě třetí strany, kterou právě zapojuje. Nejrychlejší cesta je zeptat se — v chatu, přes Slack, v e-mailu. Všechny tři zanechají stejnou stopu: přístupový údaj v čitelném textu, trvale uložený v přepisu konverzace, historii kanálu nebo poštovní schránce, dohledatelný kýmkoli, kdo se k tomu chatu, Slacku nebo mailboxu později dostane. Žádná z těch cest nebyla navržená na to, aby držela tajemství — jsou tam jen proto, že se tam zrovna odehrávala konverzace.
Agent se tomu navíc nemůže sám vyhnout obejitím protokolu. MCP požadavek elicitation/create umí v průběhu session rychle zeptat toho, kdo agenta řídí, ale specifikace k tomu má tvrdé pravidlo přesně pro tenhle případ: „Servers MUST NOT use elicitation to request sensitive information." A i bez téhle věty platí, že elicitation se dostane jen k tomu, kdo je na druhém konci aktuálního spojení — ne ke klientovi, který žádný MCP klient nikdy neotevřel a v session vůbec není. Proč tahle mezera v protokolu existuje, rozebírá Asynchronní vstup od člověka pro kódovací agenty; tahle stránka je o praktickém řešení.
Postup
Klíč deklarujete jako položku typu secret při založení sběru podkladů:
{
"project_name": "Bella Napoli — web",
"client": {"email": "majitel@bellanapoli.cz", "name": "Marie"},
"items": [
{
"key": "maps_api_key",
"type": "secret",
"label": "API klíč Google Maps",
"help": "Z Google Cloud Console — použije se k zobrazení vaší pobočky na novém webu. Šifrované, uvidí ho jen agent vašeho vývojáře, a to jen jednou.",
"required": true
}
]
}Klient otevře odkaz na portál, který mu BriefGate poslal, a uvidí maskované heslové pole se zámkem, ne textové pole, které vypadá zaměnitelně se zbytkem formuláře. Není tam žádné „zobrazit vše" ani stopa po zkopírování — jakmile odešle, hodnota z jeho strany obrazovky zmizí. Co se s ní stane dál, je otázka šifrování, ne jen rozhraní: hodnota putuje přes HTTPS a na serveru se při příchodu zapečetí do libsodium sealed boxu ještě předtím, než se čehokoli dotkne databáze. Mechanismus do detailu rozebírá Jak se ukládají přístupy od klienta, včetně jedné věci, na kterou je dobré být přesný — je to šifrování na straně serveru, ne end-to-end ani zero-knowledge.
Jakmile klient hodnotu odešle, zavoláte get_intake_results:
{
"intake_id": "in_8f3kQmR2"
}{
"results": {
"maps_api_key": {
"value": "AIzaSyD-9tSrke72PouQMnMX-a7eZSW0jkFMBWQ",
"one_time": true,
"first_reveal": true,
"expires_at": "2026-11-04T10:22:00Z"
}
},
"meta": {
"maps_api_key": { "type": "secret", "status": "approved", "submitted_at": "2026-10-05T09:12:00Z" }
}
}Pole value je tam jen proto, že jde o první úspěšné přečtení. Zavoláte get_intake_results znovu — i o pár vteřin později, i jen pro kontrolu — a value tam už není; místo něj doplňkový záznam v meta ohlásí secret_unavailable: true. BriefGate přitom nechává krátkou rezervu pro reálný případ selhání, totiž odpověď, která nikdy nedorazila: stejný API klíč, který se zeptá znovu do 5 minut od prvního odhalení, dostane stejnou hodnotu zpátky, takže vás přerušené spojení o klíč nepřipraví. Po uplynutí téhle lhůty je jediný způsob, jak hodnotu znovu uvidět, požádat klienta, aby ji odeslal ještě jednou.
Každé odhalení — ať ho spustí volání API vašeho agenta, nebo kliknutí na Reveal v dashboardu od majitele účtu — se zapíše do needitovatelného audit logu (kdo, jeho IP a kdy), který si majitel účtu přečte z dashboardu. A pokud klient danou hodnotu ještě nemá, nastavte při deklaraci položky required: false — intake se i tak dokončí, místo aby čekal na hodnotu, která neexistuje.
Kam s ní poté, co ji agent má
Jednorázové odhalení BriefGate řeší problém „dostat to ven z chatu"; co s hodnotou uděláte potom, je na vás, stejně jako u jakéhokoli jiného přístupového údaje, se kterým agent pracuje. Čestná, nijak zvláštní odpověď je stejná, jakou byste dali u jakéhokoli jiného tajemství: zapsat ji do lokálního .env souboru, který je v .gitignore a nikdy se nekomituje, nebo do správce tajemství, který projekt už používá, a v kódu na ni odkazovat jako process.env.MAPS_API_KEY, ne vepisovat přímo řetězec kamkoli, kde ho může zachytit diff nebo log. Nevracejte ji zpátky do chatu jako potvrzení, že dorazila — smysl jednorázového odhalení je, že hodnota po odeslání klientem existovala přesně na jednom místě, a vypsání do terminálu, který může vidět klient nebo kdokoli u sdíleného screenshotu, tohle popírá.
Pokud agent běží bez dohledu — CI úloha, naplánovaný běh — a místo přihlášené session používá API klíč, dejte pozor, že přečtení položky typu secret potřebuje na tom klíči konkrétně scope secrets:read (nebo admin); samotné intakes:read nestačí a pokus bez něj skončí tak, že se položka z výsledku prostě vynechá a meta vysvětlí proč. Vyplatí se to nastavit cíleně, místo abyste z pohodlnosti sáhli po admin — secrets:read je přesně to oprávnění, které úloha potřebuje, a nic navíc.
Co tohle neřeší
Položky typu secret jsou dostupné jen na tarifech Solo, Studio a Agency — na Free tarifu jejich přidání vrátí plan_required, takže tenhle postup počítá s tím, že účet je na vyšším tarifu. Tajemství navíc automaticky vyprší 30 dní po odeslání, pokud ho nikdo neodhalí — rozumná pojistka, ne náhrada za to, odhalit ho co nejdřív po odeslání.
Tohle taky není jediný způsob, jak může klient API klíč předat — sdílená položka ve správci hesel je dobrá alternativa, pokud obě strany už nějaký používají, a Jak získat přístupy od klienta bezpečně tuhle možnost poměřuje proti portálu BriefGate. Co konkrétně získáte u položky typu secret, je postup, který agent zvládne od define_intake po get_intake_results sám, bez člověka, který by hodnotu ručně přenášel na jednu nebo druhou stranu.
Související
- Jak se ukládají přístupy od klienta — mechanismus šifrování za každou položkou typu
secreta co si neslibuje - Asynchronní vstup od člověka pro kódovací agenty — proč se MCP elicitation ke klientovi nedostane a jak vypadá alternativa
- Trezor přístupů — plná reference: tarify, scopy, okna pro odhalení, vypršení
- Typy položek — pole typu
secretv kontextu ostatních jedenácti - MCP nástroje —
get_intake_resultsadefine_intakev plném rozsahu