This is general operational guidance, not legal, clinical or regulatory advice.
A connected app wants more access to your HubSpot portal. A screen lists the permissions. There's a big button to approve. Most people click it.
I get why. The integration is useful, the vendor seems reputable and nobody wants to be the person who broke the sync. But every scope you approve is another door into your CRM. In plenty of Australian businesses, that CRM holds health enquiries, financial details or staff information.
Here's the review I run before approving a new scope. It takes less time than you'd think.
A scope gives an app access to a defined set of HubSpot APIs and data. HubSpot's developer documentation on scopes describes three types:
Optional scopes are where the judgement sits. The vendor is offering extra capability. You're allowed to say no until you need it.
Under APP 11, organisations covered by the Privacy Act must take reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure. The OAIC's APP 11 guidelines explain what that looks like in practice. APP 3 limits collection to what's reasonably necessary for your functions or activities, as set out in the APP 3 guidelines.
An app with broader access than its job needs is a bigger target, and a bigger mess if something goes wrong. Least privilege is good security. It's also much easier to explain to a client, a board or a regulator.
Plan for what's coming too. From 10 December 2026, organisations that use personal information in automated decisions that could significantly affect someone's rights or interests will need to say so in their privacy policy. The OAIC is consulting on guidance for this obligation. If an app or AI agent makes decisions with your CRM data, you'll want to know exactly what it can touch.
Write it as one sentence. "Create a support ticket when a signed-in customer reports a fault." If you can't write the sentence, the scope isn't ready for approval.
Decide which record holds the trusted customer, patient or client context. I prefer one governed record over copies spread across five tools. The app should read and update the fewest fields it needs. Your CRM tends to reflect how you run the business, which I wrote about in Your CRM Is a Mirror.
These carry very different risks. Reading a ticket subject is a long way from downloading your file library or deleting records. Judge the scope by the worst thing it allows, and ignore the happy path for a moment.
Assess each scope on its own. Tickets might be justified for a service integration. Files, custom objects or HubDB might not be needed yet. Approve the smallest set that works and expand when a real use case turns up.
If the app or an agent can take consequential actions, define where a human signs off. Commercial commitments, sensitive disclosures and anything hard to reverse should need a person.
Record the app owner, the purpose, the scopes granted, the data touched, how you tested it and the next review date. A one-page register is enough. It turns "we trust the vendor" into a control someone can check.
Decide who can disconnect the app, what happens to work in progress, whether the vendor keeps copies of your data and how you'll confirm access has ended. HubSpot's connected apps settings show what's installed in your account, and its guide to managing access to apps covers the admin controls available to you.
For each app, capture six things before you approve:
An agent with broad access can do more, faster, with less oversight. That's the whole appeal, and the whole risk. Start with one job and one record. A service agent might:
It shouldn't browse unrelated records, export files or make commercial decisions just because the permissions technically allow it. This is the same thinking behind the human approval rules we use for our own AI at DigiKat.
For telehealth providers, administrative automation can organise intake, collect documents, notify staff and prepare a case for review. It must not diagnose, interpret results or prescribe. Clinicians make the clinical decisions.
Your permissions should match that line. Access to scheduling or service tickets may support an admin workflow. Access to clinical information needs a documented purpose, stronger controls and a named owner.
"Can the app do this?" is easy to answer. The more useful question is "what's the smallest access that makes this process better?" Ask it every time and your CRM stays something you can explain. If you'd like a second set of eyes on your connected apps and AI permissions, see how we approach AI safety and governance.