Collegare il backstop eBPF

Il backstop eBPF e l’osservatore di ground truth non cooperativo. Si aggancia ai tracepoint delle syscall del kernel e riporta l’I/O su file e rete come archi della mappa degli accessi che nessun processo userspace può eludere, disabilitare o falsificare. Dove la telemetria cooperativa si fida dell’agente per riportare onestamente, il backstop no — osserva il kernel, non l’agente.

Per il modello sorgente generale e la struttura di OLIVARES_SOURCES_CONFIG, vedi Collegare una sorgente. Per il percorso cooperativo che il backstop complementa, vedi Collegare Claude Code.

Cosa osserva

Il backstop strumenta syscall a livello kernel — open, read, write, connect, sendto, recvfrom e le loro varianti — ed emette un’osservazione per ogni evento I/O rilevante. La classificazione lettura/scrittura proviene dalla syscall stessa, non da ciò che l’agente dichiara, quindi è autorevole allo stesso modo in cui la classe READ/WRITE di pgAudit è autorevole: il kernel ha eseguito l’operazione, quindi l’operazione e avvenuta.

Il risultato è un flusso di archi della mappa degli accessi che attribuiscono l’I/O su file e rete a un’identità di processo sull’host. Questi archi alimentano la stessa mappa degli accessi di ogni altra sorgente.

Perché esiste

La telemetria cooperativa — esportazioni OpenTelemetry, payload degli hook, introspezione MCP — e più ricca e di livello superiore, ma è cooperativa: e l’agente che la emette. Un agente che disabilita il suo esportatore OTel, o un runtime che non ne ha mai avuto uno, non produce alcun segnale cooperativo.

Il backstop eBPF colma quella lacuna. Un agente che smette di esportare telemetria continua a fare syscall; il kernel continua a vederle; il backstop continua a riportarle. Questa è la ground truth a cui fa riferimento la documentazione di Collegare Claude Code:

La ground truth per attività genuinamente non cooperativa e il backstop kernel/eBPF, non questa euristica.

Quell’euristica — rilevare una sessione che smette di emettere OTel mentre i suoi hook continuano a scattare — e un segnale di anomalia lato cooperativo. Il backstop rende osservabile il lato non cooperativo.

Livello di copertura

Il backstop e di livello clean nel modello di fedeltà. Lettura vs scrittura e determinata dalla syscall, non da ciò che l’agente dichiara. La documentazione sulla fedeltà lo elenca insieme a pgAudit e CloudTrail: “la ground truth eBPF a livello kernel”. Copertura clean non implica attribuzione clean — vedi i limiti sotto.

Quando usarlo vs osservazione cooperativa

Si compongono; non si sostituiscono a vicenda.

• Cooperativo (OTel, hook, MCP) — contesto di livello superiore: sessioni, tool, modelli, costi. La mappa più ricca.
• Non cooperativo (eBPF) — la garanzia anti-evasione: ciò che è effettivamente accaduto a livello kernel, indipendentemente da ciò che l’agente ha scelto di riportare.

Eseguili entrambi. Il percorso cooperativo costruisce la mappa ricca su cui governi. Il backstop fornisce il livello minimo non falsificabile che cattura qualsiasi cosa il percorso cooperativo abbia mancato — evasione, configurazione errata, o un runtime senza telemetria.

Modello di deployment

Il backstop gira su ogni host dove gli agenti eseguono, cablato nel serve standard come kind di sorgente ebpf insieme a pgaudit, s3cloudtrail, runtime, mcp e claude. Poiché i programmi eBPF si agganciano al kernel dell’host, una singola istanza per host copre ogni processo agente. Non c’e nessun passaggio di installazione per agente.

Capabilities Linux

Il tracing eBPF richiede privilegi kernel elevati. Come minimo, il processo che carica i programmi eBPF necessita di capabilities nella famiglia CAP_BPF e CAP_PERFMON (o equivalenti, a seconda della versione del kernel — kernel più vecchi le raggruppano in CAP_SYS_ADMIN).

:::caution L’esatto set di capabilities dipende dalla versione del kernel, dalla distribuzione e dal modulo di sicurezza (AppArmor, SELinux). Verifica la documentazione propria del connettore per i flag precisi richiesti — questa pagina non elenca un set definitivo perché varia tra gli ambienti. L’esecuzione in un container richiede concessioni esplicite di capabilities (e possibilmente un mount del filesystem BPF); un pod Kubernetes blindato necessita di override nel securityContext. :::

Configurazione

Seleziona kind: "ebpf" in OLIVARES_SOURCES_CONFIG, usando la stessa struttura di voce sorgente di ogni altro connettore:

{
  "sources": [
    {
      "name": "host-backstop",
      "kind": "ebpf",
      "tenant": "acme",
      "config": {}
    }
  ]
}

Le esatte chiavi di configurazione sono di proprietà del connettore; leggi il suo descrittore anziché copiare uno schema non verificato. L’oggetto config sopra e intenzionalmente vuoto — questa pagina segue la stessa regola di Collegare una sorgente: documentiamo solo chiavi che abbiamo verificato, e non abbiamo verificato la superficie di configurazione del connettore eBPF da questa documentazione web.

Proprietà anti-evasione

Il backstop non dipende dalla cooperazione dell’agente:

• Un agente che disabilita il suo esportatore OTel genera comunque syscall kernel — il backstop le vede.
• Un agente che mente nella sua telemetria cooperativa non può mentire al kernel. Il record della syscall è autorevole.
• Un server MCP che falsifica readOnlyHint / destructiveHint non influisce su ciò che il backstop osserva — quelli sono segnali cooperativi che non consuma.

L’euristica lato cooperativo in Collegare Claude Code — una sessione il cui OTel diventa silenzioso mentre gli hook continuano a scattare — e un segnale di rilevamento. Il backstop è la ground truth a cui quel segnale punta.

Limiti onesti

Il backstop osserva ciò che il kernel vede, non ciò che l’agente intende. Quella distinzione conta:

• L’attribuzione è a livello di processo. L’I/O viene attribuito a un’identità di processo (PID, UID, percorso del binario). Se più agenti condividono un processo, il backstop non può separare i loro accessi — l’attribuzione e approximate, non firm. L’attribuzione per agente richiede un segnale di identità per agente; vedi Fedeltà.
• Nessun contesto di sessione o tool. Il backstop vede syscall, non sessioni o nomi di tool. Non può dirti quale tool-call ha attivato una scrittura su file — solo che il processo ha scritto il file. Il percorso cooperativo porta quel contesto.
• Dipendenza dalla versione del kernel. La disponibilità dei tracepoint eBPF varia tra le versioni del kernel. Conferma la versione minima del kernel rispetto alla documentazione propria del connettore.
• Nessun contenuto del payload. Come ogni sorgente, il backstop emette identificatori e una classificazione lettura/scrittura, mai contenuti di file o payload di rete.

Correlati

• Collegare una sorgente — il modello sorgente generale e il file di configurazione.
• Collegare Claude Code — il percorso cooperativo che il backstop complementa.
• Copertura e fedeltà dell’attribuzione — gli assi clean/lossy/opaque e firm/approximate/unknown.
• La mappa degli accessi — ciò che queste osservazioni costruiscono.