Konfigurace sdílených a soukromých připojení
Připojení jsou hranicí důvěry mezi Siesta AI a externími systémy. Připojení může být poskytovatel modelu, účet OAuth, API klíč, REST koncový bod, MCP server, úložný systém, CRM, systém pro správu tiketů, kalendář, e-mailový účet nebo poskytovatel vyhledávání/škrabání.
Tok revize připojení
- Otevřete Připojení a zkontrolujte, zda integrace již existuje.
- Přidejte poskytovatele nebo vlastní REST/MCP připojení.
- Pojmenujte připojení s vlastníkem, systémem, prostředím a účelem.
- Potvrďte, že přihlašovací údaje mají minimální užitečná oprávnění.
- Zkontrolujte, zda je připojení sdílené, soukromé nebo spravované systémem.
- Zkontrolujte správu připojení organizace: poskytovatel povolen/nepovolen a přístup na úrovni funkcí.
- Nakonfigurujte limity tokenů pro modelová připojení, kde je objem důležitý.
- Otestujte jednu akci čtení a jednu akci zápisu před přiřazením k produkčnímu agentovi nebo pracovním postupu.
Sdílené vs Soukromé
| Typ | Použijte, když | Riziko pro správce |
|---|---|---|
| Sdílené připojení | Tým by měl používat stejný servisní účet, účet CRM, projekt Jira, aplikaci Slack, poskytovatele modelu, účet pro ukládání, REST API nebo MCP server | Jeden přihlašovací údaj může ovlivnit mnoho uživatelů a agentů |
| Soukromé připojení | Akce by měla probíhat pod schránkou aktuálního uživatele, kalendářem, Diskem nebo osobním grantem OAuth | Chování agenta závisí na autorizaci každého uživatele |
| Spravované systémem | Nástroj zabudovaný do systému potřebuje připojení spravované Siestou | Správci musí rozumět tomu, který agent má tento systémový nástroj povolen |
Nepojujte osobní účet jako sdílené produkční připojení, pokud externí systém nemá možnost servisního účtu a vlastník podnikání přijímá operační riziko.
Správa funkcí
Správa připojení organizace může zakázat typ připojení nebo vynutit specifické funkce do režimu potvrzení. Efektivní přístup k funkcím používá nejpřísnější nastavení mezi politikou organizace a konfigurací na úrovni připojení.
Použijte tento základ:
| Chování funkce | Výchozí postoj |
|---|---|
| Vyhledávání, seznam, čtení, shrnutí | Povolit, když je publikum agenta oprávněno vidět data |
| Návrh, náhled, validace | Povolit, když může uživatel zkontrolovat před akcí |
| Vytvořit, aktualizovat, odeslat, publikovat, přesunout | Vyžadovat potvrzení, pokud podnikový proces výslovně nepovoluje přímé provedení |
| Smazat, publikovat, změny oprávnění, finanční/klientské aktualizace | Vyžadovat potvrzení a zúžit přístup týmu |
| Neznámá REST/MCP funkce | Vyžadovat potvrzení, dokud nebude otestována a zdokumentována |
Pro REST nástroje potvrďte parametry cesty, parametry dotazu, pole těla a statické hlavičky. Pro MCP nástroje potvrďte URL serveru, vlastní hlavičky, názvy funkcí, schémata a vlastnictví.
Limity tokenů pro modelová připojení
Modelová připojení mohou mít denní a týdenní Organization, Team a User defaults i defaults a výjimky pro konkrétní model. Použijte je u sdílených připojení pro objemné agenty a workflow. Sloupec Disabled vypíná záznam override a obnoví odpovídající default; nezakazuje subjektu přístup. Pro blokaci použijte access policy nebo connection governance.
Postupujte od obecného ke konkrétnímu:
- Nastavte all-model defaults připojení pro běžný Organization, Team a User rozpočet.
- Přidejte modelové defaults pro model s jiným provozním profilem.
- User nebo Team override vytvářejte jen jako odůvodněnou výjimku.
- All-model i model-specific využití kontrolujte v Analytics > Limits.
Příklad: ponechte 20M denní User default připojení, pro nákladný model nastavte 5M User default a pilotnímu uživateli 8M modelový override. Jeho požadavky musí splnit obecný limit připojení, efektivní modelový limit, všechny Team limity a Organization limit. Přesné pořadí popisují Token Limits v Connections Management.
Rotace přihlašovacích údajů
Rotujte přihlašovací údaje, když:
- se změní vlastník,
- testovací integrace se stane produkční,
- poskytovatel hlásí podezřelou aktivitu,
- sdílený pracovní postup je ukončen,
- dodavatel nebo dočasný správce odejde,
- klíč byl zkopírován do výzvy, prohlížeče, klientské aplikace nebo tiketu.
Po rotaci otestujte připojení a zkontrolujte provedení nástrojů na chyby.
Kontrolní seznam pro přijetí do produkce
- Připojení má vlastníka podnikání.
- Rozsah přihlašovacích údajů je zdokumentován.
- Poskytovatel je povolen v řízení organizace.
- Funkce zápisu mají potvrzení, kde je to potřeba.
- Limity tokenů modelu jsou nastaveny, kde je to potřeba.
- Připojení je sdíleno pouze s těmi správnými týmy.
- Testovací agent nebo pracovní postup vyprodukoval úspěšné provedení nástroje.
- Chování při selhání je pochopeno před tím, než je připojení použito týmem.
Vlastnictví a rotace MCP credentialů
Nejprve vyberte režim autentizace externího MCP serveru. Osobní OAuth grant nebo user-specific header ponechte Private. Shared connection použijte jen pro schválenou týmovou nebo service identitu se scope odpovídajícím všem uživatelům.
Každá sdílená MCP connection musí mít vlastníka, který umí zopakovat consent, rotovat hlavičky a řešit provider revocation. Reautorizaci provádí pouze vlastník. U Shared connection se nový credential použije pro všechny oprávněné uživatele; u Private pouze pro vlastníka. Potom connection znovu otestujte.
Kontrola OAuth připojení
Pomocí kontroly health a reautorizace oddělte neplatný refresh credential od chyby endpointu, scope, sítě nebo jedné funkce. Reautorizaci provede vlastník a správce potom ověří bezpečný read a případně jeden omezený potvrzený write v cílovém systému.