The Permission Screen Is a Contract Nobody Reads

The permission screen is one of the least theatrical moments in office technology. A person clicks a useful-looking application, signs in with a work account, and sees a list of requests: read your profile, access files you can access, maintain access to data you have given it. The button says Accept. Somewhere, a meeting begins on time.

It is easy to see this as a pop-up between a person and their work. It is closer to a small contract.

The screen is assigning a relationship among an employee, an outside application, and the organization’s information. It says what the application may do, under whose authority, and sometimes whether that authority reaches beyond one person. The decision may be perfectly reasonable. The awkward part is that the contract is often accepted by the person who needs the calendar plug-in, not by the person who will later have to explain where the data went.

The important distinction is not technical trivia

Microsoft Entra documentation separates two broad kinds of permission. Delegated permissions let an application act on behalf of a signed-in user, within what that user can access. Application permissions, sometimes called app roles, are for an application acting without a signed-in user; depending on the permission, they can reach data across the organization.

That is not a rule that every delegated request is harmless and every application permission is alarming. It is a reminder to ask a better question than, “Do we trust this logo?” Ask: What can this application reach when the employee is not looking, and whose access is it using?

Microsoft notes that delegated access does not let an application exceed the signed-in user’s access, while an app-only permission can allow access to the data associated with that permission without a user present. The difference is about scope and persistence, not just the number of items in a consent dialog.

Consent creates an owner, whether anyone names one or not

A sensible organization does not need to ban every third-party application. Plenty of useful services need calendar access, file access, or single sign-on to do the job they were bought to do. The useful discipline is to make the decision legible.

For a small organization, that usually means recording four ordinary things: the application and publisher, the business purpose, the permissions granted, and the person or role that will revisit the decision. Add the date and the employee or department using it, and the record becomes much more useful when a vendor changes terms, an employee leaves, or an unfamiliar app appears in an access review.

This is why the permission screen behaves like a contract. It creates a continuing obligation. Nobody would sign a supplier agreement and then assume it would never need renewal, review, or an exit plan. Software access deserves the same modest skepticism.

Tenant-wide consent changes the question

Some requests need an administrator because they ask for higher-privilege access. Microsoft describes tenant-wide admin consent as sensitive because it can grant an application’s publisher access to significant portions of organizational data or to highly privileged operations. It also notes that tenant-wide consent can make the application available to all users unless access is otherwise restricted.

That does not mean the administrator’s job is to become a ceremonial no. It means the decision should be proportional to the reach of the request. A reviewer should be able to answer: Who controls this application? Which feature requires each permission? Is the request aligned with the stated purpose? Can access be limited to the people who actually need it? What happens when the business relationship ends?

Microsoft recommends restricting user consent to applications from verified publishers and selected permissions, and it offers an admin-consent workflow for organizations that want users to request review instead of improvising around a blocked prompt. That turns an inconvenient screen into a visible work queue. The goal is not friction for its own sake. It is a way to distinguish a useful tool from an unowned doorway.

A small review routine beats a grand policy

Start with the applications already connected to Microsoft 365. Review the ones that can read mail, files, calendars, contacts, or directory data; the ones with organization-wide consent; and the ones nobody can clearly connect to a current business purpose. For each, decide to keep it, narrow it, reassign its owner, or remove it.

Microsoft provides ways for administrators to review and revoke permissions granted to enterprise applications. That makes the task manageable, but not automatic. A technical list can show that an application has access. It cannot tell you whether the organization still wants the relationship.

The next permission screen will still arrive at an inconvenient moment. That is fine. The useful change is to recognize it as a question about ownership before it becomes a question about cleanup.