eBPF 백스톱은 비협력적 기반 진실 옵저버입니다. 커널 시스콜 트레이스포인트에 연결하고 어떤 유저스페이스 에이전트도 회피, 비활성화, 왜곡할 수 없는 접근 맵 에지로 파일 및 네트워크 I/O를 보고합니다. 협력적 텔레메트리가 에이전트가 정직하게 보고하는 것을 신뢰하는 반면, 백스톱은 신뢰하지 않습니다 — 에이전트가 아닌 커널을 감시합니다.
일반적인 소스 모델과 OLIVARES_SOURCES_CONFIG 구조는 소스 연결을 참조하세요. 백스톱이 보완하는 협력적 경로는 Claude Code 연결을 참조하세요.
관찰하는 것
백스톱은 커널 수준 시스콜을 계측합니다 — open, read, write, connect, sendto, recvfrom 및 변형 — 관련 I/O 이벤트당 하나의 관찰을 출력합니다. 읽기/쓰기 분류는 에이전트가 주장하는 것이 아닌 시스콜 자체에서 나오므로, pgAudit의 READ/WRITE 클래스가 권위적인 것과 같은 방식으로 권위적입니다: 커널이 작업을 수행했으므로 작업이 발생했습니다.
결과는 호스트의 프로세스 신원에 파일 및 네트워크 I/O를 귀속시키는 접근 맵 에지 스트림입니다. 이 에지는 다른 모든 소스와 동일한 접근 맵을 공급합니다.
존재하는 이유
협력적 텔레메트리 — OpenTelemetry 내보내기, 후크 페이로드, MCP 인트로스펙션 — 은 더 풍부하고 상위 수준이지만 협력적입니다: 에이전트가 출력합니다. OTel 내보내기를 비활성화한 에이전트나 처음부터 없던 런타임은 협력적 신호를 전혀 생성하지 않습니다.
eBPF 백스톱은 이 갭을 닫습니다. 텔레메트리 내보내기를 중단한 에이전트도 여전히 시스콜을 만듭니다; 커널은 여전히 봅니다; 백스톱은 여전히 보고합니다. 이것이 Claude Code 연결 문서가 참조하는 기반 진실입니다:
진정으로 비협력적인 활동에 대한 기반 진실은 이 휴리스틱이 아닌 커널/eBPF 백스톱입니다.
그 휴리스틱 — 후크가 여전히 발동하는 동안 OTel 출력을 중단하는 세션 감지 — 은 협력 측 이상 신호입니다. 백스톱은 비협력 측을 관찰 가능하게 만듭니다.
커버리지 계층
백스톱은 충실도 모델에서 clean 계층입니다. 읽기 vs 쓰기는 에이전트가 주장하는 것이 아닌 시스콜에서 결정됩니다. 충실도 문서는 pgAudit 및 CloudTrail과 함께 나열합니다: “커널 수준 eBPF 기반 진실.” clean 커버리지가 clean 귀속을 의미하지는 않습니다 — 아래 한계를 참조하세요.
협력적 관찰 vs 사용 시기
합성됩니다; 대체하지 않습니다.
- 협력적 (OTel, 후크, MCP) — 상위 수준 컨텍스트: 세션, 도구, 모델, 비용. 더 풍부한 맵.
- 비협력적 (eBPF) — 회피 방지 보장: 에이전트가 보고하기로 선택한 것에 관계없이 커널 수준에서 실제로 발생한 것.
둘 다 실행하세요. 협력적 경로는 거버넌스하는 풍부한 맵을 구축합니다. 백스톱은 협력적 경로가 놓친 것 — 회피, 잘못된 구성, 텔레메트리 없는 런타임 — 을 잡는 위조 불가능한 바닥을 제공합니다.
배포 모델
백스톱은 에이전트가 실행되는 각 호스트에서 실행되며, pgaudit, s3cloudtrail, runtime, mcp, claude와 함께 소스 종류 ebpf로 기본 serve에 배선됩니다. eBPF 프로그램이 호스트 커널에 연결되므로, 호스트당 하나의 인스턴스가 모든 에이전트 프로세스를 커버합니다. 에이전트별 설치 단계는 없습니다.
Linux 기능
eBPF 트레이싱은 상승된 커널 권한이 필요합니다. 최소한, eBPF 프로그램을 로딩하는 프로세스는 CAP_BPF 및 CAP_PERFMON 계열(또는 동등한, 커널 버전에 따라 — 이전 커널은 이를 CAP_SYS_ADMIN으로 통합)의 기능이 필요합니다.
:::caution
정확한 기능 세트는 커널 버전, 배포판, 보안 모듈(AppArmor, SELinux)에 따라 다릅니다. 필요한 정확한 플래그는 커넥터 자체의 문서를 확인하세요 — 이 페이지는 환경마다 다르므로 확정적인 세트를 나열하지 않습니다. 컨테이너에서 실행하려면 명시적 기능 부여(그리고 가능하면 BPF 파일시스템 마운트)가 필요합니다; 잠긴 Kubernetes 파드는 securityContext 재정의가 필요합니다.
:::
구성
다른 모든 커넥터와 동일한 소스 항목 구조를 사용하여 OLIVARES_SOURCES_CONFIG에서 kind: "ebpf"를 선택하세요:
{
"sources": [
{
"name": "host-backstop",
"kind": "ebpf",
"tenant": "acme",
"config": {}
}
]
}
정확한 config 키는 커넥터가 소유합니다; 검증되지 않은 스키마를 복사하지 말고 디스크립터를 읽으세요. 위의 config 객체는 의도적으로 비어 있습니다 — 이 페이지는 소스 연결과 같은 규칙을 따릅니다: 검증한 키만 문서화하며, 이 웹 문서에서 eBPF 커넥터의 구성 표면을 검증하지 않았습니다.
회피 방지 속성
백스톱은 에이전트 협력에 의존하지 않습니다:
- OTel 내보내기를 비활성화한 에이전트도 여전히 커널 시스콜을 생성합니다 — 백스톱이 이를 봅니다.
- 협력적 텔레메트리에서 거짓말하는 에이전트는 커널에 거짓말할 수 없습니다. 시스콜 레코드가 권위적입니다.
readOnlyHint/destructiveHint를 잘못 보고하는 MCP 서버는 백스톱이 관찰하는 것에 영향을 주지 않습니다 — 소비하지 않는 협력적 신호입니다.
Claude Code 연결의 협력 측 휴리스틱 — 후크가 계속 발동하는 동안 OTel이 침묵하는 세션 — 은 감지 신호입니다. 백스톱은 그 신호가 가리키는 기반 진실입니다.
정직한 한계
백스톱은 커널이 보는 것을 관찰하며, 에이전트가 의도하는 것이 아닙니다. 이 구분이 중요합니다:
- 귀속은 프로세스 수준입니다. I/O는 프로세스 신원(PID, UID, 바이너리 경로)에 귀속됩니다. 여러 에이전트가 하나의 프로세스를 공유하면 백스톱은 접근을 분리할 수 없습니다 — 귀속은
firm이 아닌approximate입니다. 에이전트별 귀속은 에이전트별 신원 신호가 필요합니다; 충실도를 참조하세요. - 세션이나 도구 컨텍스트 없음. 백스톱은 세션이나 도구 이름이 아닌 시스콜을 봅니다. 어떤 도구 호출이 파일 쓰기를 트리거했는지 알려줄 수 없습니다 — 프로세스가 파일을 썼다는 것만. 협력적 경로가 그 컨텍스트를 전달합니다.
- 커널 버전 의존성. eBPF 트레이스포인트 가용성은 커널 버전에 따라 다릅니다. 커넥터 자체의 문서에서 최소 커널 버전을 확인하세요.
- 페이로드 내용 없음. 모든 소스와 마찬가지로, 백스톱은 식별자와 읽기/쓰기 분류를 출력하며, 파일 내용이나 네트워크 페이로드를 출력하지 않습니다.
관련 항목
- 소스 연결 — 일반적인 소스 모델과 구성 파일.
- Claude Code 연결 — 백스톱이 보완하는 협력적 경로.
- 커버리지 및 귀속 충실도 — clean/lossy/opaque 및 firm/approximate/unknown 축.
- 접근 맵 — 이 관찰이 구축하는 것.