This guide is for IT and security teams evaluating Bliro's integration with Microsoft Outlook Email. It covers the authentication model, the permissions Bliro requests during consent, and how Bliro enforces tool-level permissions through its AI agents.

Overview

Bliro connects to Outlook Email using user-delegated OAuth 2.0 against Microsoft Graph. Bliro acts on behalf of the signed-in user and cannot perform any email action that the user themselves is not permitted to perform. The integration is delivered through Bliro's registered Microsoft Enterprise Application - the same application used for Bliro's other Microsoft 365 integrations.

Application name: Bliro
Publisher: bliro GmbH (Microsoft verified publisher)

How the Integration Works

When a user connects Outlook Email in Bliro, the following happens:

Bliro initiates an OAuth 2.0 authorization request against login.microsoftonline.com.
The user signs in with their Microsoft work account and consents to the requested scopes.
Microsoft Entra ID issues an access token and a refresh token bound to the signed-in user.
Bliro uses the access token to call the Microsoft Graph API on behalf of that user, scoped to that user's mailbox permissions.
When the access token expires, Bliro silently refreshes it using the refresh token until the user disconnects or an administrator revokes consent.

All requests are scoped to the user's own identity. Bliro never holds an application-level (daemon) credential against your Microsoft 365 tenant.

Prerequisites

The user has a valid Microsoft 365 license with a mailbox.
Your Microsoft Entra ID tenant permits users to grant the Bliro Enterprise Application user-delegated permissions. If user consent is restricted in your tenant, a Microsoft Entra administrator must either pre-consent on behalf of the organization or grant the affected user the ability to consent.
The user is signed in to Bliro.

Setup: Connecting Bliro to Outlook Email

In Bliro, open Integrations and select Outlook Email.
Click Connect. Bliro redirects you to the Microsoft sign-in page (login.microsoftonline.com).
Pick the Microsoft work account whose mailbox you want to connect.
Review the Permissions requested screen and click Accept. The requested permissions are listed in detail in the next section.
Bliro redirects you back to the integration page.
Configure the Tools & Permissions that Bliro is allowed to use on your behalf.

Requested Permissions (OAuth Scopes)

During consent, Bliro requests exactly the following ten scopes for the Outlook Email integration. Each is listed below with its purpose and justification.

Scope	Justification
openid	Standard OpenID Connect scope. Required to identify the user and link the Microsoft 365 account to the correct Bliro account.
offline_access	Allows Bliro to obtain a refresh token so it can renew the short-lived Microsoft Graph access token automatically. Without offline_access, the user would need to re-authenticate every time the access token expires (typically every hour), including for post-meeting actions that run after the user has closed the app. Does not grant any additional data access on its own.
email	Standard OpenID Connect scope that provides the user's primary email address, used as the unique identifier linking the Microsoft 365 account to the Bliro user account.
profile	Standard OpenID Connect scope that provides the user's name and basic profile information, used in the Bliro UI to personalize the experience.
User.Read	Reads the signed-in user's basic profile: display name, email address, timezone, and preferred language. Used to identify the user in audit logs, CRM attribution, and to schedule meetings in the user's local timezone.
Contacts.Read	Reads the user's saved customer contacts so Bliro can resolve names mentioned in voice commands to the correct email address. Read-only -- Bliro does not create or modify contacts.
People.Read	Surfaces people the user frequently communicates with. Enables natural-language references to resolve to the right person even when the user has not explicitly saved them as a contact. Read-only.
User.ReadBasic.All	Reads basic profile information (name, email, job title) for other users in the user's own organization. Required when the user wants to cc a colleague on a customer email or schedule an internal handover meeting. Access is limited to basic directory information and does not include mailbox contents of colleagues.
Mail.ReadWrite	Reads the user's inbox and email threads to gather context about a customer relationship before a visit, and creates email drafts that the user can review and send. Draft creation is the default pattern: Bliro writes the email, the user reviews it in Outlook, and the user clicks send. Read access is required to build accurate, context-aware drafts that reference prior conversations. Bliro does not modify or delete existing emails in the mailbox.
Mail.Send	Allows the assistant to send emails directly on behalf of the user when the user explicitly instructs it to do so (additional safeguards are in place). It is only triggered by explicit user action; Bliro never sends emails autonomously without explicit user confirmation.

Tools and Permissions

Even with the Microsoft Graph scopes granted, Bliro does not perform any Outlook Email operation by default. Each individual action Bliro can take is modeled as a tool with its own permission level (Always Allow, Ask for Permission, or Deny), configured by an organization administrator.

Bliro currently ships a fixed set of predefined tools for Outlook Email covering email search, email draft creation, email sending, and contact search. Custom tool creation is not yet available for email integrations; only the predefined tools shipped with the integration can be enabled or disabled.

For a full explanation of the tool model, permission levels, the Ask for Permission flow, and how Bliro enforces denied tools, see AI Tools and Permissions.

To go beyond individual tool calls and define repeatable, multi-step workflows for your team (for example, automatically composing a visit report in a specific format after every meeting), see AI Skills.

Security Considerations

User-delegated only. Bliro never holds an application credential against your Microsoft 365 tenant. Every API call is authenticated as the user, and Microsoft Graph applies that user's mailbox and directory permissions on each request.
Token storage. Refresh tokens are stored encrypted at rest. Access tokens are short-lived and held only for the duration of an operation.
Auditability in Microsoft 365. Because Bliro acts as the user, every read and write is attributed to that user in Microsoft 365 audit logs (Microsoft Purview / Unified Audit Log), making activity reviewable through native Microsoft tooling.
Conditional Access. Any Conditional Access policy your tenant applies to Microsoft Graph (MFA, compliant device, named locations, etc.) applies equally to Bliro's calls.

Disconnecting and Revoking Access

Users can disconnect Outlook Email at any time from the integration screen in Bliro by clicking Disconnect. This deletes the refresh token from Bliro's side and ends Bliro's ability to call Outlook on the user's behalf.

In addition, administrators can revoke Bliro's user-delegated permissions tenant-wide at any time via the Microsoft Entra portal under Enterprise applications → Bliro → Permissions, or per-user via https://myapps.microsoft.com.