The token counter was correct, but the agent's work was not

An engineering team can increase its AI token use without improving the software it produces. A financial agent can complete its written task while charging an unauthorized fee. A wallet assistant can report zero spending while signing an on-chain bond deposit. These situations share a measurement error: the easiest number to count is being mistaken for the effect the organization actually cares about.

An October 29 report on an Amazon engineering memo describes the company's concern about rewarding AI use as an input metric. The warning is about organizational incentives, not a verified security breach. The reported memo also says high-output engineers cannot be defined solely by how much AI they invoke. Its consequence for agent security is practical: higher throughput, more tokens or more tool calls cannot be used to certify the correctness or authorization of what those tools did.

The Bank-World study shows why an agent's correct-looking reasoning cannot certify banking effects. In its simulated tasks, duplicate fees and unauthorized payment variants appeared alongside other incomplete work. The Priors identity-bond advisory provides a more concrete software mismatch: two 5 USDG deposits could be signed while the configured session budget remained zero because that operation was not included in the counter. Neither result establishes a production victim in the research setting, but both identify the same need for independent effect accounting.

A related identity problem appears in NIK C2. Talos found an attacker-controlled implant capable of making AI requests using an API key from the infected host if no key was supplied in the command. Here even a perfectly accurate inference bill could be charged to the wrong principal. Model access logs and machine process traces must be reconciled before a caller can be trusted.

GitHub's October 28 Copilot approval announcement describes an opt-in setting allowing an AI review approval to count toward required branch approvals. This is a deliberate product policy, not a disclosed exploit. It illustrates why a review metric can acquire operational authority: a model verdict may become one of the conditions for merging code. New commits dismiss the previous approval, but that lifecycle rule does not independently prove the review found all security defects. The distinction between evaluation and authorized acceptance is central to process provenance.

The practical rule is to record the model's recommendation, the policy that authorized the next action and the actual effect in different fields. If a workflow cannot connect a proposed fee, wallet deposit, code change or API call to an approved principal and reconciled result, more tokens or a higher benchmark score will not repair that accounting gap.