A brake pedal and an accelerator should not pass through the same permission logic.
That may sound obvious, but I think automated finance often treats actions too uniformly. A transaction arrives, the system checks a policy, and the result becomes approve or reject.
The process looks clean.
The risk behind each action is not.
An AI-driven strategy increasing leverage is doing something fundamentally different from the same strategy closing a position. Moving funds to a new counterparty creates a different exposure than returning capital to an approved vault. Buying an unfamiliar asset should not necessarily face the same authorization path as reducing concentration in an existing position.
This is where I think @NewtonProtocol becomes more interesting than a simple automation narrative.
Newton’s Mainnet Beta and VaultKit are focused on pre-settlement authorization: checking an action against defined rules before it settles, then producing a signed attestation that can show the evaluation occurred.
I see real value in that design.
But I think the strongest version of the idea goes beyond asking whether a transaction fits a policy.
It asks how much authorization that specific action deserves.
Consider an automated vault during a volatile market.
One action increases leverage because the strategy sees an opportunity.
Another action reduces exposure because collateral conditions are deteriorating.
If both transactions move through exactly the same approval process, the system may be technically consistent while remaining financially insensitive.
The first action increases potential loss.
The second may prevent it.
That difference should matter.
For me, this is where risk-proportional authorization becomes important. An action that expands exposure may need stricter conditions: fresher market data, tighter limits, stronger counterparty checks, or a narrower execution window.
An action that clearly reduces risk may need a faster path, especially when delay itself could make the position worse.
I am not arguing that risk-reducing transactions should bypass authorization.
I am arguing that authorization should understand direction.
A system that only knows “allowed” and “not allowed” may miss the economic meaning of what the agent is trying to do.
This becomes even more important with AI agents because automated systems do not naturally pause and interpret context the way a human trader might.
A person can look at the market and think:
“This trade normally violates my preferred route, but I need to reduce exposure immediately.”
A rigid policy engne may only see that the route is not approved.
The result could be a strange contradiction: the authorization layer blocks an action designed to make the portfolio safer because the transaction does not fit a rule written for normal conditions.
That would not mean the rule failed.
It would mean the policy lacked risk awareness.
This is the part of NEWT I find worth following closely. Newton is trying to bring enforceable permissions into automated onchain finance. The harder challenge is making those permissions expressive enough to distinguish between actions that create risk and actions that remove it.
A signed attestation could become more useful when it communicates that distinction.
Instead of only proving that a transaction passed a rule, I would want the surrounding policy logic to make clear why that level of authorization was applied.
Was the strategy increasing leverage?
Was it reducing exposure?
Was it interacting with a previously approved asset?
Was it entering a new market?
Was it using an emergency exit condition?
Those details can change what a sensible authorization process should look like.
I also think this could improve user understanding.
Most people do not want to study every internal policy module before using an automated strategy. They want confidence that the system becomes more cautious when the action becomes more dangerous.
That is easier to understand than a long technical list of controls.
The principle is simple:
More risk should require stronger permission.
Less risk should not be delayed without a good reason.
Of course, implementing that principle is difficult.
The first problem is defining what “risk-reducing” actually means.
Closing part of a position may reduce market exposure but create liquidity costs. Moving into a stable asset may lower volatility but introduce counterparty or depegging risk. Exiting one vault may reduce smart-contract exposure while creating settlement or bridge risk somewhere else.
Financial actions rarely move risk in only one direction.
That means the policy cannot rely on a simple label.
It may need to consider several dimensions at once: leverage, liquidity, collateral quality, concentration, counterparty exposure, and the reliability of the data being used.
The second challenge is preventing abuse.
If an application gives faster authorization to risk-reducing actions, a poorly designed strategy may try to classify aggressive behavior as defensive. The definition must be enforceable, not merely descriptive.
The third challenge is transparency.
A user should be able to understand why one action required stronger approval while another moved through a faster path. If the logic is hidden, risk-sensitive authorization can start to feel arbitrary.
This is where verifiable attestations could become especially meaningful.
A receipt should not be treated as a guarantee that every financial judgment was correct. But it can provide evidence that the action was evaluated under a defined policy and that the required authorization path was followed.
For me, that is more useful than simply seeing that a transaction executed.
I want to know whether the system recognized the type of risk it was creating.
I also think different aplications will need different authorization profiles.
A conservative institutional vault may require strict checks for nearly every capital movement.
A retail rebalancing tool may use simpler limits.
An AI agent managing a narrow set of approved assets may need less friction than one operating across multiple chains, counterparties, and lending markets.
That flexibility is important because one universal risk model would probably become either too loose for serious capital or too restrictive for practical use.
Newton-specific infrastructure becomes valuable only when developers can translate those differences into enforceable rules without making the user experience impossible to understand.
That is the balance I would watch with Newt.
Too little control, and automation becomes dangerous.
Too much rigid control, and automation loses the ability to respond when markets move quickly.
The best authorization layer should not only stop prohibited actions. It should recognize that some actions deserve deeper scrutiny than others.
For me, this is the real standard for controled AI finance.
I do not just want an agent that follows rules.
I want an agent whose permission system becomes stricter as the consequences become larger.
Because in automated markets, treating every transaction equally does not always create fairness or safety.
Sometimes it only means the system failed to understand the difference between taking risk and escaping it.
