Securitate¶
Pericol
Acest modul poate fi periculos dacă nu este configurat cu atenție.
Un LLM conectat la Odoo poate, în funcție de ce activați:
Exfiltra date către un furnizor extern de modele (prompturile, rezultatele instrumentelor, atașamentele și istoricul conversațiilor părăsesc serverul dumneavoastră).
Citi orice date comerciale pe care utilizatorul care acționează (sau utilizatorul agent) le poate deja citi conform ACL-urilor Odoo — și, implicit, politica de acces AI permite citirea dacă nu o înăspriți.
Crea, modifica sau șterge înregistrări odată ce capabilitățile Write / Delete și regulile politicii de acces o permit — inclusiv prin rulări nesupravegheate ale agentului (după aprobarea unei propuneri de către supervizor sau imediat, dacă Mod de scriere al sarcinii respective este hybrid / auto) sau instantaneu, în modul de scriere din chat Aplică automat.
Apela acțiuni de business (metode de ciclu de viață) dacă capabilitatea Action și lista de permise le autorizează.
Accesa web-ul public sau instrumente MCP, care pot importa conținut nesigur în contextul modelului (prompt injection) sau pot trimite date în exterior.
Modifica interfața și schema dacă Customize este activat pentru un administrator.
Tratați fiecare privilegiu AI ca pe un acces root în producție pentru acel domeniu: începeți restrâns, măsurați, apoi deschideți doar ceea ce necesită un caz de utilizare concret.
Model de amenințări (ce poate merge prost)¶
Date care părăsesc compania¶
Fiecare rundă de chat și fiecare rezultat de instrument trimis furnizorului este procesat conform termenilor și jurisdicției acelui furnizor. Date personale sensibile, salarii, parole (dacă apar vreodată în text liber), termeni contractuali și secrete ale clienților pot apărea în:
mesajul utilizatorului și istoricul conversației;
instantaneele de înregistrare L4 când conversați dintr-un formular;
rezultatele instrumentelor (rezultate
search/read/read_group);fișierele încărcate și paginile web preluate;
pașii rulărilor agentului și jurnalele cu încărcătură completă (dacă jurnalizarea este setată pe încărcătură completă).
Măsuri de atenuare: alegeți un furnizor și o regiune pe care le acceptați contractual; păstrați Nivel de jurnalizare AI pe Doar metadate în producție, cu excepția investigării unui incident; refuzați modelele/câmpurile sensibile în regulile de acces AI; nu activați Web sau MCP pentru agenții care gestionează tichete confidențiale; instruiți utilizatorii să nu lipească secrete în chat.
Chat interactiv cu privilegii excesive¶
Dacă un angajat cu privilegii înalte folosește asistentul cu Write / Delete / Action activate și modul de scriere Aplică automat, o singură rundă greșită a modelului (sau un prompt injection într-un e-mail lipit) poate modifica imediat datele de producție.
Măsuri de atenuare: păstrați modul de scriere pe hybrid sau confirm; lăsați Delete dezactivat; restrângeți Write la grupuri de încredere prin capabilitatea Limitat la grupuri; reguli de refuz pe câmp/model pentru salarizare, bănci, taxe și modele de sistem.
Agent autonom cu privilegii excesive¶
Un agent asociat unui res.users rulează cu grupurile Odoo ale acelui utilizator. Dacă copiați valorile implicite „Internal User” fără a elimina grupuri, agentul este un angajat deplin. Combinat cu domeniul de canal agent_full și o audiență largă, orice solicitant din lista de permise poate declanșa lucrări la nivelul complet al claselor de capabilități ale agentului.
Măsuri de atenuare: creați un utilizator dedicat, doar cu grupurile necesare; nu asociați niciodată Settings / AI Administrator; setați un supervizor uman; folosiți implicit domeniul intersect; audiențele de canal goale înseamnă nimeni; păstrați capabilitatea Write dezactivată pe agenții orientați spre public; reverificați întotdeauna propunerile în calitate de supervizor.
Ocolirea ciclului de viață / a stării¶
Scrierea brută a câmpului state poate ocoli butoane precum Confirmă / Postează. Poarta respinge scrierile directe în ``state``-ul ciclului de viață. Folosiți în schimb acțiuni de business din lista de permise (call_action), când capabilitatea Action este activată.
Pragul de refuz absolut (autoprotecție)¶
Un set fix de modele tehnice este întotdeauna refuzat instrumentelor AI, indiferent de regulile de acces. Administratorii nu le pot „deschide” prin ai.access.rule. Pragul include:
modele de sistem sensibile din punct de vedere al securității (drepturi de acces, reguli, grupuri, utilizatori și chei API, parametri de configurare, secvențe, meniuri, vizualizări, acțiuni de server, cron-uri, coada de e-mail, token-uri de plată, conturi bancare ale partenerilor, …);
toate modelele aplicației AI însăși (
aiși orice numeai.*) — agenții nu pot reconfigura politica, aptitudinile, blocările sau propriile rulări prin instrumente;mail.messageșidiscuss.channelbrute (integritatea autorului / a probelor — chatter-ul legitim trece prinmessage_postal înregistrării proprietare, nu prin instrumente generice de creare).
Acesta este un prag, nu o politică completă de clasificare a datelor — modelele de business precum hr.employee sau account.move nu sunt refuzate absolut implicit; trebuie să le configurați dumneavoastră, dacă este nevoie.
ir.attachment și mail.activity se află chiar în afara pragului, într-un mic set cu permisiune exclusiv explicită: nicio valoare implicită globală nu le deschide vreodată, dar o regulă de acces o poate face, iar modulul livrează câte una pentru fiecare — atașamente citibile și scriptibile, activități citibile, scriptibile și creabile — astfel încât aptitudinile pentru documente și facturi furnizor să poată citi un PDF, iar agenții să poată lăsa un To-Do de verificare pe numele lor. Crearea sau ștergerea unui atașament și ștergerea unei activități rămân închise, deoarece niciunul dintre modele nu trece la valorile implicite globale. Citiți acele două reguli ca permisiuni reale, nu ca parte a pragului: un agent poate genera o activitate pe orice înregistrare pe care o poate citi și poate reatașa un fișier la o altă înregistrare. Restrângeți-le sau dezactivați-le dacă este mai mult decât necesită implementarea dumneavoastră.
Efecte secundare între modele¶
Un câmp poate scrie într-un model pe care nu l-ați deschis niciodată: crm.lead.email_from actualizează e-mailul partenerului. Poarta refuză astfel de câmpuri, iar cele două traversări nu sunt la fel de configurabile. Acolo unde traversarea este statică — un câmp related — refuzul este absolut și nicio regulă de acces nu îl ridică. Acolo unde este dinamică — un câmp cu inverse — este ridicat doar de o regulă care numește exact acel câmp, astfel încât o acordare la nivel de model să nu poată curge lateral, iar pista de audit să nu poată subraporta tacit ce a atins o scriere. Pe calea de preluare a fișierelor (fetch_file_to_field), activarea pe câmp nu se aplică deloc: un câmp țintă cu invers este refuzat indiferent de regula pe care o scrieți, deoarece conținutul provine dintr-un URL ales de model.
Zece permisiuni de scriere pe câmp sunt livrate activate pe bazele de date cu Contabilitate, pentru fluxul de facturare. Patru sunt pe account.move.line și, pe calea one2many imbricată, o permisiune la nivel de câmp este rezolvată înaintea nivelului de model, deci acele patru câmpuri de linie sunt scriptibile prin Linii factură chiar dacă nicio regulă nu permite scrierea pe account.move.line în sine. Analizați-le înainte de a certifica faptul că liniile de factură sunt închise. Unul dintre cele patru, analytic_distribution, necesită atenție suplimentară: este un câmp JSON, deci regula sa ridică atât refuzul valorilor de tip JSON, cât și protecția între modele, iar inversul său rescrie înregistrările analitice ale unei linii postate — ștergând și recreând înregistrări account.analytic.line pe un model pe care nicio regulă nu l-a numit. Consultați Protecția scrierii între modele.
Eliminarea câmpurilor sensibile¶
Câmpurile ale căror nume seamănă cu secrete (password, token, api_key, …), câmpurile magice și anumite tipuri complexe sunt eliminate sau refuzate la scriere. Aceasta este apărare în profunzime, nu un substitut pentru refuzarea unor modele întregi (de ex. HR).
Confirmare și reverificare¶
Scrierile în așteptare sunt revalidate la momentul aplicării, sub identitatea corectă care acționează și politica curentă. Aprobarea unei propuneri vechi după revocarea drepturilor ar trebui să eșueze închis. Propunerile agentului reconstruiesc autoritatea din rulare, nu din privilegiul celui care confirmă (cel care confirmă autorizează; agentul execută).
Starea de funcționare a rulării face parte din acea autoritate. O propunere de la o rulare oprită la cerere sau închisă de reaperul de rulări blocate deoarece worker-ul ei s-a oprit este refuzată la momentul aplicării și nu poate fi aprobată de nimeni: reaperul nu poate deosebi un worker mort de unul lent, astfel încât unei rulări declarate încheiate de altcineva nu i se permite niciodată să-și reia scrierile. Propunerile lăsate de o rulare care s-a încheiat singură — Efectuat, Eșuat sau Expirat — rămân aprobabile până când întreținerea le expiră.
Roluri și grupuri de securitate¶
Grup |
Scop |
|---|---|
AI: Utilizator |
Folosește chatul, propriile conversații, propriile propuneri de scriere, memoria; supervizorii au nevoie de acesta pentru a aproba propunerile agentului. |
Grupul AI: Administrator |
Configurează agenți, capabilități, politici, aptitudini, MCP, monitorizare. Implică AI: Utilizator. |
Settings (administrare de sistem) |
Pagina aplicației Setări AI, configurare ghidată, planuri de configurare. |
Important
Un utilizator agent nu trebuie să dețină niciodată Settings sau AI Administrator. Modulul blochează asocierea unor astfel de utilizatori pe formularul agentului (la momentul scrierii). Nu acordați ulterior nici acele grupuri pe formularul utilizatorului — aceasta ocolește constrângerea agentului și elimină comutatorul de oprire prin blocare pentru administratorii AI.
Controale stratificate (listă de verificare)¶
Folosiți toate straturile; niciunul nu le înlocuiește pe celelalte:
Grupurile Odoo ale utilizatorului / utilizatorului agent — ce pot face fără AI.
Capabilități AI — ce clase de instrumente există (ask, read, write, delete, web, mcp, action, customize, setup, navigate).
Grupuri de acces AI + reguli — permisiune/refuz pe model/câmp pentru instrumentele AI.
``capability_ids`` ale agentului — plafon suplimentar doar pentru acel agent.
Reguli de canal + audiență + scope_mode — cine poate declanșa agentul și dacă clasele de capabilități sunt intersectate cu cele ale solicitantului.
Mod de scriere / scrieri în așteptare / supervizor — om în buclă. Chatul folosește modul global din Setări; fiecare sarcină a agentului are propriul mod (implicit confirm). Consultați Modul de scriere al sarcinii (doar pentru rulările agentului).
Limite de rată, avertismente, blocări, modele blocate — abuz și iterare.
Jurnalizare și retenție — probe și retenție minimă pentru jurnalele de pași.
Configurația de bază recomandată pentru producție¶
Lăsați Write, Delete, Web, MCP, Customize, Action dezactivate până când un caz de utilizare numit are nevoie de fiecare dintre ele.
Păstrați valorile implicite ale politicii de acces: citire permisă (sau refuzată, dacă preferați refuzul implicit și deschideți doar modelele necesare), creare/scriere/ștergere refuzate.
Preferați modul de scriere hybrid sau confirm pentru chat; niciodată auto pe baze de date de producție partajate, fără un proces de gestionare a modificărilor.
Lăsați Mod de scriere al sarcinii agentului pe confirm, cu excepția cazului în care sarcina este explicit sigură pentru ciorne (de ex. completarea AP care nu postează niciodată); documentați opțiunea.
Un supervizor uman pentru fiecare agent; supervizorii în AI: Utilizator.
Fără un agent „atotputernic” comun tuturor departamentelor — separați pe domenii și date.
Analizați săptămânal, la început.
Documentați fiecare agent în runbook-ul intern (scop, grupuri de utilizatori, reguli, clase de date permise).
Ce nu garantează securitatea¶
Rezistență perfectă la prompt injection.
Clasificarea din start a fiecărui câmp comercial sensibil.
Că presupunerile din datele de antrenare nu pot apărea în răspunsurile în text liber (regulile de ancorare reduc, dar nu elimină halucinațiile — acțiunile critice trebuie să treacă prin instrumente și confirmare).
Conformitatea GDPR/legală în sine — aveți în continuare nevoie de temei legal, DPA-uri cu furnizorii și politică de retenție pentru conversațiile pe care le păstrați.
Continuați cu Primii pași numai după ce această pagină a fost înțeleasă de persoanele care vor administra modulul.