Integration permissions: a practical check of least privilege

Let's discuss your project →

An integration that only reads data should not automatically be able to change it. That is the practical starting point when you review a SaaS connector, API, service account, or internal automation before approval.

Microsoft includes least privilege in its Zero Trust guidance for developers and encourages granular permissions, with a clear distinction between read and write access, and between delegated permissions and application permissions. The key review question is simple: does the integration’s declared task match the permissions it actually requests? Microsoft Learn

This matters because permission requests are often approved as routine. A tool may only need to generate a report, sync a small dataset, or read a summary. If it asks for broad access to an entire account or API surface, the gap deserves a technical explanation before approval.

What to define before opening the permission screen

Before reviewing scopes or roles, write down four minimum elements:

  • the task the integration is supposed to perform;
  • the operations it must be able to execute;
  • the system or environment where it will run;
  • the person or role that accepts the residual risk.

Without these elements, the review stays vague. Saying that an app is “for reporting” is not enough. You need to know whether it reads data, aggregates it, writes changes back, or acts on behalf of a user or as an autonomous service.

Simulated example: an open-orders report

A useful test case is a service that generates a report on open orders. The minimum task is straightforward:

  • read only the records required for the report;
  • do not create orders;
  • do not delete orders;
  • do not modify users;
  • do not access unrelated sensitive data.

This example helps separate “it works” from “it is properly authorized.” A reporting service that only needs a summary should not request full account access if narrower permissions exist.

A practical verification method

Step 1: describe the task before the permissions

Create a table with four columns:

Operation Resource Permission needed Approval owner
Read open orders Orders API or database Limited read access IT owner / data owner
Generate a report Reporting service Read-only access to source data Process owner
Export a summary Approved storage location Write access to a dedicated folder Process owner
Update customer records Identity or CRM system Not required Do not approve unless explicitly justified

If an operation has no clear business reason, the permission should not be granted by default.

Step 2: compare the request with the real function

Before approval, ask three questions:

  • Are there distinct permissions for read and write?
  • Does the integration truly use a granular model, or does it request broad access for convenience?
  • Does the service still work with read-only permissions?

This is not just a technical question. It is also a governance question. The reviewer should be able to see the distance between what the integration claims and what it requests.

Step 3: test allowed and denied operations

In an authorized test environment:

  • create a dedicated account or app for the service;
  • verify that it can read only the intended data;
  • verify that it fails when it tries to go out of scope;
  • use test data, not production data.

The result should be documented as observed behavior, not as an assumption. It is not enough for the user interface to hide a button. Authorization must be enforced by the system that grants the operation, not only by the UI.

Example output from the test:

  • open-orders report: allowed;
  • order creation: denied;
  • user modification: denied;
  • access to unrelated dataset: denied.

How to handle exceptions without hiding them

Some integrations do not offer enough permission granularity. In that case, the review file should record:

  • which limitation exists;
  • who accepts the risk;
  • when it must be reviewed again;
  • whether the data scope can be reduced, environments separated, or the workflow changed.

If the service is useful but the privileges are too broad, the answer is not a vague “approved.” It is an explicit decision with a review date. That is especially important when a vendor changes, when the data boundary changes, or when the integration is retired and access must be revoked.

Acceptance checks for IT and operations

A short checklist is enough if it is operational:

  • IT owner: does the requested permission match the declared task?
  • Process owner: does the service really need write access?
  • Security: was at least one negative case tested in a safe environment?
  • Data owner: do we know which data is being read and where it goes?
  • Review owner: is there a date to reassess any exception?

If any answer is “I do not know,” approval should pause until the missing information is available.

The practical takeaway

Microsoft’s Zero Trust guidance is useful because it turns a broad principle into a concrete review habit: ask for the minimum, separate read from write, and prefer granular permissions when possible. Microsoft Learn

For organizations, the decision rule is simple: approve an integration only after comparing the task, the permission request, and a real test of what the service can and cannot do.

That discipline reduces ambiguity as well as risk. In integration work, ambiguity is often the first hidden cost.

Sources