Securitate

Tenancy

Fiecare tabelă de business poartă organization_id ca a doua coloană, iar citirile trec prin TenantContext — singura sursă a lui „organizația curentă" (decizia D-002). Organizația nu e niciodată acceptată de la client: dashboard-ul o leagă din sesiune, API-ul o leagă din cheia de API. Fiecare resursă delimitată pe tenant are un test care dovedește că organizația A nu poate citi, actualiza sau șterge rândul organizației B, pe fiecare cale de intrare.

RBAC

spatie/laravel-permission cu echipe cheiate pe organization_id (decizia D-003). Permisiunile sunt <resursă>.<verb> — recording.delete, assistant.publish. Rolurile sunt per organizație, deci faptul că ești admin într-un tenant nu îți dă nimic în altul.

Chei și secrete

• Cheile private de API se stochează ca hash. Textul există o singură dată, în răspunsul de creare.
• Cheile publice se stochează în clar, pentru că sunt publice prin definiție, și poartă restricții de origin și de asistent, fiindcă ajung în bundle-uri de browser.
• Credențialele de furnizor folosesc o cheie de criptare separată (CREDENTIAL_ENCRYPTION_KEY, decizia D-004), nu APP_KEY, deci rotirea cheii aplicației nu cere recriptarea secretelor de furnizor ale fiecărui tenant.
• Nimic nu scrie în log o credențială, un header Authorization sau un body brut de webhook care conține una: pentru asta există App\Support\Redactor și packages/contracts/src/redact.ts.

SSRF

Fiecare URL dat de un tenant — endpoint-uri de tools, ținte de webhook, servere MCP, surse de knowledge — e verificat înainte să fie apelat, și din nou la fiecare hop de redirect. Intervalele private, adresele link-local și endpoint-ul de metadate al cloud-ului sunt refuzate.

Sandboxing

Tools-urile bash, computer și text_editor nu se execută niciodată în procesul gateway. Rulează într-un container fără rețea implicit, cu plafon de CPU și de memorie, cu sistem de fișiere root doar-citire și cu o dimensiune mărginită a ieșirii.

Cele trei nu ajung oricum într-un apel

Convertorul către formatul de fir al gateway-ului nu are nicio mapare pentru bash, computer sau text_editor, deci sunt aruncate din lista de tools a fiecărui apel. Sandbox-ul e real; tool-urile nu ajung la el pe calea asta. Vezi Ce nu este construit.

Prompt injection

Conținutul necontrolat — rezultate de tools, rezultate MCP, bucăți regăsite, vorbirea apelantului — e împachetat înainte să ajungă la model, ca textul din el să nu poată fi citit ca instrucțiune de la operator.

Autentificarea clientului

Browserele nu țin niciodată o cheie privată. Vezi Autentificare.

Jurnal de audit

audit_logs e doar cu inserări și reține cine ce a făcut, cu ce resursă și de unde. Valorile credențialelor sunt excluse din diff-ul înregistrat.

Retenția datelor

Retenție per organizație, setată separat pentru înregistrări, transcrieri, evenimente, log-uri și structured outputs, plus un mod zero data retention care nu păstrează niciun audio și nicio transcriere după apel. Retenția rulează noaptea; zero data retention fără întârziere rulează inline, la finalizare.

Consimțământul la înregistrare e un anunț, nu un consimțământ

Se poate reda un anunț. Înregistrarea pornește înainte să fie rostit, iar un refuz nu poate fi respectat — gateway-ul poate raporta doar announced, pentru că nimic nu colectează o confirmare. Citește consent_state: "announced" ca „s-a făcut o notificare". Vezi Dezvăluire AI și consimțământ.

Conformitate

WARNING

Modurile SOC 2, HIPAA și PCI sunt proiectate, iar controalele de mai sus sunt jumătatea tehnică a lor. Nu se pretinde nicio certificare.

SAML SSO nu e implementat — serviciul de SSO o spune în atâtea cuvinte, și intenționat nu există nicio rută — din lipsa unei biblioteci de XML-DSig. OIDC e implementat. SCIM provizionează utilizatori, dar nu grupuri.