Fail-closed validation for direct script steps

The step everyone assumes is safe

Discussions about AI governance concentrate on the model's freedom to act: which tools it can call, which credentials it holds, which environments it can reach. That framing quietly exempts the steps where no model is involved. A plain script step is assumed safe because it is deterministic — the author wrote the command, so the command is what runs.

Deterministic is not the same as compliant. A hand-written script can drop a table, deploy to the wrong environment or exfiltrate a credential just as effectively as a model can, and it does so without any of the review a model-driven step attracts. If a pipeline carries policy that says which commands are permitted, a script step that bypasses the policy check is the largest hole in it.

Blocking context applies to scripts too

In NopsAI, knowledge context attached to a pipeline can be marked as blocking. When blocking context applies to a step, a direct script no longer takes the short path to execution. The agent instead submits the script for validation against that context before anything runs.

The validation asks a narrow question, not an open one. The model is not invited to improve the script, decide the goal or propose an alternative. It is asked whether this specific command is permitted under this specific policy context, and to return the command it considers allowed.

The command must come back unchanged

Execution proceeds only if the validated command matches the script the pipeline author wrote, compared after trimming surrounding whitespace. Any divergence is treated as a failed validation rather than as an improvement to adopt.

This is the part that matters against prompt injection. If content the model read during the run — a ticket description, a log line, a file in the repository — persuades it to return a modified command, that modified command is not executed. The check does not depend on detecting the injection; it depends on the output being identical to something the model did not author. An attacker who can influence the model still cannot change what runs.

The same applies to a model returning an explanation rather than a command. A refusal, a caveat or a rewritten instruction all fail the comparison equally.

What happens when the answer is not a clean allow

Validation produces one of four decisions: allow, block, conflict, or uncertain. An unrecognized response is treated as uncertain rather than being interpreted generously. Crucially, an unavailable model is also an uncertain result — a timeout, an unreachable provider or an unresolvable profile is not a reason to skip the check.

How each decision is enforced depends on the pipeline's governance level, and the levels are explicit rather than implied. Under strict, anything that is not an allow stops the run. Under guarded, a block or a conflict stops the run while an uncertain result continues with a warning. Under exception-based, a conflict may continue if an approved exception exists, and everything else stops. Under advisory, nothing stops the run but every non-allow decision is recorded as a warning.

Strict is the default. A pipeline that sets no governance level gets the level that fails closed, which is the correct direction for a default to point: forgetting to configure governance should not silently produce the most permissive behaviour.

Why this is a boundary control, not a prompt control

It is tempting to address unauthorized tool use by writing a better system prompt. That approach fails for a structural reason: the prompt and the untrusted content occupy the same channel, so anything the prompt asserts, later content can contest.

Comparing an output against a fixed reference is different in kind. It does not ask the model to be trustworthy; it removes the model's ability to change the outcome. The model can veto the command by returning a block, and it can fail to approve by returning anything else, but the one thing it cannot do is cause a different command to execute.

That is the property worth designing for. A governance control should reduce what a compromised component can accomplish, not merely make compromise less likely.