Imagine Newton has two operators evaluating the same Policy.
Both receive the same intent, the same policyData, and the same Policy artifact. Operator A completes the evaluation in 90ms. Operator B is slightly slower, hits the 100ms timeout, and returns an evaluation error.
The logic has not changed. The input has not changed. The Policy has not changed. But the authorization result is no longer the same.
That is why CPU limits in Newton Protocol are not merely a performance concern.
When Rego is compiled into WASM, a Policy can run inside an isolated sandbox. It cannot arbitrarily read host memory, call system APIs, or interfere directly with external processes. But memory safety answers only one question:
What is the Policy allowed to access?
It does not answer another: How much computation is the Policy allowed to consume?
A Policy can still process excessively large inputs, expand into too many logical branches, or consume an unreasonable amount of CPU. It does not need to break out of the sandbox to become harmful. It only needs to keep evaluation running long enough to turn the authorization layer into a bottleneck between intent and execution.
The most obvious solution is to impose a timeout.
But wall-clock time is not deterministic. Two operators may take different amounts of time to perform the same computation because of differences in hardware, cache behavior, system load, or runtime versions. One node may complete the Policy and return allow, while another is terminated before reaching a final decision.
Newton may still preserve the sandbox. But it no longer preserves computational consistency.
Execution budgets, therefore, should not be measured only in milliseconds. They need to reflect the actual amount of logical work performed, using mechanisms such as WASM fuel, instruction counts, input bounds, or a maximum number of evaluation steps.
Newton does not need every operator to run at the same speed.
What it needs is for every operator to evaluate the Policy within the same computational boundary. Even fuel, however, is not enough if the cost model is not fixed.
A new compiler may produce a different artifact. A new WASM runtime may implement built-ins differently. If the number of instructions required to express the same semantics changes, a Policy that previously completed successfully may begin exhausting its budget after an upgrade.
The budget must therefore be tied to a specific compiler version, runtime version, set of built-in semantics, Policy artifact, and cost model.
Newton does not only need to version Policy logic. It also needs to version the cost of executing that logic.
This directly affects whether a past authorization decision can be reproduced. When auditing an execution months later, the system cannot merely know which Policy was used. It must also know which runtime executed it, what budget was applied, which cost model was in effect, and whether the evaluation ever reached its limit.
Without that information, Newton may be able to reproduce the logic on paper, but not necessarily the actual behavior of the evaluation.
There is an even more important boundary: What happens when the budget is exhausted? The system must fail closed, but budget exhaustion should not be treated as identical to deny.
Deny means the Policy was fully evaluated and concluded that the action was not permitted. An evaluation error means the system failed to produce a valid decision.
Both states should block execution, but they carry different meanings for auditing, debugging, and authorization provenance. If Newton collapses them into a single result without recording the cause, the system may remain safe in the moment while losing the ability to explain why the decision occurred.
Budget exhaustion should therefore be recorded as a distinct authorization state. It should have clear provenance and must never fall back to allow.
At this point, execution metering is no longer merely a defense against CPU exhaustion.
It becomes a condition of a deterministic authorization model.
The sandbox defines what a Policy may access. The execution budget defines how much computation it may consume. The cost model determines how that cost is measured. Fail-closed semantics ensure that an incomplete evaluation cannot be misinterpreted as valid authorization.
Newton’s public documentation does not yet make its full cost model clear. This should therefore be treated as an architectural requirement that still needs verification, not as proof that the protocol necessarily lacks such a mechanism.
But the central question remains: Can Newton force every operator to evaluate the same Policy within the same computational boundary, under the same cost model, and handle budget exhaustion with the same semantics?
An authorization protocol truly controls a Policy only when it limits not just what the Policy is allowed to do. It must also limit exactly how much the Policy is allowed to compute.