A staff member prepares a payment and a manager approves it. Can either person release the money?
That depends on authority.
Approval is a judgment that a proposed action looks acceptable. Authority is the permission and technical ability to cause the action. Financial systems need both, because the proposal on a screen and the transaction that finally executes can differ.
This distinction already appears throughout finance. A staff member can prepare a payment while lacking permission to release it. An investment system can recommend an order while lacking permission to submit it. A reconciliation service can flag a discrepancy while lacking permission to change the controlling record.
AI agents enter the same chain. An agent can draft an action, use a tool and present information to a person or automated checker. A second model saying “approved” still leaves the central question unanswered: What independently enforced limit controls what the agent can actually cause?
Follow the action through five steps
A workflow that can change money, data or systems has five parts:
- Proposal: A person or system describes a possible action.
- Approval: A reviewer or automated check decides that the presented action is acceptable.
- Authorization: A policy or accountable person grants permission within defined limits.
- Execution: A service carries out the action using its final account, amount, destination and other details.
- Evidence: Records show who acted, what was approved, what executed and which state changed.
These steps may take seconds. Keeping them distinct still matters. An approval screen may show one description while the execution service receives another. A valid credential may carry more power than the approver intended. An application log may record what it requested without showing what the destination completed.
A protected key can sign a false instruction
Bitget reported a September 2026 security incident involving approximately $387.5 million in transfers to attacker-controlled addresses.[1] Reporting on chief executive Gracy Chen’s account said an attacker breached a backend wallet system, spoofed transfer information and triggered the authorization-signing process. Chen said private-key compromise had been ruled out.[2][3]
The account gives a clear example of correct technical execution carrying the wrong business instruction.
A digital signature can prove that a particular key signed a particular message. By itself, it cannot prove that the destination, amount, asset or instruction inside the message is genuine. False transaction data can reach a protected signing process, and the process can perform its assigned job perfectly while producing an unauthorized result.
The same gap can appear in an agent workflow. A person sees a payment description while the final beneficiary is resolved later. A control approves source code while the build introduces a dependency. A monitor accepts the agent’s explanation without inspecting the API request that will actually run.
The permission must attach to the final action: the resolved account, beneficiary, instrument, quantity, destination, system, data request and downstream effect.
Set limits the agent cannot rewrite
The limits on an agent’s power must not change just because the agent changes its wording, memory or description of the task.
A safe control system can give every agent a distinct identity and credential. It can limit permissions by action, account, destination, amount, volume and time. A separately authenticated policy service can check the request. A permitted-destination list can refuse unknown recipients. A signing rule can cover the resolved transaction. Different actors can propose, check and execute. A required human reviewer can genuinely refuse the action. Destination records can confirm what happened.
NIST says agents should be treated as distinct entities with their own identities, credentials and rights.[4] This allows an institution to see delegated power and revoke it. An agent preparing a transaction does not need permission to release it. An agent finding a record mismatch does not need permission to rewrite the authoritative record.
Authority must also be removable. Stopping an agent may require ending processes, revoking credentials, blocking network routes, freezing queued instructions and stopping delegated work. The destination then needs to confirm that activity ceased.
Finally, the evidence should connect the original instruction, proposer, approval, policy decision, credential, execution result and resulting state. Those records need protection from the system whose activity they describe.
The practical rule is short: Approve what you can see. Authorize the exact action that will occur. Record the result somewhere the actor cannot change.
Sources
- Bitget support notice: https://www.bitget.com/support/articles/12560603896108
- CoinDesk, account of the Bitget incident: https://www.coindesk.com/markets/2026/09/25/bitget-s-usd351-million-hack-happened-via-spoofed-transfers-not-private-keys-ceo-gray-chen-says
- CNBC, account of the Bitget incident: https://www.cnbc.com/2026/09/25/crypto-platform-bitget-suspects-north-korea-in-352-million-hack.html
- NIST, identity for agentic AI: https://www.nist.gov/blogs/cybersecurity-insights/back-future-why-agentic-ai-needs-strong-identity-foundation