Guardrails — บังคับสิทธิ์ตรงจุดเกิดผลจริงMake Guardrails Enforceable at the Effect Boundary

1. The engineering problem

The word guardrail often conflates two mechanisms. A semantic detector estimates whether content is problematic. A hard guard checks whether a concrete action is authorized. The former can be wrong because it is a learned judgment. The latter should fail closed when identity, target or action is outside the application contract. A prompt saying 'never merge main' is not equivalent to withholding a merge credential or refusing a merge action in the tool gateway.

The companion checks the authenticated principal, exact repository and allowed action before any provider call. Only maintainer + demo/shop + draft_patch passes. Changing action to merge_main produces action_denied, zero calls and zero external effects even if the fixture model would be maximally confident. This is a simple capability boundary. In a real code host, use separate credentials with the narrowest scopes, protected branches, and a mediator that validates the concrete operation at commit time [1].

2. The boundary to design

The lab returns an in-memory draft. It neither writes repository files nor opens a PR. Its arithmetic interpreter accepts a tiny expression grammar; it is not a general-purpose Python sandbox. Do not scale this teaching mechanism into 'safe execution' by adding eval or a subprocess and assuming a temporary directory is isolation. General generated code needs an independently hardened execution environment, restricted network, bounded resources, no ambient credentials, and a threat model appropriate to the deployment.

3. Read the implementation

Implementation excerpt from the companion. Run the complete lesson below with its imports and fixtures.

def authorize(request, principal):
    # principal comes from the application's auth layer, never from model output.
    if principal != "maintainer" or request["repo"] != "demo/shop":
        return Gate("reject", "permission_denied")
    if request["action"] != "draft_patch":
        return Gate("reject", "action_denied")
    return Gate("pass", "draft_capability")

If you later add a PR-opening action, bind approval to the exact repository, base revision, candidate hash and operation. Recheck that binding immediately before the effect. A revised candidate must invalidate the old approval; an ambiguous remote timeout needs reconciliation before retrying the action. These are production extension requirements, not implemented features of the companion. The immediate lesson is narrower and testable: a confident semantic answer cannot override a hard deny. Keep that invariant even if the orchestration library changes.

4. Compare the outcomes

The following output comes from scripted fixtures that verify architecture behavior. It is not a measurement of live Jev accuracy, latency, or cost.

{
  "reason": "action_denied",
  "calls": 0,
  "effects": 0
}

5. Run, break, and explain

Part 08 code · Implementation · Tests: test_permission_stops_before_inference · Exercise

git clone https://github.com/Anirach/ai-core-engineering-workbench.git
cd ai-core-engineering-workbench
git checkout 18cdfcd4156d3d02acb8badf3b3a0a823113e0ed
python3 -m workbench.lesson 8
python3 -m unittest tests.test_boundaries.BoundaryTests.test_permission_stops_before_inference -v

Your turn

Attempt a different repository, a guest principal and merge_main. Assert that all three stop before inference.

Keep three artifacts: the input you tried, the resulting state and reason, and an explanation of which boundary owns that result. Do not change an expected result merely to make a test pass.

6. Sources and limits