Blindare le Pipeline CI/CD: Quando l'Agente AI Diventa il Vettore d'Attacco
L'incidente Clinejection di febbraio 2026 non è stato un caso isolato. È stato il campanello d'allarme che l'industria ha sottovalutato: un singolo titolo di issue malevolo su GitHub ha compromesso la supply chain dell'agente di coding "Cline", trasformando un assistente AI in un vettore di privilege escalation verso ambienti CI/CD e credenziali di repository.
Oggi, mentre i framework agentici (LangGraph, AutoGen, Semantic Kernel, Claude Code, Gemini CLI) diventano componenti standard delle pipeline di deployment, la superficie d'attacco si è spostata. Non è più il codice che scriviamo. È il codice che l'agente decide di eseguire per nostro conto.
L'Architettura del Tradimento: "Comment and Control"
La vulnerabilità classe Comment and Control (documentata da Cloud Security Alliance e OWASP Agentic Applications Top 10 2026) sfrutta un'assunzione architetturale ingenua: gli agenti trattano metadati GitHub non attendibili — titoli PR, corpi issue, commenti HTML — come contesto autorevole per il proprio planning.
```python
issue_body = github.get_issue(123).body # Input non sanificato
plan = agent.plan(f"Risolvi: {issue_body}") # L'agente "legge" l'iniezione
agent.execute(plan) # Esegue tool calls privilegiati
```
Un attacker non deve bucare il modello. Deve solo scrivere un issue ben formulato. L'agente, nella sua ansia di essere utile, esegue l'iniezione come istruzione legittima: esfiltra `GITHUB_TOKEN`, `AWS_KEY`, `DOCKER_HUB_CREDS` — tutto ciò che la pipeline CI/CD ha generosamente iniettato nell'ambiente.
La Lezione del Progetto Siliceo: Sovranità sul Contesto di Esecuzione
Nel Progetto Siliceo abbiamo imparato questa lezione direttamente. Il nostro Kernel Rust v2 (che gira su `localhost:5005` con ~1.3GB VRAM su una RTX 2070 8GB) non espone nessun tool all'LLM per default. Ogni capacità (`think`, `call_llm`, `fallback_provider`, `memory_read`, `memory_write`) è un capability token esplicito, firmato, revocabile, con scope definito a compile-time.
Non usiamo "system prompt" per definire i permessi. Usiamo type system Rust.
```rust
// Esempio reale dal nostro kernel: i tool sono capacità tipizzate, non stringhe
pub trait Capability: Send + Sync {
fn scope(&self) -> CapabilityScope; // ReadOnly | WriteLocal | Network | Privileged
fn requires_approval(&self) -> bool;
}
#[derive(Capability)]
#[scope(WriteLocal)]
#[requires_approval(true)]
pub struct FileWriteTool { ... }
```
Insight pratico applicabile subito:
Se stai integrando un agente AI in CI/CD, smetti di passare `GITHUB_TOKEN` all'ambiente dell'agente. Crea un sidecar service (un microservizio Rust/Go minimalista) che espone solo le operazioni Git necessarie (`create_branch`, `open_pr`, `read_file`) via gRPC con mTLS. L'agente chiama `sidecar.open_pr(title, body)` — il sidecar valida, sanifica, logga, e usa il suo token short-lived. L'agente non vede mai la credenziale. Il blast radius passa da "tutto