An agent’s ability to propose an action should not automatically include authority to execute it.
Agency is a permission decision
OWASP describes excessive agency as a problem involving excessive functionality, permissions or autonomy. An AI agent connected to financial tools makes those boundaries especially important. A conversational goal such as “optimise operations” is not a precise spending policy. The system needs enforceable limits on which actions are available and who can approve them.
Three separate stages
A research agent can identify an option. A preparation component can construct a proposed action. A signing process can authorise a transaction only after policy checks. These stages need not share the same credentials. Separating them makes it easier to inspect a destination, asset and amount before anything irreversible occurs, and to stop when the proposal does not match the user’s mandate.
A fictional operating policy
Consider a demonstration agent allowed to prepare payments only to a preapproved test recipient, with a small test budget and a required human confirmation. Attempts to change the recipient or exceed the budget should fail independently of the model’s explanation. This is a design example, not an implemented product or an endorsement of any custody arrangement. Real deployments require their own security review.
Test failure and recovery
Ask what happens when a tool times out, a quote expires, an approval arrives twice or the agent restarts. Use unique operation identifiers and reconcile results before retrying. Log decisions without exposing secrets. A stop control must actually disable consequential actions, not just hide a button. Autonomy becomes more credible when its limits are observable and testable, rather than described only in a policy paragraph.
Sources & further reading
Sources checked 7 October 2026. Source-linked explanatory content; not personalised investment advice. Found an error? Request a correction.
