An AI tool that summarizes a document has a different risk profile from one that can read every customer record, send email or change account permissions. Before connecting a vendor to your business, establish exactly what access the product needs and how you will control it.<\/p>\n\n\n\n
The buying decision should cover the working integration, not just the demonstration. A useful review leaves you with a permission inventory, a bounded pilot, named owners and evidence that the controls work.<\/p>\n\n\n
In guidance last reviewed on 26 October 2026<\/strong>, the Australian Signals Directorate\u2019s Australian Cyber Security Centre highlighted AI-enabled attacks that exploit trusted supplier relationships and cloud application permissions. It recommended reviewing third-party access and limiting it to what the supplier\u2019s function requires. Read the ASD\/ACSC guidance.<\/a><\/p>\n\n\n\n The underlying Microsoft report, published 21 October<\/a>, described attackers using an agentic AI framework to accelerate abuse of compromised ConnectWise application identities. Existing application permissions enabled access without an interactive user sign-in. Microsoft also cautioned that an affected application\u2019s presence, or even successful authentication, does not by itself prove that customer data was accessed or stolen.<\/p>\n\n\n\n This was reporting about AI-assisted attacks and compromised supplier access, not evidence that every AI vendor is compromised. The purchasing lesson is broader: examine the access path through which any connected product operates. The following checks turn that lesson into a practical review for a business buyer and their IT administrator.<\/p>\n\n\n Ask for the exact permissions the integration will request, the permissions already granted during any trial, and a plain-language explanation of each. Distinguish reading records from changing them, sending messages, deleting files or administering accounts.<\/p>\n\n\n\n For Microsoft environments, application permissions let software act through its own identity without a signed-in user; delegated permissions involve a user context. Those are materially different access arrangements. Microsoft explains the distinction here.<\/a><\/p>\n\n\n\n Evidence to request:<\/strong> a permission export or administrator-screen review, mapped to the proposed workflow. If a tool only needs one shared mailbox or project folder, ask whether it can be restricted to that scope. Record any broader access it cannot avoid before deciding whether the benefit justifies it.<\/p>\n\n\n Find out which account, application identity or service account performs the work, who controls its credentials, and who inside your business can change or disable it. Avoid an arrangement that nobody can distinguish from an employee\u2019s ordinary activity.<\/p>\n\n\n\n Microsoft\u2019s 28 October guidance on agent governance<\/a> recommends governed agent identities where supported and appropriate, together with visibility into ownership, access and behavior. For a small business, a useful starting record is simple: integration name, technical identity, business owner, administrator and review date.<\/p>\n\n\n\n Question to ask:<\/strong> \u201cIf the employee who set this up leaves tomorrow, can we still identify, manage and stop the integration?\u201d<\/p>\n\n\n Follow a representative record through the proposed workflow. Which fields leave your system? Which vendor and model providers receive them? Are prompts, attachments, outputs or support logs retained? Ask how retention, deletion, human access and model-training use apply to the specific product tier and contract you are buying.<\/p>\n\n\n\n Evidence to request:<\/strong> a data-flow diagram, current provider\/subprocessor list and written answers tied to your configuration. Treat a broad \u201cwe do not train on your data\u201d statement as one answer, not a complete account of storage or access. Start the pilot with synthetic or appropriately de-identified records where practical, and have the responsible person approve any move to sensitive business data.<\/p>\n\n\n List the actions that should require a person\u2019s approval: for example, issuing refunds, changing payment details, sending external messages or deleting records. Decide the boundary before the pilot, including any amount limits or recipient restrictions.<\/p>\n\n\n\n OWASP\u2019s guidance on excessive agency<\/a> recommends limiting tools and permissions, requiring human approval for high-impact actions, and enforcing authorization outside the model. A written instruction telling an agent to \u201cask first\u201d should not be the only control.<\/p>\n\n\n\n Test to run:<\/strong> in an authorized test environment, attempt a representative action without approval. Verify that the connected system blocks it, then confirm what the approver sees before an allowed action proceeds. Record the result rather than accepting a screenshot of a settings page.<\/p>\n\n\n Ask the vendor and your administrator to trace one test task from request to result. Can they identify the integration, time, affected record, attempted action, approval and outcome? Find out which records you can export, how long they remain available and who reviews alerts.<\/p>\n\n\n\n Microsoft\u2019s sign-in documentation<\/a> distinguishes user activity from service-principal and managed-identity sign-ins. Authentication records alone do not tell you every business action that followed; request the relevant application or service audit trail too.<\/p>\n\n\n\n Acceptance check:<\/strong> a reviewer who did not run the test can explain what happened from the retained evidence. Avoid collecting unnecessary sensitive content merely to make the logs more detailed.<\/p>\n\n\n Before relying on the integration, rehearse stopping it with test data. Document how to disable the connection, revoke relevant grants and credentials, address queued work, and confirm when access actually ends. Also decide how the business will operate while it is disconnected.<\/p>\n\n\n\n Microsoft\u2019s permission-revocation guidance<\/a> notes that revoking consent does not itself prevent a user from consenting again, and that access may exist through other authorization systems. Do not assume a single \u201cdisconnect\u201d button closes every route.<\/p>\n\n\n\n Question to ask:<\/strong> \u201cWhat access can remain after disconnection, for how long, and how do we verify that it has ended?\u201d Revocation timing is platform-specific. For example, Google\u2019s OAuth documentation<\/a> warns that revocation can take time to have full effect. Keep evidence of the stop test and its limitations.<\/p>\n\n\n Define the vendor\u2019s incident contact, your escalation owner, notification arrangements and responsibility for containment and recovery. Include what happens outside business hours and when an update requests broader access. A change in permissions should trigger a new review rather than silently inheriting the original approval.<\/p>\n\n\n\n The ASD\/ACSC guidance<\/a> calls for clear supplier security expectations, incident-response responsibilities and verification of remediation. It also warns that disabling a compromised application may not remove other access established during an intrusion.<\/p>\n\n\n\n Evidence to request:<\/strong> a short responsibility record that both sides can use. If you suspect an actual compromise, involve an authorized incident responder and preserve relevant evidence; this buying checklist is not an incident-response procedure.<\/p>\n\n\n For an illustrative pilot that drafts replies to customer enquiries, the initial scope might be one test mailbox, selected records and no automatic sending. A reviewer can then judge usefulness while the administrator verifies the access and approval controls. This is a proposed test design, not a claim about a particular vendor\u2019s capabilities.<\/p>\n\n\n Keep the evidence, unresolved questions and conditions for expanding access with the buying decision. For a related example of separating product claims from observed behavior, see our illustrative AI fraud-analysis case study<\/a>.<\/p>\n\n\n Athelguard helps businesses and investors examine technology claims, dependencies and technical risk. If you are evaluating a connected AI product, request a technical assessment<\/strong><\/a>. Begin with a non-confidential description of the workflow and the decision you need to make.<\/p>\n\n\n\n Sources checked 1 November 2026. This article provides a vendor-evaluation framework, not a guarantee of security or a certification of any product.<\/p>\n\n\n\n1. Match each permission to a business task<\/h2>\n\n\n\n
2. Give the integration an identity and an owner<\/h2>\n\n\n\n
3. Trace where the data goes<\/h2>\n\n\n\n
4. Test the boundary around consequential actions<\/h2>\n\n\n\n
5. Reconstruct one completed task from the logs<\/h2>\n\n\n\n
6. Prove that you can disconnect it<\/h2>\n\n\n\n
7. Agree who acts when something goes wrong<\/h2>\n\n\n\n
Make the pilot a decision gate<\/h2>\n\n\n\n
\n
Need an independent technical view?<\/h2>\n\n\n\n