“I want to use this app. Can you approve it in Microsoft 365?”
It recently came up as the question of the week in the podcast I co-host, SMB Community Podcast, and then it also came up in a Mastermind Group that I mentor too. In the same week so I know it’s top of mind.
The app approval request is showing up in MSP helpdesk more and more often. It’s the desired consequence of not allowing users to approve enterprise apps in Entra. The question that I heard is whether we should be the department of no or the department of anything goes. And is this any different than being asked to insert a DVD and install an app?
It sounds like a technical task. A user finds a cool new SaaS app or AI powered something, clicks a button, an approval request arrives, and the MSP is expected to approve and click Allow, fast.
But there’s a real decision to be made.
The real decision is whether the business understands what the application can access, what it can do with that access, what new risk it creates, and who will own that risk if something goes wrong. Not to mention who owns the apps account and how do we maintain the knowledge benefits that it’s supposedly going to provide? These are heady questions.
Why does this decision exist now? Because of identity and access. Something apps themselves never had before. In some ways, it’s like being asked to set up a new hire.
For years, MSPs have been trained to act as technology gatekeepers. We decide what gets installed, what gets blocked, and what is allowed into the environment. That approach worked when applications arrived slowly, and IT controlled most of the technology used in the business.
AI has changed that. Employees are finding new tools on their own. Business leaders are hearing about products from colleagues, vendors, social media, industry groups, kids and the golf buddy. New AI features are appearing inside software that the client already owns. If the MSP responds to every request with “no,” the client begins to see IT as the department preventing progress.
Yet because of that identity and access problem, we also can’t give a simple yes. Instead, use the Yes, And… “Yes, and here is what you’re agreeing to and here are the risks.”
You Are Not Approving the Business Risk
When an MSP approves an enterprise application, the client may interpret that action as a statement that the application is safe. You can feel that coming back on you someday…”well, you approved it.” The thing we know, is that we can’t know whether something really is safe or whether it might stay safe. We can make an educated guess and that’s where we need to land.
What we need to a repeatable way to communicate that, that isn’t boiler plate and is seen as a value add by our clients.
What we can’t do is make the business decision on the client’s behalf. Our role is to identify and explain the risk well enough that an authorized person at the client can make an informed decision.
That distinction matters. We are not saying, “This application is safe.” We are saying:
- This is the information and data the application can access.
- These are the actions it can perform inside your environment.
- These are the security, privacy, operational, and compliance concerns we identified.
- These are the controls that can reduce—but not eliminate—the risk.
- This is our recommendation based on what we know today.
- The final decision belongs to the business.
That moves the us out of the role of button pusher while keeping us from being labeled, the department of no.
Every New App Expands the Environment
An enterprise app is not just another app. Depending on the permissions granted, it may be able to read email, access files, view calendars, use directory information, send messages, change content, or maintain access when the user is not actively signed in.
If it was just one application, maybe that’s an acceptable risk. We can keep the details about one application in our head and our documentation. But hundreds of applications create a management problem.
MSPs have to consider more than whether the app looks legitimate on the day of the request. We also need to ask whether anyone will continue to monitor it. Who will notice if the vendor is breached? Who will review permissions when the app changes? Who will remove access when the employee who requested it leaves? Who will remember why it was approved six months from now? All of that has to become part of the MSPs process.
If nobody owns those tasks, the application becomes another permanent opening into the client’s data. We can’t have that. Once something is part of the network, it is our responsibility. That’s how MSP services are sold. That’s how we have to behave.
Build a Risk-Assessment Process, Not an Approval Queue
The volume of requests is going to keep increasing. Handling each one as an improvised help-desk decision will not scale. You need a consistent third-party application review process.
The process does not have to begin as a massive governance program. A practical first-level assessment can answer a short set of questions:
- What business problem is the client trying to solve?
- Who requested the application, and who is the executive owner of the decision?
- What permissions does the application request?
- What company data will it read, create, store, transmit, or use to train an AI model?
- How does the user authenticate, and does the app retain offline access?
- Does the vendor provide meaningful security, privacy, compliance, and incident-response information?
- Can access be limited to specific users, groups, files, or functions?
- How will the application be monitored, reviewed, and eventually removed?
The result should be a short executive summary written for a business decision-maker—not a technical dump of permission names and compliance acronyms.
The summary should clearly state the known risks, the unknowns, the available controls, and your recommendation. It should never promise that the application is secure or that nothing will go wrong.
“Yes, and” Is an Advisory Service
This process is work. Researching the vendor, evaluating permissions, documenting the findings, explaining the business impact, recording the decision, and monitoring the application afterward all require time and expertise.
If clients are adding more applications and expecting the MSP to manage the resulting risk, that responsibility must be included in the service and the price.
A client with regulatory requirements, sensitive data, or a large number of AI tools may need a deeper risk review and recurring governance service. This is all billable.
The pricing model can vary. The important point is that the work should not disappear into an unlimited help-desk agreement simply because it arrived as a ticket.
Document the Client’s Decision
After the risks have been explained, the client may still decide to move forward. That is a valid business decision. Businesses accept risk every day.
The MSP should document:
- The application requested and the business purpose.
- The material risks and unknowns identified during the review.
- The controls the client agreed to implement.
- The MSP’s recommendation.
- The person who accepted the risk for the business.
- The date the decision will be reviewed again.
This is not about producing paperwork to blame the client later. It is about making sure everyone understands the decision, the responsibilities, and the limits of the MSP’s role.
The same record also improves future conversations. When the client has accumulated dozens of enterprise applications, you can show which ones are still needed, which have not been used, which permissions have changed, and which risks the business previously accepted.
Update the Contract Before the Incident
Your service agreement should make the boundaries clear before an approved application causes a problem.
If a third-party AI app is compromised, is the investigation and cleanup included in the monthly agreement? Is it a billable incident-response project? What if the client proceeded against the MSP’s recommendation? What if the vendor changed its service after the review?
These questions are much easier to answer in a calm contract discussion than during an active incident.
The agreement does not need to treat AI as though it is a completely separate universe. MSPs have always dealt with third-party software risk. What has changed is the speed, volume, reach, and business pressure surrounding these requests. The contract and service model need to catch up with that reality.
The Modern MSP Enables Better Decisions
Clients are going to use AI. They are going to experiment with new applications, connect tools to company data, and look for ways to make their employees more productive. An MSP that tries to stop all of it will eventually be bypassed.
An MSP that approves everything without a process is not serving the client either.
The opportunity is to become the advisor who helps the business adopt new technology with its eyes open. We can help clients understand what an application changes, where the exposure exists, which controls are reasonable, and what responsibility the business is accepting.
So the next time a client asks, “Can you approve this app?” the answer should not be a reflexive yes or no.
