The AI Proposes, Plain Code Decides: Who Decides What the Rule Means?

An inbox-agent review separated defects in generated code from a disagreement about intended behavior.

Core Finding:Separating a model's proposal from permission to act is a useful design intention. It still leaves an engineering question: does the surrounding software implement the intended policy, and is that policy clear enough to review? An AI-built inbox agent exposed both problems. Independent review identified actions inconsistent with their stated approval requirements. It also raised a finding that the engineering lead later ruled was intended behavior. The reviewer could identify a disagreement, but deciding which behavior the product should permit required an explicit policy decision. This extends our published inbox-agent study. The published inbox-agent study already reported the escalation-policy ruling alongside the repair sequence. Here we retrospectively group the reported policy-related observations and explain why that grouping is not a count of confirmed authority escapes. Data from October 2026, analyzed October 2026.

Empirical Findings Table

The reports contain 17 high-severity findings. Four fit the draft's broad policy-enforcement grouping: a shutdown-related processing concern, a drafting concern, an approval-related mailbox action, and a disputed action associated with human escalation. These are results stated at the behavior level; implementation details are omitted.

Telemetry Metric	Measured Value	Context & Observability

Engineering Action Directives

An AI reviewer is useful as a source of concrete challenges to an implementation. It can ask whether a permitted action matches the written requirement and whether a change has introduced an exception. Its output remains a proposal for engineering judgment. Automatically converting every finding into a patch risks changing intended product behavior.
Plain code also needs a clear policy to implement. Moving decisions outside model output does not make policy ambiguity disappear. In this case, the important decision concerned what should happen when work needs human attention. That was a product rule to resolve explicitly, rather than a fact the reviewer could infer from its own preferred design.
The case also changes how we describe verification. A finding count measures what a reviewer reported under a particular scope. A disposition records what the team decided to do about it. A passing follow-up records what the reviewer saw in the supplied changes. Keeping those statements separate makes the evidence more useful than presenting a single total as a security outcome.

Methodology Boundaries & Limits

This is a retrospective analysis of a single service and its saved review sequence. It is not a benchmark of governance designs or model families.
The policy grouping was assigned after reading the findings. A different definition could reasonably exclude the shutdown concern or classify the escalation dispute separately.
The review reports describe visible changes and repeatedly qualify missing context. A clean final diff review does not establish that the whole service is free of defects.
No live abuse experiment, authority-escape rate, or platform-wide credential audit is measured here. The record cannot support a claim that unauthorized behavior is impossible.