Policy-Driven Review of Agent-Generated Code Before Merge

A code agent given repository write access will happily generate code that compiles cleanly, passes every linter rule, and introduces an architectural disaster.

It replaces an internal cryptographic wrapper with an unvetted third-party package. It hardcodes a fallback URL to a public endpoint to make a flaky test pass. It mutates a database migration file that was locked three sprints ago.

Linting does not catch this. Compilers do not catch this. Traditional CI discovers the issue only after the agent has pushed a branch, opened a pull request, and consumed human review capacity. Once a proposal lands in code review automation workflows as an open PR, the damage to team attention is already done. True agent governance requires intercepting the write before it touches the tree.

The Cost of Post-Commit Enforcement

Most teams hook governance checks into pull requests. The agent writes to a local branch, commits, pushes, and triggers a webhook. If the code breaches a policy—such as importing a forbidden dependency or editing a protected schema directory—the check fails on CI.

This is the wrong control point.

First, it treats agent actions like human actions. A human developer understands the context of an unwritten architectural policy or reads the contributing guide. An agent executes a loop against an objective function. If the fastest path to resolving a prompt is to import an unapproved library, it will do so.

Second, it pollutes the repository with dirty state. Failed attempts leave orphaned branches, consume runner minutes, and generate review noise.

The correct place for a policy gate is between the agent deciding to write a file and the actual mutation occurring. Policy evaluation must happen at the intent layer, not after disk mutation.

Intercepting Proposals with a Policy Gate

A build intent gate isolates the write proposal. When an agent decides to mutate a file or add a dependency, it submits a structured write intent rather than executing a raw filesystem write.

The gate evaluates the proposal against a declarative policy file before granting access to disk. A practical policy covers three surfaces:

1. Target Path Restrictions: Explicit deny-lists for sensitive paths (.github/workflows/*, migrations/*, internal authentication boundaries).
2. Dependency Constraints: An allowlist of approved package registries, approved package names, and permissible software licenses.
3. Structural Invariants: Rules prohibiting the removal of baseline security headers, telemetry wrappers, or required error handlers.

If the proposed mutation breaches an invariant, the policy gate rejects the intent immediately. The gate returns a structured error payload detailing the exact rule violated. The agent receives this terminal verdict in its context window and can attempt an alternative implementation without leaving a trail of broken commits.

{
  "status": "REJECTED",
  "reason": "POLICY_VIOLATION",
  "rule": "DISALLOWED_DEPENDENCY",
  "details": "Direct import of 'axios' violates dependency policy. Use '@internal/http-client'.",
  "target": "src/services/billing.ts",
  "remediation": {
    "action": "USE_APPROVED_IMPORT",
    "allowed": ["@internal/http-client"],
    "documentation": "docs/architecture/networking.md"
  }
}

Closing the Remediation Loop

A rejection without actionable metadata forces the agent to guess. To make the build intent gate effective, the returned payload must provide concrete correction paths.

When an intent fails, the agent runtime consumes the structured payload and executes a closed remediation loop:

1. Read the constraint: The agent parses the rejection rule and remediation fields directly from the response object.
2. Rewrite the intent: Instead of trying to force the disallowed dependency or path, the agent swaps the call for the allowed internal module specified in the payload.
3. Resubmit for validation: The agent posts the updated proposal back to the intent gate.
4. Mutate only on approval: Disk writes execute only after the gate returns an approved verdict.

This isolates governance failures to the agent's local working loop. The main branch never sees the invalid draft, CI runners remain idle, and human review focuses on valid architectural contributions.