Pre-execution governance evaluates a proposed operation before the effect being governed can occur and requires a control point able to apply the resulting decision to that operation.
This is an operational definition. “Before” refers to the protected effect, not necessarily to model inference, tool selection, or every earlier message. A service may have received a request while retaining the ability to withhold the resource change that request proposes.
The decision needs a concrete object
The evaluator needs enough reliable context to identify the operation being governed: its material targets, inputs, acting identity, and applicable authorization conditions. An initial instruction or tool name may not supply those facts. Evaluating a general intention is not the same as evaluating the operation that follows.
The executor must also establish which proposal the decision covers. If material arguments or targets change, the earlier decision may no longer apply. A shared task or session identifier does not, by itself, establish that correspondence.
The control must still be able to affect execution
Evaluation alone can produce a recommendation or record. A pre-execution control needs a connection that can withhold the protected operation, allow the scoped attempt, or retain a pending state when applicable approval is required. Changing a proposal is another possible intervention where the implementation supports it; the changed operation still needs appropriate authorization.
OWASP's Transaction Authorization Cheat Sheet describes a final authorization gate tied to transaction execution. That supports the connection between authorization and the operation carried out. It does not prescribe one architecture or require human approval for every agent operation.
The boundary is specific to the effect
Holding a later operation cannot prevent an earlier disclosure. Likewise, a decision covering a call does not automatically establish control over every operation a tool performs internally. State which effect the control can withhold and what remains outside that point.
Failure and pending behavior also need to be defined. The category name does not establish whether execution stops when evaluation is unavailable. Permission to attempt an operation does not guarantee success, and a recorded denial does not alone prove that the executor withheld the effect.
Pre-execution governance identifies a particular boundary within runtime AI governance. A tool call describes a request through an interface; the protected effect and its application point must be identified separately.
The pre-execution governance guide develops these distinctions for concrete targets, changed proposals, batches, and partial results.