Out-of-bound acts must be blocked, not reported after the fact

What it is

When an agent walks outside its grant, the right response is that the act does not happen — not that it happens and then a line is written, “out of scope detected.” Out-of-scope acts must be blocked makes the permission boundary an execution switch, not a CCTV camera. The camera is for audit; the gate is for the world boundary.

A report afterwards can satisfy “we have monitoring.” It cannot satisfy “it did not go out.”

Why it happens

Detection and interception are two causal chains. Detection can be read from a log after the act, which is already too late for the world. Interception has to ask, before the tool is called: does this ticket cover this object and this verb. If that question is missing between plan generation and tool execution, a rerouted plan reroutes execution with it. Safety engineering calls this fail-closed; products often build agents fail-open, then lean on operations reading logs.

A report also manufactures the feeling that it was handled: someone saw an alert, therefore someone stopped it. The permission-layer version of a nominal loop.

Studying it

Give the agent a narrow ticket, then induce a call to an out-of-ticket tool or object. Compare three implementations: policy check and reject before execute, alert after execute, log only. Dependent variables: whether the out-of-scope act occurs in the external system, whether people believe it was stopped, latency from the cross to a person seeing it. Independent variables: whether the check sits at plan or tool layer, whether reject causes a replan, whether the alert interrupts.

The primary endpoint is whether the external system has that row, not whether the product has an alert event.

Where it stops holding

If the scope itself is a blanket grant, what you block is the empty set; this entry cannot save that — narrow the grant first. Audit records should still be written after a block, but writing is not a substitute for blocking. A confirm dialog is the person’s gate; a permission check is the machine’s; both are needed. This entry only requires the machine gate to refuse before execute.

Applying it

• Policy-check every tool call before it is issued: object, verb, ticket scope. If it fails, do not issue the call, and expose the rejection so the agent replans — do not retry the same call.
• Out-of-scope must be neither swallowed silently nor only logged after the fact. To the person it must be immediately visible: “not done, because out of scope.”
• Check: under a narrow ticket, let the agent touch an out-of-ticket object, and look at the external system. If that row exists, the boundary is still a camera. Then see whether the product showed a reject before the call — an alert only after the call means the intercept was fitted late.

Related

• Same group: L4.06.1 Permissions must be granted by task scope, not all at once · L4.06.3 Records of permission use must be auditable
• Nearby: L4.07 Pre-action Confirmation · L4.13 Agent Failure Reporting and Escalation · L1.05 Human in the Loop
• Search terms: fail closed · policy enforcement · agent sandbox