A tool that can read a document is not the same as a tool that can send a message, change a record or instruct another system. The difference is easy to miss when both arrive behind the same conversational interface.
That distinction matters in a family office or fiduciary business. A person asking for help with a board paper may be entitled to read one set of records but not another. An apparently simple task might pass through documents concerning several entities, advisers, beneficiaries or members of a family. The organisation remains responsible for those boundaries even when the work is delegated to software.
The first question, therefore, is not whether an AI agent is capable of doing the work. It is whose authority it will be using.
Access comes before intelligence
Most technology projects begin with the function: find the document, prepare the summary, reconcile the figures. With an AI agent, I would begin with the entitlement. Which person is asking? Which entity or mandate are they acting for? What records are they permitted to reach for this purpose? What may the agent retain or pass to another service?
These questions sound administrative until the same system can search widely across a document archive. A correct answer drawn from a document that the requester should never have seen is still a failure.
The boundary has to be enforced by the underlying identity and access arrangements, not by an instruction telling the model to be discreet. An agent should not acquire broader access merely because it is convenient to connect it to a powerful service account. Where records have inconsistent permissions, the sensible first investment may be to correct those permissions rather than to deploy the agent.
There may also be information the agent should not receive at all: legally privileged material, particularly sensitive family correspondence, credentials, recovery information or records whose disclosure would cross an entity boundary. The precise exclusions are contextual. The important thing is that somebody decides them before the system is given a path to the data.
A draft is not an instruction
A useful way to judge authority is to distinguish what the system may read, summarise, recommend, prepare and do. I describe the progression in more detail in the six levels of AI authority. The progression is not a maturity score. An organisation does not become better governed by moving further along it.
Consider a request to deal with an overdue document. An agent might identify the missing item and prepare a reminder for review. That is different from deciding whom to contact, selecting an address and sending the reminder. It is more different again if the agent can change a case status, update a record or initiate a payment.
Each change of authority requires a different decision. “A human is in the loop” is not a sufficient description of a control. What, exactly, does the human see? Can they verify the underlying source and proposed action? Can they alter or refuse it? Is approval attached to one bounded action or to a whole sequence the system may choose for itself?
Approval is meaningful only if the approver can understand what is being authorised. Otherwise an apparently cautious process becomes an automated decision with a human signature at the end.
What would remain visible afterwards?
An organisation should be able to reconstruct a material action without asking the agent to remember what it did. That means distinguishing the request, the records consulted, the permissions used, the recommendation or draft produced, the person who approved it and the action eventually taken.
A transcript alone may not be enough. A message saying “completed” is not evidence that the correct version of a record was changed, or that nothing else changed with it. The useful audit trail belongs in the surrounding systems, with the appropriate security and retention controls, not solely in a conversation window.
Nor does a confident answer establish that it is right. Where an AI-generated statement influences a fiduciary decision, the person relying on it should be able to return to the source, distinguish fact from inference and recognise where the underlying information is incomplete.
Stopping the system is part of granting access
Before allowing an agent to take action, ask how its authority will be withdrawn. Can its credentials and tool permissions be revoked without disabling unrelated services? Can unfinished tasks be cancelled? Will the organisation know which changes it made? Which changes are reversible, and which require a separate correction or escalation?
There is a difference between closing a chat window and removing an agent's ability to act. A genuine stop mechanism has to work at the systems and permissions that confer authority.
I would also want the first test to be unremarkable. Use a narrow task, representative but non-sensitive material, permissions that cannot reach the wider estate, and an outcome the responsible professional can check. Test a refusal, an incorrect record and an attempted action outside scope, not only the demonstration that works.
Who makes the decision?
The technology team can explain how access, logging and intervention will work. The vendor can explain the product's capabilities and contractual terms. Neither should decide alone what the organisation is prepared to delegate. That decision belongs with the people accountable for the information and the work, with legal and fiduciary input where required.
Some agents may deserve only permission to retrieve and draft. Others may eventually be authorised to carry out tightly bounded actions with independent safeguards. And some workflows should remain entirely human. Those are not statements about whether an organisation is progressive or cautious. They are judgements about consequence, evidence and control.
The most useful AI agent is not necessarily the one that can do the most. It is the one whose authority can be explained before the task begins, observed while it runs and withdrawn when necessary.