An agent needs a mandate before it needs tools.

Consider a request for a document. An agent could locate an authorised case, identify the requested item and prepare a reply. The reviewer would need to see the recipient, the precise document version and the message together. Approving that proposal should not give the agent permission to browse unrelated files, add another attachment or substitute a different destination just before sending.

This separates reading, preparation and execution. Each operation needs appropriate permissions and a result that the user can understand. A broad request such as handling a case does not define an executable mandate. The scope should instead name permitted actions, limits, responsible people and the circumstances in which the agent must stop and return the task to a person.

The system executing an action must enforce permissions even when the interface only offers apparently valid choices. Text found in a document or message must remain source material, not become a privileged instruction. Tests should therefore include misleading requests to change a recipient, access another organisation's records or bypass a reviewer. Revoking a user's access while a proposal is being prepared also needs an explicit outcome.

Approval should apply to the concrete version shown to the reviewer. Before execution, the application must check that the mandate and relevant data are still valid. Due diligence decisions remain with authorised people throughout. An agent may prepare an examination, but its suggested conclusion must not automatically approve a relationship or be treated as legal advice under a more permissive tool setting.

A connector depends on an official interface, the permissions it offers and the terms governing its use. These must be checked for each existing application. Some systems may support a controlled export but no safe write operation. Others may require a manual step. An integration proposal should make those limits visible rather than assuming that every tool can be connected or should be replaced.

Timeouts need particular care: an action may have completed even when its acknowledgement was lost. A retry must be able to recognise an existing operation before creating a duplicate message or entry. The intended record should link the request, proposal, approval and result without copying unnecessary case information into logs. Some effects can only be corrected, not undone.

An agent should start with a limited set of actions and clearly identified accounts. A first trial can use a fictional mailbox or document collection; access to the organisation’s working systems is introduced only within the agreed scope. The team needs to see which action is proposed, which information supports it and when human confirmation is required. That visibility must also cover retries and fallback services, so an error does not quietly widen the agent’s access.

The assessment should consider review time, corrected proposals, interrupted actions and recovery work, not only a successful demonstration. Vedetta includes planned assistance for all Monaco vigilance professions, but its product workflows and integrations remain under development. The current demonstration supports discussion of the intended workflow; its operational features are still being built.