Controlar agents IA com Codex en l'entorn de treball

Els agents IA de treball han canviat una frontera important: ja no parlem només de sistemes que responen text. Eines com Codex poden llegir un projecte, proposar canvis, executar ordres, revisar codi, usar eines connectades i treballar dins d’un entorn real de desenvolupament.

Això és útil precisament perquè acosta la IA al lloc on es prenen decisions i s’executen accions. Però també canvia el risc. Un agent amb accés a repositoris, terminal, navegador, CRM, email, automatitzacions o documentació interna no és un assistent abstracte. És una capa operativa que pot actuar usant la nostra sessió, els nostres permisos i la nostra identitat professional.

Si aquesta capa es configura malament, es compromet o rep instruccions malicioses des d’una font no fiable, el problema no és només que “s’equivoqui”. El problema és que pot produir accions reals atribuïdes a una persona, un equip o una empresa. En el pitjor cas, podria facilitar frau, suplantació, fuga de dades, enviaments massius, manipulació de sistemes o campanyes coordinades que semblin legítimes perquè surten de comptes i eines autoritzades.

Aquest article complementa la guia de privacitat i seguretat en agents IA comercials, les regles de negoci en agents IA i l’anàlisi de què no hauria d’automatitzar un agent IA comercial. El focus aquí és l’entorn de treball: desenvolupament, operacions, marketing, vendes, documentació i qualsevol procés on un agent pugui usar eines en nom d’una persona.

En resum

Controlar agents IA com Codex no vol dir frenar la productivitat. Vol dir separar clarament què pot llegir, què pot modificar, quines eines pot usar, quan necessita aprovació humana i què queda registrat per a auditoria. El risc real no és que el model “vulgui fer mal”, sinó combinar identitat, permisos, dades, eines i escala sense límits suficients.

La regla pràctica és simple: si un agent pot actuar en nom teu, ha d’operar amb permisos mínims, entorn acotat, xarxa controlada, secrets fora d’abast, revisió humana en accions sensibles i traçabilitat completa.

Per què un agent de treball no és un chat

Un chat respon. Un agent connectat actua.

Aquesta diferència canvia l’arquitectura de seguretat. En un entorn professional, un agent pot tenir accés a capes molt diferents:

• Repositoris de codi.
• Terminal i scripts locals.
• Arxius de projecte.
• Gestors de paquets.
• Eines de revisió i pull requests.
• Navegador o aplicacions internes.
• CRM, email, calendaris o documentació.
• Pipelines, desplegaments o credencials si l’entorn els exposa.
• Automatitzacions que repeteixen accions a gran escala.

Cadascuna d’aquestes capes amplia la superfície de risc. Un error aïllat pot ser reversible. Un error amb eines, permisos i capacitat de repetició pot convertir-se en un incident.

Per això no convé avaluar aquests agents com si fossin només una interfície conversacional. Cal avaluar-los com a usuaris operatius amb una combinació de context, autonomia i eines.

El risc central: identitat delegada

Quan una persona usa un agent IA dins del seu entorn, moltes accions poden quedar associades a aquella persona: canvis d’arxius, ordres executades, missatges enviats, tickets creats, branques obertes, comentaris en PR, tasques en CRM o accions en eines connectades.

Si algú compromet aquesta sessió, abusa d’una integració o aconsegueix que l’agent actuï sobre instruccions no fiables, la primera traçabilitat pot apuntar a l’usuari legítim. L’organització pot veure “ho ha fet aquest compte”, encara que la persona hagi estat víctima d’una cadena d’abús.

Aquest és el punt delicat: l’agent pot convertir-se en una interfície d’identitat delegada. No només té intel·ligència; té accés.

Superfície	Risc si no hi ha control	Control mínim
Repositori	Canvis no autoritzats, introducció d’errors o modificacions difícils de revisar.	Branches separades, revisió humana, tests i permisos d’escriptura acotats.
Terminal	Execució d’ordres amb efectes no esperats.	Sandbox, allowlist d’ordres, aprovació per a accions sensibles i logs.
Arxius locals	Lectura de secrets, contractes, dades personals o material intern.	Deny-read per a .env, claus, credencials i carpetes sensibles.
Xarxa	Exfiltració de dades o crides a destinacions no aprovades.	Xarxa desactivada per defecte o allowlist de dominis estricta.
CRM o email	Enviaments externs, canvis comercials o campanyes atribuïdes a l’empresa.	Eines granulars, esborranys, límits de volum i aprovació humana.
Automatitzacions	Repetició massiva d’una acció incorrecta.	Quotes, rate limits, circuit breakers i revisió de fluxos.
Producció	Desplegaments, canvis de configuració o accés a dades reals.	Separació d’entorns, permisos temporals i aprovació explícita.
Logs	Impossibilitat de saber què ha passat.	Registre de prompts, ordres, tool calls, usuari, hora i resultat.

La pregunta correcta no és “confiem en la IA?”. La pregunta correcta és “què podria passar si aquesta identitat i aquests permisos s’usen malament?”.

Campanyes massives: quan l’escala multiplica el dany

L’automatització converteix una acció en un patró repetible. Això és valuós quan el patró és legítim: revisar tickets, preparar briefings, actualitzar documentació, crear tasques o generar esborranys.

També és perillós quan el patró s’orienta malament. Un compte amb accés a email, CRM, xarxes socials, repositoris, formularis o eines d’ads pot produir molt dany si un agent compromès executa accions en massa. No cal imaginar un sistema especialment sofisticat: n’hi ha prou amb combinar permisos amplis, baixa revisió, absència de límits de volum i una identitat que ja té confiança interna.

El risc no és només “hackejar el model”. Pot venir de llocs més normals:

• Una sessió oberta en un equip no protegit.
• Un token o credencial exposat a l’entorn de l’agent.
• Una eina connectada amb permisos massa amplis.
• Un document extern amb instruccions malicioses.
• Un workflow que executa el que l’agent retorna sense validació.
• Una política d’aprovació massa laxa.
• Un entorn on no es revisen accions repetitives fins que ja és tard.

Per això els agents de treball necessiten controls d’escala. Una acció interna de baix risc pot ser automàtica. Una acció externa, repetida, irreversible o reputacionalment sensible ha de tenir límits de volum, aprovació, observabilitat i capacitat d’aturada.

El prompt no és suficient

Un bon prompt ajuda a orientar l’agent. Un arxiu AGENTS.md ajuda a fixar expectatives del repositori: ordres de verificació, normes d’estil, límits del projecte, rutes de desplegament o decisions que requereixen cura.

Però una instrucció no substitueix un control tècnic.

Si l’agent té accés d’escriptura a tot el sistema, xarxa oberta, secrets disponibles, eines genèriques i autorització per actuar sense aprovació, el prompt està carregant amb responsabilitats que haurien de pertànyer a l’arquitectura.

Els límits importants han de viure en diverses capes:

1. Permisos de l’entorn: què pot llegir i escriure.
2. Sandbox: on pot executar ordres.
3. Xarxa: si pot connectar-se fora i a quins dominis.
4. Eines: quines accions concretes té disponibles.
5. Aprovacions: quan s’ha d’aturar i demanar revisió.
6. Secrets: quines credencials queden fora d’abast.
7. Traçabilitat: què es registra per reconstruir decisions.
8. Política humana: qui revisa canvis, excepcions i incidents.

Les instruccions són una capa útil. Els permisos són el límit real.

Controls específics per a Codex i agents de desenvolupament

En el cas de Codex, la documentació oficial descriu diverses peces rellevants per operar amb més seguretat: sandboxing, polítiques d’aprovació, control de xarxa, perfils de permisos, AGENTS.md, configuració gestionada i registres per a govern empresarial.

El patró defensiu hauria de ser aquest:

Capa	Com aplicar-la
AGENTS.md	Documentar regles del repo, ordres vàlides, abast del projecte, restriccions de desplegament i criteris de revisió.
Mode read-only	Usar-lo per a exploració, diagnòstic, planificació o revisió sense canvis.
Workspace acotat	Permetre escriptura només al directori de treball necessari, no a tot el sistema.
Deny-read	Bloquejar .env, claus SSH, tokens, credencials, exports de dades i carpetes personals.
Xarxa controlada	Mantenir xarxa apagada o limitar-la a dominis necessaris.
Aprovacions	Exigir confirmació per a xarxa, ordres sensibles, escriptures fora del workspace, desplegaments o accions destructives.
Eines granulars	Preferir accions específiques davant d’eines genèriques de “fer qualsevol cosa”.
Branques i PRs	Separar treball de l’agent en branches revisables amb tests i diff clar.
Logs	Conservar activitat suficient per a auditoria, depuració i investigació.
Configuració gestionada	En equips, aplicar perfils permesos i restriccions des d’una política central.

L’objectiu no és convertir cada tasca en burocràcia. L’objectiu és que l’autonomia depengui del risc.

Matriu d’autonomia

No totes les accions requereixen el mateix nivell de control. Convé separar cinc nivells.

Nivell	Què pot fer l’agent	Exemples	Control recomanat
1. Observar	Llegir informació no sensible.	Revisar estructura del repo, documentació pública, arxius de codi no secrets.	Read-only i logs bàsics.
2. Proposar	Suggerir canvis sense aplicar-los.	Pla de refactor, diagnòstic, checklist de seguretat.	Revisió humana abans d’editar.
3. Preparar	Crear esborranys o canvis en branca aïllada.	Patch, PR draft, email intern, resum de reunió.	Tests, diff revisable i aprovació abans de publicar.
4. Executar baix risc	Realitzar accions reversibles i acotades.	Formatar codi, actualitzar docs, crear tasca interna.	Permisos mínims, rollback senzill i registre.
5. Executar alt impacte	Tocar producció, enviar campanyes, modificar dades sensibles o actuar externament.	Desplegaments, emails massius, canvis contractuals, esborrat de dades.	Per defecte, no autònom; requereix aprovació explícita i controls addicionals.

Aquesta matriu evita una trampa comuna: tractar igual una correcció de documentació que un desplegament, una campanya o una acció sobre dades personals.

Què hauria de quedar fora d’abast

Un agent de treball no hauria de tenir accés permanent o automàtic a tot el que una persona pot tocar.

Per defecte, convé deixar fora:

• Arxius .env i secrets locals.
• Claus SSH, tokens d’API i credencials de desplegament.
• Dades personals, financeres, legals o de salut que no siguin necessàries.
• Backups i exports complets de bases de dades.
• Eines d’enviament massiu sense límits.
• Producció excepte en fluxos molt controlats.
• Consoles de cloud amb permisos amplis.
• Workflows que executen accions externes sense validació.
• Historials o documents privats que no estiguin vinculats a la tasca.

L’agent ha de rebre context suficient per treballar, no accés indiscriminat a l’entorn complet.

Senyals que l’entorn està mal governat

Hi ha senyals pràctics que haurien de disparar una revisió:

• L’agent pot llegir secrets sense necessitar-ho.
• S’usa el mateix compte per a desenvolupament, producció i automatització.
• No existeix diferència entre lectura, escriptura i accions externes.
• L’agent pot accedir a xarxa oberta sense traçabilitat.
• Les eines connectades no tenen scopes específics.
• Ningú revisa ordres, diffs o tool calls d’alt impacte.
• No hi ha registre central d’accions.
• Les campanyes o workflows no tenen límits de volum.
• No existeix un procediment clar per revocar permisos.
• L’organització no sap quins agents estan actius ni qui els usa.

Quan apareixen diverses d’aquestes senyals, el problema no és el model. És govern operatiu.

Com respondre davant d’un incident

Si se sospita que un agent IA ha actuat malament o ha estat compromès, la resposta ha de ser pràctica i ràpida.

1. Revocar sessions, tokens i credencials vinculades.
2. Aturar automatitzacions i tasques programades relacionades.
3. Aïllar l’entorn on operava l’agent.
4. Revisar logs d’ordres, tool calls, arxius tocats, missatges enviats i destinacions de xarxa.
5. Identificar canvis en repositoris, CRM, email, documentació i producció.
6. Revertir accions errònies quan sigui possible.
7. Rotar secrets que van poder quedar exposats.
8. Revisar permisos abans de reactivar el flux.
9. Documentar causa, abast, impacte i controls afegits.

La resposta no hauria de dependre de recordar què va passar en una conversa. S’ha de poder reconstruir des de registres verificables.

Com ho plantejaria Nicolás Torres

Per a Nicolás Torres, el control d’agents IA comença abans de connectar-los a eines. La pregunta inicial no és “què pot automatitzar l’agent”, sinó “quina identitat, dades i permisos heretarà”.

L’enfocament seria:

1. Mapar l’entorn: repositoris, eines, dades, credencials, accions externes i responsables.
2. Classificar riscos: baix, mitjà o alt segons impacte, reversibilitat, sensibilitat i escala.
3. Definir permisos mínims: lectura, escriptura, xarxa i eines només on aporten valor.
4. Separar identitats: usuaris humans, comptes de servei i automatitzacions no s’haurien de barrejar sense criteri.
5. Dissenyar aprovacions: tota acció externa, irreversible o sensible ha de tenir revisió humana.
6. Registrar activitat: ordres, canvis, tool calls, decisions, usuari i resultat.
7. Provar escenaris d’abús: no per ensenyar a atacar, sinó per comprovar que els límits funcionen.
8. Revisar periòdicament: permisos, logs, excepcions, campanyes, integracions i accessos actius.

Un agent IA ben governat pot augmentar productivitat sense convertir l’entorn de treball en una caixa negra. La confiança no hauria de venir d’assumir que l’agent “es portarà bé”. Hauria de venir de límits tècnics, revisió humana i traçabilitat suficient per saber què va passar, qui va autoritzar cada acció i com aturar el flux si alguna cosa es desvia.

La potència d’aquests agents és real. Precisament per això cal tractar-los com una part seriosa del sistema operatiu de l’empresa.

Preguntes freqüents

Per què cal controlar agents IA com Codex?

Perquè poden treballar sobre repositoris, arxius, terminals, eines externes i dades de l'organització. Si tenen massa permisos, un error o compromís pot convertir-se en accions reals fetes amb la nostra identitat.

Quin risc apareix si un agent IA és compromès?

Pot facilitar canvis no autoritzats, fuga de dades, enviaments externs, manipulació de sistemes, campanyes massives o accions que semblin executades per una persona o empresa legítima.

N'hi ha prou amb escriure bones instruccions al prompt?

No. Les instruccions ajuden, però els límits crítics han d'estar en permisos, sandboxing, aprovació humana, eines acotades, logs, revisió i polítiques d'accés.

Quins permisos hauria de tenir un agent IA de treball?

Només els necessaris per a la tasca concreta: lectura o escriptura limitada al workspace, xarxa desactivada o allowlist, secrets fora d'abast, eines específiques i aprovació per a accions sensibles.

Com es detecta ús indegut d'un agent IA?

Amb registres d'activitat, traçabilitat d'ordres i eines, revisió de canvis, alertes sobre accions inusuals, separació d'identitats i capacitat de revocar accessos ràpidament.