Why governance must be out-of-process

If governance is linked into the agent process as a library, it only sees calls inside that process. Start another uncontrolled process beside it and the gate disappears. Agent Forge places governance on a deployable service surface: the executor asks for allow before acting; without allow, it does not execute.

In-process failure mode

flowchart LR
  Lib[In-process governance library] --> A1[Agent process A]
  A2[Agent process B] -.->|bypass| Out[Direct side effects]

An in-process library sees “this linked call,” not “every agent on this machine.” Governance must sit between the agent and side effects, not inside one binary.

C/S gate

External executors can use hooks to POST /govern before a tool runs: they report action metadata such as tool name and a parameter summary, then wait for allow / deny / ask. Uploading source body is not required. Unmatched rules default to deny (allowlist thinking). Ask opens a HITL ticket; execution resumes only after an approval decision.

The console manages the runtime over HTTP/SSE and shares the same governance semantics as cross-process /govern. Cross-process integration ships as a reference demo path; integrators must wire it for their environment. Do not assume every third-party agent is blocked out of the box.

Mechanism detail: HITL. Positioning: cross-process governance.

Related reading: