Runtime Guardrails: Enforcing License Policies at the Build‑Intent Gate

The hidden risk of unchecked agent writes

A CI‑run that spawns an autonomous agent often ends with a file write. The agent decides what to emit, the runtime copies the bytes into the repository, and the build continues. When the gate between decision and mutation is absent, the agent can introduce a dependency whose licence conflicts with the project’s policy. The result is a repository that now contains proprietary code, a legal exposure that surfaces only weeks later during a compliance audit. The failure mode is clear: no licence guardrail at the write gate.

Why the write gate matters more than the model

The model that powers the agent is irrelevant to the licence breach. Whether the agent is a large language model or a rule‑based generator, it can still suggest import com.example.proprietary.*. If the system immediately commits that change, the repository state becomes non‑compliant before any human or automated review can intervene. The build intent gate is the only point where the system can enforce invariants such as “all imported libraries must be approved”. Treating the gate as a passive hand‑off is the mistake; it must be an active policy enforcement layer.

Concrete failure

agent> generate data‑export module
... (model output)
import "lodash";
import "proprietary‑analytics";

The agent’s proposal passes the model’s internal safety filter, but the licence check never runs. The write proceeds, the proprietary‑analytics package is added to package.json, and the next npm install pulls in a commercial licence. The breach is only discovered when a developer runs npm audit weeks later, at which point the commit history already contains the offending dependency.

Enforcing a licence guardrail at the build intent gate

1. Register the write intent – Every agent‑initiated write must first call the Build Intent endpoint. The request contains a manifest of files to be added or modified, together with a list of new external packages.

1. Resolve licensing invariants – The gate consults a licence catalogue (e.g., SPDX identifiers) and applies the project’s policy: allow only MIT, Apache‑2.0, BSD‑3‑Clause. Any package outside the whitelist triggers a PROVISIONAL verdict, refusing the write.

1. Return a terminal state – The gate replies with REJECTED and a diagnostic message. No files are written, no repository mutation occurs. The agent can either abort or propose an alternative that satisfies the licence policy.

1. Audit trail – The gate logs the proposal, the licence check result, and the final decision. This log becomes part of the build artefact, satisfying compliance auditors without additional effort.

The same flow works whether the agent talks to the MCP server, the plain HTTP API, or the offline client. The policy enforcement is model‑independent; the gate’s decision depends only on the declared intent, not on any generated content.

A minimal implementation sketch

// TypeScript client example – @shpbl/sdk
import { buildIntent } from '@shpbl/sdk';

async function proposeWrite(files, newDeps) {
  const response = await buildIntent({
    files,
    dependencies: newDeps,
    agentId: 'data-exporter',
  });

  if (response.status === 'REJECTED') {
    console.error('Licence guardrail blocked the write:', response.reason);
    return false;
  }
  // proceed with mutation if ACCEPTED
  return true;
}

The client sends the intent, receives a verdict, and only then mutates the repository. The licence check lives entirely on the server side, guaranteeing that no rogue client can bypass it.

Integrating with existing code‑review automation

Most teams already run pre‑merge checks (linters, static analysis, unit tests). Adding the licence guardrail is a single extra step:

1. Hook the build intent gate into the PR pipeline – Before the merge job, invoke the gate with the PR diff.
2. Fail the pipeline on REJECTED – Treat the gate’s verdict as another required status check.
3. Expose the diagnostic message – Surface the reason in the PR comment so developers understand why the change was blocked.

Because the gate runs before any files are written, the repository never contains the prohibited code, and the PR never needs a manual revert. This pattern aligns with the broader agent governance approach described in the pillar post on governing code agents at the build intent gate.

What you can do on Monday

1. Identify the licence policy – List the SPDX identifiers your project permits.
2. Add a build‑intent call to your CI – Use the TypeScript client or the HTTP API to submit every agent‑generated change for approval.
3. Fail the build on a REJECTED response – Treat the gate as a required status check in your PR workflow.

Implementing these three steps creates a concrete licence guardrail that stops unsafe proposals before they ever touch the repository. The result is a safer codebase and a compliance process that scales with the number of autonomous agents you deploy.