The run was green, but the activity record still had the line that mattered: withdraw_allowed=true before revoke_tx=confirmed.
That is not a closed run. The bridge leg had settled, the ERC 4626 vault deposit had landed, and the share balance was showing. Fine. The asset arrived. But the approval state was still part of the route, and it needs to be closed in the same place the route is being marked successful.
An OpenLedger run should not be treated as complete until the activity record shows approval_used=true, bridge_step=settled, vault_deposit=complete, revoke_tx=confirmed, remaining_authority=none, and open_fee_status=settled_after_revoke.
A green vault result proves the deposit landed. That is all it proves. It does not prove the agent cleaned up the approval it used during execution.
If someone has to answer whether the agent can still withdraw, move, or approve anything after the vault action, that answer should not require pulling bridge history, cloud config, or the previous agent run. It should be sitting in the run record already.
The risk being avoided is basic. The user gets the vault position without an active withdraw permission left behind after the deposit completes. Cleanup is tracked next to the action instead of being treated like some side note that has to be reconstructed later.
Bridge flows make this easier to miss. Once the destination side clears, attention moves to shares, fees, the next setup, or the next trade. The opened approval can fall out of view unless the system forces revoke state into the same transaction story.
That is the OpenLedger state-tracking issue worth watching. If an agent is touching real value, completion cannot stop at “asset landed.” The run record also has to show that the authority used during the route is no longer live.
Fast agent setup is weaker if cleanup has to be guessed afterward, so once an agent touches a bridge and an ERC 4626 vault, the completion condition needs to include withdraw_allowed being gone.