What is pre-execution action enforcement?

An agent action passes through a fixed sequence, and each stage offers a different amount of information and a different amount of leverage.

Only the third row has both properties at once — full information and full reversibility. Earlier, you do not yet know what you are ruling on. Later, you are describing something that already happened. That narrow window is what "post-reasoning, pre-execution" names, and it is where a control has to sit to actually be a control.

At the interception point, the action is a fully-specified object rather than an intention. That is what makes deterministic evaluation possible. A pre-execution check has access to:

• The operation. Which tool, which specific operation on it, and the parameters — including the ones that determine blast radius, like the value on a payment or the scope of a delete.
• The target. Which system of record is about to be written to, and how that system is classified.
• The identities. Which agent is acting, and which person or workflow it is acting on behalf of. Both, because Segregation of Duties is a statement about who.
• The history. What this agent and this human have already done in the workflow, which is what makes "did you raise the invoice you are now approving" answerable.
• The scope. The action surface mapped and classified for this agent at design time, which the operation is compared against.

The evaluation is a comparison, not an inference. That keeps it fast — safe actions clear without perceptible latency, because checking whether an operation falls inside a pre-computed scope is a lookup rather than an analysis performed from scratch.

A binary control forces every policy into a choice between blocking legitimate work and permitting risk, so a third outcome does most of the useful work in practice.

Allow. The operation is inside scope and no threshold applies. It proceeds with the decision recorded. The overwhelming majority of actions land here, which is the point: governance that stops everything is not governance an organisation keeps running.

Block. The operation is outside the agent's scope, or crosses a boundary that has no legitimate exception — an agent approving its own invoice, a coding agent attempting a production drop. The call does not execute and the attempt is recorded.

Escalate. The operation is inside scope but above a threshold or inside a class requiring human authority. The action is held — not queued behind an action that already completed — and routed to the named approver for that scope. It resumes on approval, or is denied. This is where deterministic policy and human judgement meet: the rule about when to escalate is fixed, and the decision itself stays with an accountable person.

The most common architecture in the market observes agent behaviour, scores it, and alerts. That model is borrowed from security monitoring, where it works, and it transfers badly here for a reason worth being precise about.

Security monitoring assumes a response window. An anomalous login can be investigated and the session terminated because compromise takes time to convert into damage. An agent action has no such window: the tool call completes in milliseconds and the effect is immediate and often irreversible. The payment settles. The record is deleted. The email leaves. By the time a score is computed and a human reads the alert, there is nothing left to decide.

So a log line saying an agent deleted a production database is evidence, not a control. It may be useful evidence. It is not the thing that was supposed to prevent the outcome, and an auditor asking who authorized that action will not accept it as one.