Trezor na přístupy

Přehled

Typ položky secret umožňuje vybírat od klientů citlivé údaje — hesla, API klíče, přístupy k hostingu, tokeny externích služeb — a držet je šifrované. Když agent zavolá get_intake_results, dešifrovaný text se vrátí jednou. Po tom prvním vyzvednutí je hodnota pryč a další volání ji už neobsahují.

Trezor na přístupy je k dispozici v tarifech Solo a Agency. Pokus zařadit položku typu secret na tarifu Free vrátí chybu plan_required.

Proč jsou přístupy jiné

Běžné položky (text, soubor, barva, URL) ukládají odeslané hodnoty do databáze v otevřené podobě. U necitlivého obsahu je to v pořádku.

Položky typu secret fungují jinak:

1. Klient vyplní na portálu zamaskované pole
2. Ještě než hodnota opustí prohlížeč, zašifruje se přes libsodium sealed box veřejným klíčem BriefGate
3. Do databáze se uloží jen šifrovaný text — otevřená podoba se serverů BriefGate nikdy nedotkne
4. Privátní klíč existuje pouze v prostředí serveru, nikdy ne v databázi
5. Ani kompletní dump databáze hodnoty neodhalí

Privátní klíč je 32bajtový tajný klíč páru libsodium. Při vlastním hostingu si generujete vlastní pár a máte pod kontrolou obě strany.

Zadání položky typu secret

Zařaďte ji do items[] při volání define_intake:

{
  "key": "wp_admin",
  "type": "secret",
  "label": "Přístupy do administrace WordPressu",
  "help": "Vaše uživatelské jméno a heslo. Šifrujeme end-to-end a vývojáři se zobrazí jen jednou."
}

Na portálu klient uvidí:

• Zamaskované pole (znaky se při psaní skrývají)
• Ikonu zámku
• Poznámku: „Údaj se zašifruje a vývojáři se zobrazí jen jednou.“

Po odeslání se hodnota přes portál nedá nijak získat zpět.

Průběh jednorázového odhalení

Krok 1. Zavolejte get_intake_results (přes MCP nebo GET /v1/intakes/:id/results).

Při prvním volání obsahují položky typu secret dešifrovaný text:

{
  "wp_admin": {
    "value": "admin:MyPassword123",
    "one_time": true,
    "first_reveal": true,
    "expires_at": "2026-08-15T10:00:00Z"
  }
}

Krok 2. Uložte si hodnotu do vlastního správce hesel. Jinou příležitost mít nebudete.

Při všech dalších voláních stejného endpointu je value vynechané:

{
  "wp_admin": {
    "value": null,
    "one_time": true,
    "first_reveal": false,
    "expires_at": "2026-08-15T10:00:00Z"
  }
}

Když údaj propadne (30 dní po odeslání) dřív, než si ho vyzvednete:

Zavolejte request_revision(intake_id, "wp_admin", "Přístupy propadly, než jsme si je stihli vyzvednout. Prosím zadejte je znovu.") a klient je vyplní znovu.

API klíč použitý k vyzvednutí musí mít scope secrets:read nebo admin.

Auditní stopa

Každé odhalení se zaznamená s údaji:

• Kdo (který API klíč volání provedl)
• IP adresa volajícího
• Časové razítko
• intake_id a item_key

Zobrazení auditního logu:

GET /v1/audit?action=secret.revealed

Filtrování podle intake:

GET /v1/audit?action=secret.revealed&intake_id=int_01J3K...

Do logu se jen přidává, nelze z něj mazat.

Automatická expirace

Přístupy propadají 30 dní po odeslání položky klientem. To je výchozí nastavení. Při vlastním hostingu se řídí proměnnou prostředí SECRETS_TTL_DAYS.

Propadlý údaj má value: null a nedá se získat. Použijte request_revision a nechte klienta zadat ho znovu.

Doporučení pro agenty

Ukládejte okamžitě. Když get_intake_results vrátí položku s first_reveal: true, uložte hodnotu ještě než volání skončí. Přes API už nikdy dostupná nebude.

Ukládejte do správce hesel. Po odhalení dejte hodnotu do svého správce (1Password, Vault, AWS Secrets Manager a podobně). Nezapisujte ji do souboru, nelogujte ji a nedávejte ji do commitu.

Odhalenou hodnotu nikdy nelogujte. Ani na úrovni debug. Pokud váš logger zachytává proměnné, zamaskujte citlivé údaje dřív, než je předáte jakékoli logovací funkci.

Po použití nechte údaj vyměnit. Až přístup doslouží (třeba po nasazení webu), řekněte klientovi, že si ho může změnit. Zachycený údaj byl platný v době sběru; jeho výměna omezí dopad, kdyby se hodnota někde uložila nebezpečně.

Dostupnost