q15-exec

q15-exec owns command execution. When the agent needs to run a shell command, build a project, or install a package, it sends the request to q15-exec over gRPC at :50051.

Why a separate execution service?

If the agent and the shell lived in the same process, a compromised prompt would have direct access to the host. By moving execution into a separate service, q15 creates a boundary: the agent can request commands, but the exec service controls how they run. See Harness Engineering for why this separation matters.

Nix-powered execution

Commands run through nix shell. This means any package from nixpkgs is available on demand without rebuilding the container image. Need git? curl? python3? A specific version of go? The exec service fetches it from the Nix store.

The /nix path is persistent. Fetched packages are cached across sessions, so the first run of a package is slower than subsequent runs. Docker named volumes preserve the image’s built-in bootstrap Nix runtime on first use.

# Example: the agent asks exec to run a command with git available
nix shell nixpkgs#git --run "git log --oneline -5"

Session lifecycle

q15-exec supports multiple concurrent sessions within one pod. Session state is held in memory inside that pod. This is why the deployment model keeps one exec pod per stack — it avoids cross-pod session routing complexity and keeps storage ownership local.

Egress routing

q15-exec routes outbound network traffic through q15-proxy at :50052. The agent never talks to the proxy directly. This means the proxy handles credential injection for all outbound requests — the agent can reach the internet, but it does so without holding any secrets itself.

This is not optional

The routing is configured at the deployment level, not by the agent. Even a fully compromised prompt cannot ask q15-exec to bypass the proxy — the exec service always routes egress through q15-proxy:50052. This is what makes credential injection a reliable defense rather than a polite suggestion.

Build isolation

q15-exec intentionally passes --option build-users-group "" to nix shell. This keeps Nix builds on the current container user (expected to be root), because common container seccomp defaults can block execve after Nix drops to nixbld users.

The security boundary for those builds is the container or Kubernetes namespace, not Nix user isolation inside the container.