The Drift Log · Governing agents that write code
Policy‑Driven Build Intent Gate for Safe Agent‑Generated Code
8 November 2026 · 3 min read · 509 words · established
A pre‑commit Build Intent gate lets agents propose changes, but only writes that pass licensing and attribution policies are allowed.
The failure that slips through most pipelines
Agents that can write code often sit on a decision‑to‑commit path that lacks any gate. An agent decides “I need a new helper function”, emits a pull request, and the repository accepts it. The write happens before any policy check. The result is unauthorised licences, missing attribution, or runtime I/O that the team never approved. The breach is not caused by the model that suggested the change; it is caused by the absence of a pre‑commit gate that validates the Build Intent.
Build Intent policy as the first line of defence
A Build Intent policy is a set of invariants that every write proposal must satisfy. The policy lives in a single engine that runs before any artifact is persisted. Typical invariants include:
- licence compatibility – the proposed dependency must be allowed by the project’s licence whitelist.
- source attribution – the change must reference an upstream origin if it copies code.
- runtime I/O declaration – any new system call must be declared in the manifest.
The engine evaluates the intent against these rules and returns a verdict. If any rule fails, the proposal is rejected and the agent receives a clear error code. No code is written, no branch is created.
The request‑response flow that enforces the gate
- An agent calls the MCP server or the plain HTTP API with a Build Intent payload. The same payload can be sent via the typed TypeScript client (
@shpbl/sdk). - The server forwards the payload to the policy engine.
- The engine checks the invariants.
- If all checks pass, the engine returns PROVISIONAL and the agent may proceed to the certification harness. If a check fails, the engine returns FAILED with a message that the agent must surface to the developer.
Because the gate is enforced before any write, the repository never sees a violating commit. The decision point is isolated from the actual write, matching the pattern described in the pillar post /blog/governing-code-agents-at-the-build-intent-gate.
SHPBL’s concrete implementation
SHPBL ships a model‑independent Build Intent gate that agents must pass before any write. The gate is exposed through the same four doors – MCP server, HTTP API, TypeScript SDK, and offline file mode – so the policy engine is a single source of truth. A certification harness records the final verdict, distinguishing CERTIFIED, PROVISIONAL, INCONCLUSIVE, and FAILED outcomes. The gate respects licensing invariants and upstream attribution automatically. See the documentation for agent access /mcp-access and the live run harness /harness for a full example.
What you can do on Monday
Run the free repository evaluation at /evaluation. It will scan your code base, surface missing licences and attribution, and generate a starter Build Intent policy. Import that policy into your MCP or API endpoint, and enable the pre‑commit gate in your CI pipeline. The next time an agent proposes a change, the gate will block any violation before it reaches the repository. This single step turns an open write surface into a controlled, auditable process.
Keep reading
Next in the log
- Sandbox Isolation for Agent Build Intent
Isolate agent writes in ephemeral sandboxes to prevent credential leaks and CI churn before code lands.
- Blocking Agent Commits that Introduce Undeclared Runtime I/O
Prevent coding agents from bypassing side-effect boundaries by validating AST purity invariants before write proposals touch disk.
- Enforcing Pre-Commit Invariant Checks on Agent Write Intent
Gating agent file mutations on pre-commit Build Intent validation stops structural boundary violations before diffs hit code review.
The Strategic Master Library · written and reviewed under the house's own epistemic rules: nothing claimed that we cannot show.