In short
Review an AI or automation connection as an operational account with access to information and actions. Limit permissions, separate preparation from approval, test denied actions and keep a way to revoke access. The review should cover connected systems and support arrangements, not just the AI product's settings.
In this guide
Map the complete connection
A tool described as a reporting assistant may be connected to email, files, CRM records and an integration service. Its effective reach depends on all those permissions, including what the connected account can retrieve or change. A friendly interface does not make that reach obvious.
List the accounts, systems, data types and destinations involved. Record who owns each credential and how access is approved. Check whether the tool acts as the individual user or through an application identity, and whether it can reach information outside the intended team or business.
Do not confuse the ability to act with permission to approve
A workflow may prepare a supplier update or customer response without being authorised to send it. Enforce that distinction in system roles and approval steps where possible. Instructions inside a prompt are useful guidance, but they are not a substitute for access restrictions.
| Connection | Boundary to define | Evidence to request |
|---|---|---|
| Document retrieval | Approved sources and user access | A test showing unrelated records cannot be retrieved |
| Customer communication | Drafting versus sending | Required approval and the recorded recipient |
| Finance workflow | Preparation versus payment or master-data authority | Role configuration and rejected unauthorised actions |
| Cross-business reporting | Entity-specific data and permitted aggregation | Isolation tests and approved reporting scope |
ASD's secure AI deployment guidance emphasises access control, validation and ongoing monitoring. Apply those principles to the actual deployment. A hosted assistant, custom integration and self-hosted model have different control responsibilities.
Test boundaries as well as normal output
Use an authorised test environment and agreed sample data. Test expired credentials, unavailable sources, a repeated event and a request the workflow is not allowed to perform. Confirm that the result is a visible stop or escalation, rather than a plausible substitute.
Include documents containing instructions that conflict with the authorised task. Retrieved content should remain information, not permission to access another system or disclose unrelated records. Specialist testing may be needed where the consequences or technical exposure are substantial.
Keep acceptance records outside the tool's own editable workspace. For a consequential action, compare its claimed success with the receiving system's record. An assistant reporting that it completed a task is not enough to establish that the authorised result occurred.
Know who handles the next change or failure
Assign responsibility for permissions, vendor changes, failures and the continuing cost. Define what is logged, who can inspect it and how sensitive information is protected. Test revocation and recovery without exposing credentials or copying unnecessary personal information.
A new data source, model, integration or action can change the risk. Review those changes before expanding access. The business owner should know how to pause the workflow and which manual process can maintain essential work while an issue is investigated.
Where Advery's work is relevant
The secure product beta record describes access boundaries, human review and release checks. Advery can bring that operating-design discipline to an AI or integration review, coordinating the business owner, administrator and specialist providers.
A practical first engagement would map one connection and agree the permissions, tests and support required before it handles more sensitive work. Where independent assurance or specialist technical testing is required, that scope should be agreed with the appropriate security provider.