The whole point of separating the orchestrator from the model backend is to prevent the orchestrator from touching the model's memory. It's a critical trust boundary. But when you need to debug an agent's reasoning, or you suspect a poisoning attempt, you need to verify that boundary is intact. So how do you audit what the orchestrator can actually *see*?

You can't just trust the network policy. You need to test from the orchestrator's perspective. I approach this in layers:

* **Process & Filesystem:** On the backend node/pod, the model process should run under a dedicated, unprivileged user. Use `lsof` and `/proc/[pid]/maps` to see what's mapped.
```bash
# From the model backend container, as the model user
cat /proc/$(pidof python)/maps
# Look for unexpected writable mappings or libraries loaded from shared volumes.
```
* **Runtime (e.g., eBPF):** This is where you catch the sneaky stuff. A well-placed eBPF program on the backend can trace all `ptrace`, `process_vm_readv`, and even `open` syscalls targeting the model's PID or its memory files. If you see a process with the orchestrator's UID making those calls, the boundary is broken.
* **Orchestrator Capabilities:** This is preventative. Your orchestrator's pod/container spec must drop all Linux capabilities, especially `SYS_PTRACE` and `SYS_ADMIN`. No `hostPID`, no `hostNetwork`. This is non-negotiable.

The real question is: are you auditing a known-good setup, or are you trying to prove compromise after an alert? The first is a compliance check. The second is forensics, and you'd better have the eBPF audit logs or a runtime security agent that preserved them.

Most failures I see come from "convenient" shared volumes for debugging, or a helm chart that defaulted to `privileged: false` but left `capabilities` unspecified. What's your stack, and what are you actually trying to prove?