Standards · Proprietary platforms

Microsoft Graph

Microsoft Graph is a vendor-controlled, proprietary API surface over Microsoft 365 and adjacent Microsoft cloud services, documented publicly and reachable by any developer with a tenant.

Standards · Agents · Enterprise

What it is

Microsoft Graph is a proprietary, vendor-controlled API surface over Microsoft 365 and the surrounding Microsoft cloud services. It exposes a single endpoint, graph.microsoft.com, with REST APIs and client libraries covering users, mail, calendars, files in OneDrive and SharePoint, Teams, Excel, Planner and contacts, alongside identity and device services such as Microsoft Entra and Intune. Two services extend its reach in different directions: Microsoft 365 Copilot connectors bring data from outside the Microsoft cloud in, and Data Connect exports Graph data to Azure stores. Connectors are published for commonly used external sources, including Box, Google Drive, Jira and Salesforce.

What it gives the knowledge layer

It gives a uniform, permission-aware API over an organisation's content: retrieval with an access model already attached. Permissions are either delegated, where the application calls on behalf of a signed-in user and cannot reach beyond what that user can reach, or application-level, where the application calls with its own identity. Role-based access control in services such as Microsoft Entra can apply on top, so some requests need both. For an agent this means the tenant's own access rules do the filtering, and no parallel permission layer has to be maintained beside the content store.

Where it is documented

Microsoft documents the surface in the Microsoft Graph overview, the access model in Overview of Microsoft Graph permissions, and the request mechanics and SDKs in Use the Microsoft Graph API. The documentation is public; access to the data is not.

What it does not solve

It exposes Microsoft's model of the tenant and its permission semantics, not your domain knowledge. A file, a message and a calendar entry arrive with identity and access attached; they do not arrive with a definition, with a relation to your other entities, or with any indication of whether they are still current. Entity identity across systems, the vocabulary those entities belong to — the work a scheme like SKOS covers — and provenance stay your responsibility. Content not held in the Microsoft estate is absent unless someone connects it, and the connectors that would do so are Microsoft's, administered in Microsoft's terms. The access semantics carry a consequence of their own: because a delegated call is bounded by the signed-in user and some requests also depend on role-based access control, the same query returns different answers for different callers. That is the correct behaviour for access control and an awkward one for knowledge, which wants one agreed statement rather than a per-caller view.

FAQ

No. It is a proprietary, vendor-controlled API surface over Microsoft cloud services. Its documentation is public and its APIs are available to developers, but the interface and its behaviour are set by Microsoft.

An access model it does not have to build. A delegated call acts for a signed-in user and cannot reach beyond that user's own access, while an application call acts with its own identity; role-based access control in services such as Microsoft Entra can apply on top of both.

No. It names users, files, messages and events in Microsoft's terms. It gives no concept scheme for your domain, no definitions of your entities and no statement of how their relationships are meant to be read.

Entity identity across systems, currency and provenance, and anything held outside the Microsoft estate. Graph returns a file or a message with its access controls attached; deciding what it means in your domain, and whether it is still current, remains your work.

Sources

  1. Microsoft Graph overview — the services the API covers, the single endpoint, Copilot connectors and Data Connect.
  2. Overview of Microsoft Graph permissions — delegated and application access, delegated versus application permissions, and the role-based access control that can apply alongside them.
  3. Use the Microsoft Graph API — request mechanics, authentication and SDKs for calling the API.