Example: Process-Level Execution Mediation¶

Every enforcement mechanism in Genesis Mesh up to v0.44 operates at the application layer: BoundaryEngine evaluates gates, IBCTs constrain capabilities, JustificationProofs record decisions. But a compromised agent process can bypass all of this through direct subprocess invocations that never pass through any authorization gate.

arXiv:2605.14932 (Pirch, 2026) argues that application-layer enforcement is structurally insufficient: “the mediator must be non-agent — a deterministic process that does not itself reason, cannot be persuaded, and enforces constraints mechanically.”

v0.45 introduces GenesisGuard: a local enforcement sidecar that sits between the agent process and subprocess execution. It validates authorization artifacts (BoundaryDecision, IBCT) cryptographically before spawning any subprocess, and issues a signed MediatedExecutionReceipt as proof that mediation occurred.

Critical: Advisory Mode vs. Mandatory Mediation Mode¶

Read this before deploying GenesisGuard.

GenesisGuard operates in one of two deployment modes:

Advisory mode¶

The agent may route execution through GenesisGuard, but also has direct subprocess access. Every mediated execution is receipted. Unmediated executions are not blocked.

Advisory mode does NOT prevent bypass. An adversarial or compromised agent can trivially bypass the guard by not using it. Advisory mode is useful for development, observability, and partial audit coverage — not for security enforcement.

Mandatory mediation mode¶

The agent process has no direct path to subprocesses, tool credentials, or network APIs. All execution is routed exclusively through GenesisGuard.

A deployment is GenesisGuard-enforced only if ALL of the following hold:

Agents cannot spawn subprocesses directly (no subprocess module access)
Agents cannot access network/tool credentials directly (credentials held by GenesisGuard or a guarded broker, not by the agent process)
All execution receipts reference a valid BoundaryDecision or IBCT ID
Unmediated execution attempts are logged as policy violations and blocked
The deployment operator has verified that no bypass path exists (e.g., via a sandbox audit or process restriction policy)

Calling a deployment “GenesisGuard-enforced” when it is only in advisory mode is misleading and provides a false security guarantee.

What GenesisGuard covers (and does not cover)¶

GenesisGuard provides enforcement below the agent process, above the OS.

Layer	Covered by GenesisGuard
Application gate (BoundaryEngine)	Yes — validated before spawn
Agent identity (IBCT bearer)	Yes — the request must carry the agent’s signed token
IBCT budget + expiry	Yes — validated before spawn
Subprocess environment	Yes — only `allowed_env_vars` inherited
Command allowlist	Yes — required, and matched against the whole command
OS kernel hooks	No — requires eBPF/kernel module outside this scope
Hardware attestation	No — requires TPM/TEE, outside this scope
Agent source code verification	No — attestation handled by v0.40

Step 1 — Start the GenesisGuard daemon¶

genesis-mesh trust guard start \
    --guard-sovereign guard-1 \
    --signing-key keys/guard.key \
    --port 8700 \
    --token-issuer-key 'operator-a=keys/operator.pub.b64' \
    --command-allowlist 'python --version' \
    --command-allowlist 'python /opt/report.py ...'

[OK] GenesisGuard listening on 127.0.0.1:8700
     Press Ctrl-C to stop.

In production, run as a systemd service or OS-managed process. The guard process itself must not be spawnable by agent code.

The command allowlist is mandatory¶

--command-allowlist is required and may be given more than once. The guard refuses to start without it — there is no “allow everything” default, and an empty allowlist denies every request rather than permitting them.

Each entry is a full command line, not a program name, and is matched against the whole subprocess_command:

Entry	Matches
`python --version`	exactly `["python", "--version"]`
`python /opt/report.py ...`	`["python", "/opt/report.py", …]` with any tail
`python`	exactly `["python"]` — not `python -c '…'`

A trailing ... makes the entry a prefix rule: the fixed tokens must match the head of the command and the remaining arguments are unconstrained. A prefix rule must carry at least two fixed tokens; python ... is rejected at start-up because matching a program name alone is precisely what this check exists to prevent.

Warning. A prefix rule whose fixed part ends in an interpreter’s code-taking flag — python -c ..., sh -c ... — permits arbitrary code through that interpreter. The guard logs a warning when it sees one. Name the script instead.

An entry cannot express a literal trailing ... argument; quoting does not distinguish it from the sentinel.

The invocation token is mandatory¶

--token-issuer-key maps an issuer_sovereign_id to the public key(s) that issuer signs invocation tokens with, and may be given more than once. A token whose issuer_sovereign_id has no entry is rejected with unknown_token_issuer — an unknown issuer is never trusted by default.

This is what tells the guard whose request it is holding. A BoundaryDecision carries no agent field and no capability field: on its own it proves that some execution was approved, not that this agent was the one approved. The InvocationToken names its bearer and its capabilities, so the guard rejects a request whose token was issued to someone else with token_bearer_mismatch.

The token and the decision must also name the same agreement_id, or the request is rejected with token_agreement_mismatch. Without that check an agent could pair its own valid token with an unrelated valid decision.

The budget is per guard process. max_invocations is counted in memory, keyed by token_id, and the count resets when the guard restarts. The guard makes no network calls by design, so it also cannot see revocations: a revoked token remains usable until its expires_at passes. Keep token lifetimes short.

Step 2 — Request mediated execution (agent side)¶

genesis-mesh trust guard request \
    --capability run-python \
    --decision boundary-decision.json \
    --token invocation-token.json \
    --command python -- analyze.py \
    --signing-key keys/agent.key \
    --socket-host 127.0.0.1 \
    --socket-port 8700 \
    --output receipt.json

[OK] MediatedExecutionReceipt 7a3c9f12-...
     Capability : run-python
     PID        : 12345
     Exit code  : 0

Step 3 — Verify the receipt¶

genesis-mesh trust guard verify \
    --receipt receipt.json \
    --guard-key "$(cat keys/guard.pub.b64)"

[OK] valid — 7a3c9f12-...

Use in code¶

from genesis_mesh.guard.daemon import GenesisGuardDaemon
from genesis_mesh.trust.mediation import validate_mediation_request
from genesis_mesh.models.mediation import MediatedExecutionReceipt

# Start the guard daemon (in a separate managed process in production)
daemon = GenesisGuardDaemon(
    guard_sovereign_id="guard-1",
    signing_key=guard_signing_key,
    decision_store={decision.decision_id: decision},
    agent_public_keys={"agent-a": [agent_pub_key_b64]},
    operator_public_keys={"operator-a": [operator_pub_key_b64]},
    token_issuer_public_keys={"operator-a": [operator_pub_key_b64]},
    command_allowlist=["python --version"],
    host="127.0.0.1",
    port=8700,
)
daemon.start()

# Direct call (without socket, for testing or in-process use):
result = daemon.handle_request(request)
if isinstance(result, MediatedExecutionReceipt):
    print(f"Mediated PID={result.subprocess_pid} exit={result.subprocess_exit_code}")

Rejection reasons¶

Reason	Cause
`invalid_request_signature`	Ed25519 verification failed for the request
`decision_not_found`	`decision_id` not in guard’s store
`invalid_decision_signature`	Decision unsigned, or not signed by a key the guard holds for its `operator_sovereign_id`
`decision_expired`	`decision_valid_until` is in the past
`capability_not_authorized`	Decision `authorized=False`, or capability not in IBCT
`missing_invocation_token`	The request carried no `invocation_token` — the token is required
`token_id_mismatch`	The request’s legacy `token_id` field disagrees with the carried token
`unknown_token_issuer`	No key held for the token’s `issuer_sovereign_id`
`invalid_token_signature`	Token unsigned, or not signed by a key the guard holds for its issuer
`token_bearer_mismatch`	The token’s `bearer_sovereign_id` is not the requesting agent
`token_agreement_mismatch`	Token and decision name different `agreement_id`s
`token_policy_violated`	A token policy constraint (e.g. time window) was not met
`token_expired`	IBCT `expires_at` is in the past
`token_budget_exhausted`	IBCT `max_invocations` reached for this guard process
`command_not_in_allowlist`	The full `subprocess_command` matches no allowlist entry (also returned when no allowlist is configured)
`subprocess_blocked`	Spawn failed (timeout, OS error, etc.)

Non-LLM property¶

GenesisGuard is a deterministic Python process. It does not call any LLM, does not reason about requests, and enforces constraints mechanically. This satisfies the Pirch (arXiv:2605.14932) requirement that “the mediator must be non-agent.”