Far lavorare agenti AI dentro i sistemi di una banca è un rischio operativo e di supply-chain (DORA terze parti ICT, NIS2). La risposta di CATALYST non è gestire una grande superficie agentica: è ridurla. Lavoro deterministico, tool nativi e in lettura, un verifier che non può scrivere, distribuzione chiusa. Meno superficie significa meno da difendere — e meno da spiegare a un supervisore. Aggiornato a giugno 2026, deep-linkable per CISO, Head of SecOps e auditor esterni.
Non sono raccomandazioni per blindare server di terzi: sono il modo in cui il framework è costruito. Determinismo dove conta, permessi minimi, perimetro di scrittura in whitelist, distribuzione chiusa — codificati in hook e nel frontmatter degli agenti, non lasciati al runtime.
I gate e i controlli sono script deterministici (grep, AST, JSON Schema, build), non tool-call di un agente: riproducibili e senza superficie di tool-use da difendere. L'LLM interviene solo dove serve interpretazione.
L'agente di verifica ha permessi di sola lettura (Read · Glob · Grep): legge e segnala, non scrive. Non può correggere — né compromettere — il codice che giudica.
Gli agenti modificano solo i path autorizzati (hook check-write-perimeter); il codice legacy è montato read-only. Nessuna scrittura fuori perimetro, nemmeno per errore.
La pipeline usa i tool nativi del runtime (Read/Glob/Grep/Bash). MCP è usato solo in lettura (Context7) per consultare documentazione tecnica aggiornata: nessun server MCP operativo sul critical path, quindi nessuna flotta da blindare.
CATALYST gira in immagine Docker chiusa: nessun file del framework sul filesystem del cliente, workspace montato via volume, marketplace privato. Superficie e proprietà intellettuale restano contenute.
Ogni decisione, eccezione e bypass (bypass.yaml) è tracciato; log strutturato e SIEM-compatibile, retention pluriennale — allineato a DORA Art. 9 e AI Act Art. 12.
Trattata come rischio strutturale, non come singola CVE: la superficie ridotta è la prima difesa. Dove un tool deve raggiungere endpoint esterni, sandbox + least privilege + allowlist, con threat intelligence continua (CERT-AgID, OX Security).
Lo standard MCP è ormai centrale per l'AI agentica, ma l'ecosistema intorno è acerbo e accumula vulnerabilità. La nostra conclusione non è gestire quella superficie: è non averla.
Il pattern STDIO degli SDK MCP ha mostrato debolezze design-level (disclosure OX Security, apr. 2026); CERT-AgID (apr. 2026) documenta scenari SSRF e proxy abuse via server MCP mal configurati. Le CVE sull'agentic tooling si accumulano.
CATALYST non blinda una flotta di server MCP — non la usa. La prima difesa è non avere la superficie: tool nativi, controlli deterministici, MCP solo in lettura per la documentazione.
Far toccare codice, build e dati a un agente è rischio terze parti ICT (DORA) e di supply chain (NIS2). Una superficie minima, a least-privilege e auditata è la risposta difendibile davanti a CISO e supervisore.