La tua azienda usa Cursor, Codex o Copilot senza policy? Rischi e controlli minimi

Cursor, Codex, Copilot e altri strumenti di AI coding possono entrare in azienda prima che IT, security e legal abbiano definito regole chiare. Un developer li usa nell’IDE, un team abilita agent mode, un contractor incolla log in chat, un reparto sperimenta con repository cliente. Tutto sembra produttivo, ma nessuno sa davvero quali dati sono usciti, quali tool sono autorizzati e quali modifiche richiedono review.

Una policy AI coding non serve a bloccare l’innovazione: serve a rendere esplicito chi può usare quali strumenti, su quali dati, con quali permessi e con quali controlli prima del merge o del deploy.

Per CISO, CTO, IT manager e legal, il punto non è scegliere un vendor una volta per tutte. Il punto è evitare che ogni team inventi la propria regola mentre codice, prompt, segreti e responsabilità si muovono fuori controllo.

Perché una policy è necessaria anche con tool enterprise

Le funzioni enterprise aiutano: SSO, RBAC, content exclusion, audit log, sandbox, approval policy, controlli su agenti cloud o locali. Ma queste impostazioni governano lo strumento, non garantiscono automaticamente che il codice prodotto sia sicuro, che i dati siano leciti da usare o che ogni pull request abbia la review giusta.

Una policy aziendale deve unire tre livelli distinti. Il primo riguarda i tool: quali strumenti sono consentiti, con quali account e configurazioni. Il secondo riguarda i dati: cosa non può essere inserito in prompt, contesto, log o workspace. Il terzo riguarda il processo: quando servono review, test, gate, logging, formazione ed eccezioni. Senza questi livelli, l’azienda rischia una falsa sensazione di controllo: “abbiamo Copilot Enterprise” o “Codex è in sandbox” non risponde alla domanda su quali repository sono ammessi, quali dati sono vietati e chi approva una PR che modifica auth, pipeline o segreti.

Definire tool consentiti e tool vietati

La policy deve partire da un inventario che comprenda Cursor, Codex, Copilot, Claude Code, estensioni IDE, chat generiche, plugin, MCP server, agenti cloud, tool open-source, account personali, piani free e ambienti di test. Per ogni tool va definito almeno l’owner interno, il piano consentito, i requisiti minimi (SSO, MFA, logging, gestione accessi, data retention, privacy), i repository o team autorizzati, le funzionalità abilitate e il processo per richiedere eccezioni.

La regola non deve essere “usa l’AI con buon senso”. Deve dire cosa è ammesso, cosa è vietato e cosa richiede approvazione.

Scrivere la lista dei dati vietati nei prompt

La parte più importante della policy è spesso la più concreta: cosa non si può incollare o rendere disponibile al modello. Alcuni elementi vanno vietati esplicitamente o autorizzati solo con un processo specifico:

Segreti, token, password, cookie, chiavi cloud e chiavi API.
Dati personali, dati cliente, dati sanitari, finanziari o HR.
Log con PII, header, stack trace o identificativi cliente.
Dump di database e file di produzione.
Contratti, documenti riservati, incident report e vulnerability report.
Codice di clienti o terze parti non autorizzato.
Architetture, endpoint interni e configurazioni di produzione non redatte.

Non basta scrivere “non inserire dati sensibili”. Servono esempi vicini al lavoro reale dei developer: log di errore, file .env, ticket, schermate, query, file di test, transcript, configurazioni cloud.

Governare repository, contesto e indicizzazione

Molti strumenti AI lavorano leggendo file aperti, repository, workspace, branch, issue, documentazione o contesto indicizzato. Se l’azienda non definisce confini, l’agente può vedere molto più di quanto serve. La policy deve quindi distinguere repository pubblici, repository interni, codice cliente, monorepo, progetti regolati, componenti con segreti, ambienti di produzione e repository legacy: alcuni possono essere ammessi con esclusioni, altri richiedono solo modalità read-only o il divieto di indicizzazione.

Controlli utili in questo ambito:

File di esclusione per directory sensibili.
Allowlist di repository autorizzati.
Divieto su progetti cliente senza consenso contrattuale.
Separazione tra clienti diversi.
Secret scanning prima dell’uso agentico.
Review delle impostazioni di indexing e retention.

Stabilire quando agent mode, terminale e cloud agent sono ammessi

Autocomplete e chat non hanno lo stesso profilo di rischio di un agente che modifica file, esegue comandi, apre pull request, usa MCP server o lavora in cloud con una copia del repository. La policy deve classificare le modalità operative e associare a ciascuna una regola minima.

Modalità	Rischio	Regola minima
Chat o completamento locale	Uso improprio di dati e snippet	Dati vietati, review del codice, account aziendale
Modifica file nel repository	Diff vulnerabili o troppo ampi	PR obbligatoria, reviewer owner, branch protection
Terminale o comandi	Segreti, side effect, installazioni	Sandbox, approval, no produzione
Cloud agent	Codice e contesto in ambiente remoto	Repository autorizzati, rete limitata, segreti separati
MCP/tool esterni	Azioni su sistemi aziendali	Allowlist tool, least privilege, audit log

Se una modalità permette scrittura, deploy, accesso rete o uso di tool esterni, non deve essere abilitata per default su tutti i repository.

Rendere obbligatoria la review sulle aree sensibili

La policy deve chiarire che il codice generato dall’AI resta responsabilità del team: una PR che passa i test non è automaticamente accettabile. La review diventa obbligatoria quando la modifica tocca autenticazione, sessioni, password reset, MFA o OAuth callback; autorizzazioni, ruoli, tenant isolation, middleware e policy; API, query, serializer, upload, export e pagamenti; segreti, variabili ambiente, log ed error handling; dipendenze, lockfile, package manager e script di installazione; CI/CD, Dockerfile, IaC, cloud, IAM e deploy; prompt runtime, tool calling, RAG, memoria o agenti applicativi.

Il collegamento con la Code Review è diretto: la policy definisce quando la review è necessaria, mentre la review verifica il diff e le eventuali regressioni.

Logging, audit ed evidenze

Una policy senza evidenze è difficile da applicare. L’azienda deve sapere quali tool sono abilitati, quali utenti li usano, quali repository sono coinvolti, quali agenti possono modificare codice, quali eccezioni sono state approvate e quali PR sono state generate o assistite da AI. Non sempre serve loggare il contenuto dei prompt, che può essere sensibile, ma serve almeno la governance data: tool attivi, utenti, configurazioni, repository, approval, eccezioni, finding, review e decisioni di merge.

Per l’incident response, le evidenze devono permettere di rispondere a domande concrete: quale agente ha prodotto questa modifica? Quale contesto poteva leggere? Ha avuto accesso a segreti? Ha usato rete o tool esterni? Chi ha approvato la PR?

Formazione: esempi pratici, non principi astratti

La formazione efficace mostra casi reali del lavoro quotidiano, non principi generici sull’etica dell’AI. I developer hanno bisogno di sapere cosa fare concretamente: un log di produzione che non va incollato in chat, una chiave API in un file di configurazione che va ruotata se è entrata nel prompt, una PR AI-generated che modifica middleware e test, una dipendenza suggerita dall’AI da verificare prima del merge, una policy CORS o IAM allargata per “far funzionare” la build, un file cliente che non può essere indicizzato. Questi esempi rendono la policy comprensibile e applicabile, invece di restare un documento che nessuno consulta.

Gestire eccezioni e rollout

Ogni policy deve prevedere eccezioni, altrimenti le eccezioni diventano informali. Un team può avere un caso sperimentale, un tool non ancora approvato, un repository pilota o una necessità temporanea: in tutti questi casi, l’eccezione deve avere owner, durata, perimetro, rischio accettato, controlli compensativi e revisione. Se resta attiva senza scadenza, non è più un’eccezione ma una seconda policy non governata.

Per il rollout, conviene partire da repository pilota, misurare i problemi, aggiornare la policy e poi estendere. Una policy minima ma applicata e migliorata nel tempo funziona meglio di una policy perfetta scritta prima di qualsiasi test.

Checklist minima per una policy AI coding

Inventario dei tool AI coding usati da dipendenti e contractor.
Tool autorizzati, vietati e in fase pilota.
Requisiti minimi: SSO, MFA, logging, gestione accessi, data retention.
Dati vietati nei prompt e nel contesto, con esempi concreti.
Repository ammessi, esclusi o soggetti ad approvazione.
Regole per agent mode, terminale, cloud agent, rete e MCP.
Secret scanning e file exclusion prima dell’uso su repository sensibili.
Review obbligatoria per aree critiche del codice.
Gate CI/CD minimi per PR AI-generated.
Logging e audit coerenti con privacy e incident response.
Formazione pratica per developer, reviewer e manager.
Processo di eccezione con owner, scadenza e rischio accettato.

Quando coinvolgere ISGroup

Se l’azienda sta già usando AI coding senza regole chiare, la priorità è capire esposizione e rischio: tool attivi, dati trattati, repository coinvolti, controlli vendor, policy interne, pipeline e review.

Scenario	Rischio principale	Servizio consigliato
Uso diffuso senza ownership chiara	Governance debole e responsabilità non assegnate	Virtual CISO
Adozione continuativa di AI coding nei team	Controlli non ripetibili su PR, pipeline e release	Software Assurance Lifecycle
Repository già modificati da AI su aree sensibili	Vulnerabilità o regressioni nel codice	Code Review
Applicazioni web sviluppate con AI coding	Falle applicative non rilevate prima del deploy	Web Application Penetration Testing

Il risultato atteso non è un documento lungo che nessuno legge, ma una policy applicabile: poche regole chiare, responsabilità definite, soglie di escalation e controlli tecnici collegati al processo.

Domande frequenti

Serve vietare Cursor, Codex o Copilot in azienda?
Non necessariamente. Di solito è più efficace autorizzare strumenti e casi d’uso specifici, vietare dati e repository sensibili, imporre review sulle aree critiche e configurare i controlli enterprise disponibili.
Le impostazioni enterprise del vendor bastano?
No. Sono necessarie, ma governano lo strumento. La sicurezza dell’applicazione dipende ancora da codice, dati, repository, review, pipeline, licenze, dipendenze e responsabilità interne.
Quali dati non devono entrare nei prompt?
Segreti, token, password, dati personali, dati cliente, log con PII, dump, contratti, incident report, vulnerability report, codice non autorizzato e configurazioni di produzione non redatte.
Chi deve possedere la policy AI coding?
Serve ownership condivisa: CTO o engineering per il processo tecnico, CISO per il rischio, IT per gli accessi, legal e privacy per dati e contratti, procurement per vendor e clausole.
Quando serve una Code Review?
Quando una PR generata o assistita da AI tocca auth, ruoli, API, query, segreti, dipendenze, pipeline, cloud, pagamenti o logica di business. La policy deve renderlo esplicito prima che la PR arrivi in merge.

Vuoi un Software Assurance Lifecycle realmente sicuro, continuo e conforme?

Affidati a ISGroup per:

Code review manuale e test reali in ogni fase dello sviluppo
Integrazione con DevSecOps, SBOM e remediation assistita
Compliance completa a NIS2, GDPR, DORA con supporto tecnico dedicato

Parla con un esperto

Policy AI coding: rischi e controlli minimi per Cursor, Codex e Copilot