Si el teu equip genera codi amb agents, la pregunta ja no és si aquest codi funciona. És qui comprova que, a més, sigui segur.
Aquesta peça defensa una tesi que va contra la reacció més natural: demanar seguretat a l'agent, a l'especificació o al prompt, no la garanteix. El que no es comprova no existeix. La seguretat s'escriu com a criteri que es pot executar i la verifica alguna cosa independent de l'agent, a cada canvi. I on el risc és alt, decideix una persona.
La dada: funciona, però no és segur
El 10 d'octubre de 2026 es va publicar a arXiv LSCBench, un benchmark de seguretat per a agents de codi. Els autors van construir 450 tasques a partir de 150 vulnerabilitats reals, en 7 llenguatges i 24 tipus de debilitat (CWE). Cada tasca demana només funcionalitat, amb una especificació que no esmenta mai la seguretat. Després van corregir cada solució amb proves ocultes de funcionament i de seguretat.
Dit d'una altra manera: en aquest benchmark, l'agent lliura en la majoria dels casos alguna cosa que passa les proves funcionals, i com a màxim una de cada quatre vegades alguna cosa que també passa les de seguretat. Les proves funcionals en verd no diuen res sobre el segon punt, per la mateixa raó que expliquem a per què els tests generats per IA descriuen el codi en comptes de provar-lo: una prova només comprova el que algú va decidir comprovar.
Risc Són benchmarks, no producció. Les tasques es van construir a partir de vulnerabilitats conegudes, cosa que pot exagerar la taxa davant la feina diària d'un equip. La dada no diu que tres de cada quatre canvis del teu equip siguin insegurs. Diu que «funciona» no és una prova de «és segur».
I si l'hi demanem a l'especificació?
És la reacció òbvia: si l'especificació no parlava de seguretat, que en parli. Un altre estudi va provar una cosa semblant. SusVibes, un benchmark de 186 peticions de funcionalitat tretes de projectes reals de codi obert, va avaluar 12 configuracions d'agents amb models de primera línia. Els autors conclouen que tots els agents rendeixen malament en seguretat: en l'exemple que destaquen, el 57 % de les solucions són correctes i només l'11,8 % són segures.
La part que importa aquí és l'experiment següent. Van afegir a cada petició pistes sobre la vulnerabilitat que calia evitar, i conclouen que aquesta estratègia no resol els problemes de seguretat. Avisar l'agent no és el mateix que comprovar el que fa.
Tampoc no ho arregla canviar de model. Veracode va provar més de 100 models en 80 tasques: el codi generat introduïa vulnerabilitats en el 45 % dels casos, i els models més grans no ho feien significativament millor que els petits. Veracode ven eines de seguretat i la seva nota no detalla com va dissenyar les proves, així que és una dada de suport, no la base de l'argument.
El que no es comprova no existeix
Res d'això no vol dir que l'especificació sobri. Al contrari: si un requisit de seguretat no és escrit, no hi ha res a comprovar. El que diuen aquests estudis és que escriure'l és necessari i no suficient. Cal alguna cosa, fora de l'agent, que el comprovi cada vegada.
Això és Spec-Driven Development (SDD) ben entès, tal com l'expliquem a Spec-Driven Development amb IA: l'especificació diu què s'ha de complir i una comprovació independent diu si es compleix. La idea de convertir els criteris d'acceptació en la porta del merge serveix igual per als criteris de seguretat que per als funcionals.
Un requisit de seguretat que només és a l'especificació és un desig. Quan a més és una prova que falla si s'incompleix, és un criteri.
On viu cada comprovació
No hi ha una sola barrera. N'hi ha quatre, i cadascuna cobreix el que les altres no veuen:
| Comprovació | Què detecta | Quan s'executa | El que no detecta |
|---|---|---|---|
| Criteris de seguretat escrits com a proves | Que s'incompleixi una regla concreta del producte: qui pot veure què, quines entrades es rebutgen | A cada canvi, abans de la revisió | El que ningú no va escriure com a criteri |
| Anàlisi automàtica del codi i de les dependències | Patrons coneguts de vulnerabilitat i paquets amb errades publicades | A cada canvi | Errors de lògica propis del producte |
| Lots petits | Res per si sols: fan que cada canvi es pugui revisar i desfer | Sempre | No substitueixen cap de les altres |
| Revisió i decisió d'una persona | Riscos de disseny i de context que cap prova no recull | En autenticació, permisos, pagaments i dades personals | El que no arriba a la seva taula |
Elaboració d'onext; els exemples són il·lustratius
La tercera fila no detecta res, i tot i així és la que fa funcionar les altres. DORA ho diu al seu model de capacitats per a equips amb IA: treballar en lots petits és especialment útil en un entorn assistit per IA, i com que la IA augmenta la velocitat dels canvis, el control de versions esdevé una xarxa de seguretat crítica. Com preparar aquesta marxa enrere ho trobaràs a com desfer el que fa un agent de codi.
La segona fila inclou les dependències que afegeix l'agent, que tenen el seu propi problema, com expliquem a la línia que ningú no discuteix. I la quarta no és la revisió de tot: és la decisió on el risc és alt. Com encaixa amb la resta del procés de revisió ho trobaràs a revisar codi generat per IA.
Un criteri de seguretat escrit com a prova
Un exemple il·lustratiu, sense cap client al darrere. L'especificació d'una botiga diu: «un usuari només pot llegir les comandes del seu propi compte». Convertit en prova, queda així:
# Criteri de l'especificació: un usuari només pot llegir les comandes del seu compte.
def test_un_usuari_no_llegeix_comandes_d_un_altre_compte(client, anna, comanda_de_lluis):
resposta = client.get("/comandes/" + comanda_de_lluis.id, usuari=anna)
assert resposta.status_code == 404La prova no diu a l'agent com ha d'implementar els permisos. Només falla si algú, persona o agent, deixa que l'Anna llegeixi la comanda del Lluís. S'escriu abans de demanar el canvi i no l'escriu el mateix agent que escriu el codi. Si l'escriu ell, comprova la seva pròpia interpretació, que és justament el que no volem.
Aquest tipus de proves no cobreix la seguretat de l'agent en si, que és un altre problema: quines eines té, quins permisos i quines instruccions pot rebre sense que ningú ho vegi. En parlem a la injecció de prompts i els permisos dels agents.
Com ho plantegem a onext
Si vols revisar amb algú de fora què comprova avui el teu equip i què no, el diagnòstic és gratuït, i si al diagnòstic no veiem diferència, no hi ha Quick-start. Com és la resta del camí ho trobaràs a AI-Accelerated Development.
Preguntes freqüents
És segur el codi que escriuen els agents d'IA?
Funcionar i ser segur són coses diferents. Al benchmark LSCBench, publicat l'octubre de 2026, sis agents de primera línia van resoldre correctament entre el 73,6 % i el 91,3 % de 450 tasques, però com a màxim el 25,1 % de les solucions eren a més segures. Són proves construïdes a partir de vulnerabilitats reals, no codi de producció, així que la dada no diu quina part del codi d'un equip és insegura.
N'hi ha prou de demanar seguretat a l'especificació o al prompt?
No n'hi ha prou. L'estudi SusVibes va provar d'afegir a cada petició pistes sobre la vulnerabilitat que calia evitar, i els autors conclouen que aquesta estratègia no resol els problemes de seguretat. Demanar-ho ajuda que el criteri existeixi; el que el fa complir és una comprovació independent de l'agent.
Un model més gran escriu codi més segur?
No necessàriament. Veracode va provar més de 100 models en 80 tasques i va concloure que els models més grans no ho fan significativament millor que els petits: el codi generat introduïa vulnerabilitats en el 45 % dels casos. Veracode ven eines de seguretat i la seva nota no detalla el disseny de les proves, així que convé llegir-ho amb aquesta cautela.
Què és un criteri de seguretat escrit com a prova?
És un requisit de seguretat de l'especificació convertit en una prova que s'executa a cada canvi. Per exemple, «un usuari només pot llegir les comandes del seu compte» es converteix en una prova que demana la comanda d'un altre compte i exigeix que la resposta sigui un error. Si l'agent trenca aquesta regla, la prova falla, encara que tota la resta funcioni.
On ha de decidir una persona?
A les zones on una errada de seguretat té un cost alt: autenticació, permisos, pagaments i dades personals. Allà les proves i l'anàlisi automàtica filtren, però una persona revisa el canvi i decideix si entra. A la resta, la comprovació automàtica fa la major part de la feina.
Què té a veure això amb Spec-Driven Development?
És Spec-Driven Development (SDD) ben entès: l'especificació diu què s'ha de complir, inclosos els requisits de seguretat, i alguna cosa independent de l'agent comprova que es compleix. Si la seguretat no és a l'especificació, no hi ha res a comprovar; si hi és però ningú no la comprova, és un desig.
Fonts
- Tianyi Wu, Chao Ge, Peng Chen i altres, «Last Secure Code Benchmark: Is the Code You Vibe Secure?», arXiv:2610.14766, v1 del 10 d'octubre de 2026 (preprint; 450 tasques, 150 vulnerabilitats reals, 7 llenguatges, 24 CWE, sis agents).
- Songwen Zhao, Danqing Wang, Kexun Zhang, Jiaxuan Luo, Zhuo Li i Lei Li, «Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks», arXiv:2512.03262, v1 del 2 de desembre de 2025, revisat (v4) el 21 de setembre de 2026 (preprint; 186 tasques, 12 configuracions d'agents; l'exemple del 57 % i l'11,8 % és SWE-Agent amb Claude 4 Sonnet).
- Veracode, nota de premsa del «2025 GenAI Code Security Report», 30 de juliol de 2025 (80 tasques, més de 100 models; fabricant d'eines de seguretat).
- Kevin M. Storer i Derek DeBellis, «Introducing the DORA AI Capabilities Model», Google Cloud Blog, 23 de setembre de 2025.
- Les cites de fonts en anglès estan traduïdes per onext. La taula de comprovacions i l'exemple de prova (il·lustratiu, sense client) són elaboració pròpia d'onext.
Bernat López és fundador i CEO d'onext, boutique d'IA. Acompanya equips de desenvolupament i de producte a treballar amb IA amb mètode —especificació abans de programar, una persona que decideix on hi ha risc i Spec-Driven Development— i aplica a la seva pròpia empresa el que proposa: onext funciona amb el seu propi sistema agèntic.
LinkedIn →