Imagine an AI coding agent changes an authentication module and returns a correctly formatted review response claiming "security_approved": true. No security owner has approved the change, yet the workflow still permits the merge.
A valid response is not an authorized change.
A mandatory policy needs a control that refuses the prohibited action without trusted evidence. The agent must also lack permission to disable that control.
For a rollout decision, ask something narrower than “Does this tool support our policies?” Ask: “Which actions can this workflow prevent, under whose authority, and what happens when evidence is absent?”
Separate the report from the authority to proceed
Stack Overflow’s October 28, 2026 article “A JSON schema Is not an AI governance layer” states: “The AI governance argument is happening one layer above the code that actually stops your agent.” That distinction helps frame the control review; it is not evidence that a particular tool can enforce a policy.
Distinguish three jobs:
| Layer | What it establishes | Boundary to verify |
|---|---|---|
| Output-format validation | A response contains the required fields and permitted value types. | An approval claim still needs authentication and authorization. |
| Policy evaluation | Available evidence satisfies a defined rule. | A failed evaluation must reach a control that prevents the action. |
| Enforcement authority | A merge, release or other protected action is refused when its conditions are unmet. | The agent must lack permission to disable or bypass the control. |
These jobs can exist in the same system. They still need separate verification.
In the authentication scenario, an evaluation could correctly return “approval missing” while an optional status check leaves the merge button available. The evaluation works; the mandatory control does not.
Use a policy-to-control matrix before approving access
Start with prohibited actions, not broad aspirations such as “AI-generated code must be secure.” A prohibited action identifies a boundary you can test: merging an authentication change without an authorized approval, for instance.
Use this policy-to-control matrix as a review artifact. Its rows describe policy choices rather than capabilities of a specific product.
| Prohibited action | Accountable owner | Enforcement point | Required evidence | Exception authority |
|---|---|---|---|---|
| Merge an authentication change without security-owner approval | Security lead | Required merge gate covering protected paths | Authorized approval tied to the exact proposed revision; absence blocks merge | Named security delegate through a recorded exception |
| Introduce a prohibited dependency across an architecture boundary | Architecture owner | Required merge check | Policy result for the proposed revision; unavailable evaluation blocks merge | Named architecture exception approver |
| Let the coding agent deploy directly to production | Platform owner | Production access boundary | Agent identity lacks deployment authority and must use the approved release path | Separate, authorized emergency operator |
A release gate cannot enforce a prohibition on merging: by the time it refuses deployment, the prohibited merge has already happened. Put the control at the action the rule names, and specify what happens when required evidence is missing.
Not every guideline needs a blocking gate. Naming conventions or advisory design suggestions can remain review feedback if the organization accepts that discretion. I would reserve mandatory gates for rules whose violation should actually stop the named action. Otherwise, the policy promises a restriction that the workflow does not deliver.
Test the authentication approval rule without trusting the agent
For the authentication scenario, write the policy plainly:
Changes to protected authentication paths require approval from an authorized security owner for the revision being merged. Without that approval, merge is denied.
The agent may explain the change and provide evidence for review. It should not grant its own exception or supply an unverified assertion of approval.
A required check alone does not implement this rule. The gate must obtain the approval from a trusted review record, verify that the approving identity is authorized, and compare the record’s revision identifier with the exact revision being merged. A passing result for an earlier revision must not authorize a later one.
Some workflows retain an approval after new changes arrive. For this policy, a retained approval is insufficient unless it explicitly covers the new revision. The merge control must enforce that match at merge time, rather than trusting a stale check result or assuming approvals are automatically invalidated.
Gate configuration needs separate protected authority too. Changes to required checks, protected-path rules, approval logic and exception permissions must not be available to the agent through its granted identity. Otherwise, the agent could change the condition instead of satisfying it.
Run this acceptance test in an isolated repository with mock authentication code and no production credentials or customer data:
- Create a protected-path change. Confirm that the gate recognizes the changed file as subject to the security-approval rule.
- Omit the approval. Attempt the merge through the workflow intended for the pilot. The required result is denial.
- Include an approval claim in the agent’s response. Leave the real approval absent. The merge must still be denied because the claim is not an authorized approval event.
- Add the authorized approval. Confirm that the approval condition now passes for that exact revision. Other required checks must still apply.
- Change the revision. Attempt another merge without renewed authorized approval. The required result is denial, even if the review interface retains the earlier approval.
- Attempt to disable or bypass the gate. Using the agent’s granted identity, try to alter the gate configuration or merge around it without an authorized exception. Configuration changes must require separate protected authority, and the unauthorized merge must remain blocked.
Capture the proposed revision, approval state, identity used, gate configuration and observed outcome. A screenshot saying “review complete” is weaker evidence than a recorded attempt showing that the protected action was refused.
Independence means the agent cannot turn its own assertion into permission or disable the control using its granted access. The gate can live in the same development platform; it needs a separate authority boundary, not necessarily a separate vendor.
Passing establishes only the tested control under the tested permissions and paths. It does not establish code correctness, complete governance coverage or protection against every bypass; broader rollout requires examining the other mandatory rules and access paths.
Approve a constrained pilot, or hold the affected workflow
I would approve a constrained pilot when the gate passes the acceptance test, its owner accepts responsibility, and bypass permissions match the exception policy. Keep the pilot within the repositories, permissions and protected actions evaluated.
For the matrix’s other rules, hold affected architecture changes until the boundary check is mandatory. Withhold direct production access if the agent can bypass release approval.
Hold any affected workflow when a mandatory rule is merely advisory, the agent can remove its own restriction, or missing evidence allows the prohibited action. That does not require rejecting AI coding tools altogether. A team could permit isolated code generation while withholding merge or deployment authority.
Find where one mandatory rule actually blocks action
Spend five minutes choosing one mandatory rule from the proposed rollout and filling in a single matrix row. Name the prohibited action, owner, required evidence and exception authority. Identify the existing gate that refuses the action when evidence is absent, or mark the enforcement point as missing.
If the team cannot identify where refusal occurs, it has found a rollout gap before granting more access. This exercise prepares the test; it does not replace running it in an isolated environment.