Is the Rule You Rely On Actually a Control, or Just a Wish?

Challenge: Can you name every route that can perform the action and show current evidence that each route will deny it?

Pick one consequential rule in an AI-assisted workflow. List every route that can perform the action and the current denial evidence for each route.

If we cannot show that evidence, the rule may still be useful guidance. We just cannot rely on it to stop the action. For the AI-assistant hook pattern examined here, local instructions and actor-editable hooks are convenience layers; protected server-side mechanisms provide enforcement only under their stated administration and configuration conditions.

When we delegate work to people and AI systems, the gap can hide behind normal success. A check may appear to work until the tested actor can change, remove, or route around it.

The proposed assessment starts with a count our own teams can defend:

Unverified routes = all relevant routes - routes with current observed denial evidence

If we cannot supply both numbers, the proposed assessment keeps the overall claim unverified. That tells us where intent ends and evidence begins, so we can decide which proof is worth obtaining.

Have a workflow that is costing time, money, or customer confidence? Just In Time AI can help you find the smallest valuable improvement, implement it as a secure, compliant AI system, and prove the business result before expanding. Explore AI Systems Setup and Coaching.

What: What makes a rule an enforced preventive control?

The public Enterprise Security: Hook Enforcement Model describes defense in depth for AI-assisted work. A local Claude Code hook is a convenience layer: it can catch accidental violations early, but a developer or agent with write access can modify, remove, or bypass local hook files. Protected server-side controls can provide stronger enforcement when they are properly configured and administered outside the tested actor's authority.

The relevant rows from the source's published defense-in-depth table are the actual artifact:

That table shows where the source places enforcement. The proposed reader aid below adds three business-reliance checks:

1. Define the action and routes. Identify the prohibited action and every route that could perform it before deciding what the control claim covers.
2. Check independent stopping power. Confirm that the stopping mechanism and the authority to administer it sit outside the tested actor's write authority.
3. Require current deny evidence. Require observed denial evidence from a harmless, reversible test in an owned and explicitly authorized environment.

Under this proposal, the accountable business leader defines the consequence, the routes that matter, and the evidence threshold. The system owner or an authorized technical agent designs and runs the controlled test. The protected administrator confirms who can change the enforcement layer. In a small company, we may hold all three roles, but the record should still make each responsibility explicit.

The proposed assessment would produce a representative record like this:

Within this proposed assessment, the enforced label would cover only the route, conditions, configuration, and administration that were actually checked.

What should a control record show?

A proposed assessment record should let us see the claim and its limits without reading implementation code. For each relevant route, it would record:

• Prohibited action and tested actor. State what must be stopped and whose authority the test examines.
• Owned, authorized environment. Identify the environment in which the harmless test is permitted.
• Stopping mechanism and administrator. Name the protection and the administrator who can change it.
• Representative action and test data. Describe the harmless action and data that stand in for the prohibited route.
• Expected denial and observed result. Record what should be blocked and what the test actually showed.
• Retained evidence. Link the evidence that supports the observed result.
• Containment and rollback. State the safeguards prepared before the test begins.
• Exceptions and retest triggers. Identify unverified routes and the conditions that require the claim to be tested again.

Under the proposal, we define containment and rollback before any test begins, and we stop before an external or irreversible effect. If a route cannot be tested safely, the system owner would record it as UNVERIFIED in an owner-visible queue and request a decision within 48 hours. The entire queue, deadline, and silence rule is a proposed policy. An unstated default can create two risks: the request may wait indefinitely, or someone may misread no answer as authorization. The proposed default is UNVERIFIED / NO RELIANCE: silence does not approve testing or justify reliance on the route as enforced.

The proposed assessment also treats the control claim as expired for an affected route when the route, actor rights, enforcement policy or configuration, protected administration, or a material environment assumption changes. The system owner would repeat the protected-mechanism check and harmless deny test before the accountable leader relies on the enforced label again.

The commit-pinned Enterprise Security: Hook Enforcement Model documents actor-editable local hooks and conditionally protected server-side controls. The six-column record is a proposed business adaptation; it proves nothing until a controlled test fills the observed-result column for the route and conditions being evaluated.

Artifacts

• JitNeuro repository - the public repository that maintains the released pattern.
• Enterprise Security: Hook Enforcement Model - the maintained reader-facing model for local-hook bypassability and conditional protected enforcement.

Why: Why does protected stopping power matter to the business?

False assurance can create a recurring cost. We pay once to determine what happened. A repeat may add frustration because we believed the issue had already been handled. If the same gap reaches a customer, the possible consequence extends beyond rework into delivery, trust, or compliance risk.

AI-assisted work adds another meter. Every repeated investigation can consume staff time, AI calls, tokens, compute time, and elapsed time while a decision waits. We can estimate that exposure with our own inputs:

Recurring control-gap cost = repetitions x [(people-hours x loaded hourly rate) + AI token cost + (compute or wall-clock hours x unit rate) + delay cost]

For the AI portion:

AI token cost = (input tokens x provider input-token rate) + (output tokens x provider output-token rate)

This is an illustrative calculation, not a claim about measured savings or a universal rate. We supply our own repetition count, hours, rates, token use, compute use, and defensible delay cost. We track potential loss of confidence separately. A rule that repeatedly fails may weaken trust and create a risk that people begin treating compliance as optional.

For a related view of the operating cost of giving AI agents authority to stop work, read I gave my agents a veto. Here is what it cost me.

For the implementation walkthrough, read How Do I Turn a Rule Into an Enforced Control?.

Bottom Line: Why is verified enforcement worth the effort?

Reserve the enforced label for routes with current protected denial evidence. Keeping every other route marked as guidance, bypassable, or unverified reduces repeated uncertainty and limits exposure to team frustration, a repeat reaching a customer, compliance decay, and people-hours plus AI calls, tokens, and compute spent re-deriving a control decision the business already paid to settle.

If you want more decision-ready guidance for operating a business with AI, join the DanStolts.com newsletter.

Frequently Asked Questions

How can I tell whether a written rule is an enforced control?

For AI-assistant hooks, first identify the prohibited action and its routes. The source says local actor-editable hooks are bypassable and protected server-side mechanisms depend on their administration and configuration. The proposed assessment adds a harmless authorized deny test before calling a specific route enforced; it labels the rest guidance, bypassable, or unverified.

What should I test before relying on a local AI-agent hook?

First check whether the agent or developer can edit the hook, its configuration, or the instructions that load it. The proposed assessment has the system owner or authorized technical agent use harmless representative data only in a controlled, owned, and explicitly authorized environment, with containment and rollback defined first; stop before any external or irreversible effect. If safe testing is unavailable, the proposed policy puts the route in an owner-visible queue with a 48-hour deadline and defaults silence to UNVERIFIED / NO RELIANCE.

Who should run a deny test for an automated control?

In the proposed assessment, the accountable business leader defines the consequence, routes, and evidence threshold. The system owner or authorized technical agent designs and runs the harmless controlled test, while the protected administrator confirms who can change the enforcement layer. The representative record names the actor, environment, expected denial, observed result, evidence, containment, and rollback.

When should I retest a preventive control?

The proposed assessment calls for retesting whenever a route, actor right, enforcement policy or configuration, protected administrator, or material environment assumption changes. The system owner would repeat the protected-mechanism check and harmless deny test for each affected route before the business leader relies on the control claim again. If safe retesting is unavailable, the proposed policy places the route in the owner-visible queue with a 48-hour deadline and defaults silence to UNVERIFIED / NO RELIANCE.

Does a written policy help with compliance if it cannot stop the action?

It can document intent and support training, but it is not a preventive control by itself. Describe it accurately as guidance or a detective measure until an authoritative path denies the prohibited action and a current test proves that denial. Auditors and operators should be able to inspect both the control boundary and its latest deny evidence.

Update History

• 2026-09-14: At the prepublication stage, I substantially revised this article around the pinned hook-enforcement source, route-specific denial evidence, business ownership, and explicit limits. The revision helps you distinguish protected stopping power from guidance without implying that an unverified protected route has been approved.
• 2026-09-14 - Reader path and implementation help: Added the property-specific Just In Time AI service callout within the first third of the article and verified the paired reader path. The lifecycle-authorized article is bound to its locked canonical route; deployment and anonymous readback remain pending.