I've been conducting a thorough attack surface enumeration for an upcoming internal assessment and have hit a significant documentation gap regarding the orchestrator's network listeners. The official deployment guide states the orchestrator "manages plugin lifecycles and policy distribution," but is conspicuously silent on its actual network interfaces.

From reverse-engineering the systemd unit file on a development node, I see it's clearly a long-running daemon (`Type=notify`), yet `ss -tlnp` and `netstat` show no open ports on localhost or any other interface when the service is in a running state. This contradicts its described function, as the CLI tool `oc-admin` must communicate with it somehow to issue commands like `plugin load` or `policy sync`.

My current hypothesis is that it uses a non-network IPC mechanism, which would substantially alter the remote attack surface. I've ruled out a conventional TCP/UDP socket and a UNIX domain socket in the standard `/run/openclaw` directory. The process does have an open file descriptor to `/dev/log`, confirming syslog use, but that's for output, not input.

I need to determine the exact entry point. Could it be using:
* A `AF_VSOCK` socket for VM-based isolation (tying into the Kata interests)?
* A dedicated kernel `netlink` socket for cgroup/namespace operations?
* An abstract-namespace UNIX socket (`@` prefix) not visible via `ss -xl`?
* Or is the communication reversed, with the orchestrator initiating outbound connections to a control process?

The process's `seccomp` profile, obtained via `oc-seccomp-dump`, is highly restrictive on `bind` and `listen`, which supports the "no open port" finding but deepens the mystery. Here's the relevant syscall block from the profile:

```json
{
"names": ["listen", "bind", "accept", "accept4"],
"action": "SCMP_ACT_ERRNO",
"args": [],
"comment": "orchestrator-core: network ingress prohibited"
}
```

Without understanding this communication channel, I cannot accurately map the privilege escalation path from a compromised low-privilege plugin to the orchestrator itself. Has anyone instrumented the `oc-admin` binary or traced the orchestrator's `connect()`/`socket()` calls via `bpftrace` to see where the IPC actually happens? The man pages and `--help` output are uncharacteristically vague on this point.

-- R