Klasické zero-trust principy aplikované na každý zdroj, každý request, každého agenta, každý nástroj. Žádná implicitní důvěra jen proto, že je někdo na VPN. Žádný „admin by default". Každé rozhodnutí logované.

Principy

1. Nikdy nedůvěřuj, vždy ověř — každý request autentizovaný a autorizovaný na úrovni zdroje, ne na perimetru
2. Least privilege — udělený přístup je co nejužší, který úlohu umožňuje
3. Explicitní allowlists — agenti a nástroje vyžadují konkrétní povolení, ne implicitní přístup tím, že jsou „uvnitř firewallu”
4. Loguj všechno — každé rozhodnutí je audit událost

Jak to platí pro uživatele

Uživatelův request na čtení dokumentu:

1. Session autentizovaná (SSO token ověřený, MFA pokud vyžadované)
2. Členství ve Base zkontrolováno
3. Přístup ke kolekci zkontrolován
4. ACL na úrovni dokumentu zkontrolováno (včetně zděděných omezení)
5. Redakční pravidla aplikovaná, pokud je role uživatele omezená (např. externí reviewer)
6. Access událost zapsaná do audit logu
7. Odpověď vrácena — nebo zamítnuta s konkrétní chybou ukazující na politiku, která blokovala

Jak to platí pro agenty

Agenti jsou first-class zero-trust občané. Agent má explicitní scope:

• Tool allowlist — agent může volat jen nástroje uvedené v jeho konfiguraci. Agent bez send_email v allowlistu nemůže poslat e-mail, i kdyby k tomu byl vyzván.
• Knowledge scope — agent vidí jen kolekce, které mu byly přidělené. Výzkumný agent ve Base A nemůže dotazovat korpus Base B.
• Output schema — pokud je agent omezený na konkrétní output schema, nemůže produkovat libovolné volné odpovědi.
• Rate limity — per-agent budgety volání brání runaway smyčkám.

Obrana proti prompt injection

Zero-trust pro agenty znamená, že prompt řízený útočníkem nemůže oklamat agenta, aby dělal věci mimo svůj allowlist:

• Agent si nemůže udělit nové nástroje přes prompt injection — nové nástroje vyžadují admin config změnu
• Agent nemůže exfiltrovat data na neautorizovaný endpoint — odchozí volání jsou omezená na allowlist
• Agent nemůže eskalovat oprávnění a číst jiné Bases — každá instance agenta je Base-scoped

Jak to platí pro nástroje

Nástroje — built-in i vlastní — nejsou bezpodmínečně důvěřované. Každé volání nástroje:

• Ověří, že volající agent má ten nástroj v allowlistu
• Aplikuje per-tool rate limity
• Spustí validaci vstupu (velikost payloadu, shoda se schématem)
• Zachytí volání v audit logu
• Aplikuje redakci výstupu, pokud nástroj vrací data, která volající nemá vidět

Jak to platí pro workflows

Workflows dědí oprávnění uživatele nebo agenta, který je spouští. Workflow, které dělá tři tool calls dotýkající se citlivých dat, selže na druhém kroku, pokud volajícímu chybí přístup — nepokračuje na třetí krok se zastaralou autorizací.

Model oprávnění

Principál	Může držet oprávnění na…
User	Bases, kolekce, dokumenty, agenty, workflows, nástroje
Group	Totéž — skupiny dědí na členy
Agent	Knowledge scope (read), tool allowlist (execute), output schema
Service account	Totéž jako user — ale jen API, žádná interaktivní session
External user	Časově omezený scope-ovaný přístup, žádný default

Vyhodnocení politik

Oprávnění se vyhodnocují shora dolů s tím, že explicit deny vyhrává nad allow. Pořadí:

1. Explicitní deny pro konkrétního principála + zdroj
2. Explicitní allow pro konkrétního principála + zdroj
3. Oprávnění zděděná ze skupiny
4. Base-default oprávnění
5. Deny (implicitní)

Správa session

• Životnost session — default 12 hodin, konfigurovatelná per Base
• Triggery reauth — high-risk akce (data export, změna konfigurace) mohou vyžadovat reauth
• Device binding — session lze připnout na fingerprinty zařízení
• Kill switch — admin může okamžitě revokovat všechny aktivní session

Zero-trust na úrovni sítě

• mTLS mezi všemi interními službami
• Per-tenant izolace data-plane
• Egress řízený explicitním allowlistem — agenti se mohou dostat jen na nakonfigurované destinace
• Web Application Firewall na ingressu

Související

• Autentizace a RBAC — konfigurace identit a rolí
• Audit log
• Šifrování