Proč je paranoia správná odpověď
Po sedmi dnech experimentu jsem si jistý jednou věcí: správný postoj vůči agentnímu AI není důvěra, ale řízená nedůvěra. Agent udělá to, co mu dovolíte — a pokud mu dovolíte příliš, udělá přesně to.
Guardrails nejsou omezení produktivity. Jsou to podmínky, za kterých je agentní vývoj bezpečně použitelný. Bez nich experimentujete — ne nasazujete.
MCP jako kontrolní vrstva
Model Context Protocol nabízí přirozené místo pro guardrails: MCP servery. Místo toho, aby agent volal nástroje přímo, volá je přes MCP server, který implementuje kontrolní logiku.
Konkrétní příklady MCP guardrails:
- Souborový systém MCP — agent může číst a zapisovat jen do povolených adresářů. Pokusy o přístup mimo perimeter jsou logoványa zamítnuty.
- Git MCP — commity jsou povoleny, ale push na main vyžaduje lidské schválení. Agent commituje do feature větve, člověk merguje.
- Databázový MCP — agent má přístup jen ke čtení, nebo k izolované vývojové databázi. Žádný přístup k produkčním datům.
- Terminálový MCP — whitelist povolených příkazů. Agent může spustit testy, ne smazat soubory.
Hooky jako pojistky
Git hooky jsou druhá linie obrany. Zatímco MCP guardrails kontrolují, co agent může volat, hooky kontrolují, co se dostane do repozitáře.
Pre-commit hook
Kontroluje každý commit před tím, než je potvrzen. V naší konfiguraci verifikuje:
- Žádné secrets nebo API klíče v kódu (regex na typické vzory)
- Žádné přímé změny v konfiguračních souborech mimo povolené cesty
- Splněný minimální formát commit message
Pre-push hook
Vyžaduje interaktivní potvrzení při pushi do chráněných větví. Agent nemůže tuto kontrolu přeskočit — hook běží na straně klienta a není konfigurovatelný ze systémového promptu.
Limitování nástrojů: méně je více
Jedna z nejefektivnějších guardrails je nejjednodušší: dejte agentovi méně nástrojů, než si myslíte, že potřebuje. Agent s přístupem k terminálu, souborovému systému, databázi a externím API je výkonný — a nepředvídatelný. Agent s přístupem jen k souborovému systému a gitu je pomalejší, ale bezpečnější.
Postupně přidávejte nástroje na základě prokázané potřeby, ne preventivně. Každý přidaný nástroj rozšiřuje plochu pro neočekávané chování.
Lidské review na konci cyklu
Technické guardrails nestačí. Na konci každého agentního pracovního cyklu musí být lidská kontrola — ne jako formalita, ale jako skutečné review.
Minimální kontrolní seznam pro review agentního výstupu:
- Dělá kód to, co byl zadán?
- Jsou testy smysluplné, nebo pouze pro zvýšení coverage?
- Jsou zachovány stávající konvence?
- Jsou viditelné bezpečnostní problémy (SQL injection, XSS, IDOR)?
- Respektuje kód architekturní hranice?
Review nemusí být exhaustivní pro každý commit. Ale pro každou feature nebo logický celek by mělo proběhnout.
Chcete vidět, jak jdou automatizovat firemní procesy? Domluvte si konzultaci — naše řešení začíná tam, kde vibe-coding končí.