This guide is for IT and security teams evaluating Bliro's integration with Gmail. 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 Gmail using user-delegated OAuth 2.0 against Google's OAuth 2.0 service. Bliro acts on behalf of the signed-in user and cannot perform any action in Gmail that the user themselves is not permitted to perform. The integration is delivered through Bliro's registered Google OAuth application, which has been verified by Google.

App name: Bliro
Publisher: bliro GmbH
Verification: Google-verified -- the app's branding and scope use have been reviewed and approved by Google

How the Integration Works

When a user connects Gmail in Bliro, the following happens:

Bliro initiates an OAuth 2.0 authorization request against accounts.google.com.
The user signs in with their Google account and approves the requested scopes on Google's consent screen.
Google issues an access token and a refresh token bound to the signed-in user.
Bliro uses the access token to call the Gmail API and Google People API on behalf of that user.
When the access token expires, Bliro silently refreshes it using the refresh token until the user disconnects or an administrator revokes access.

All Google requests are scoped to the user's own identity and Google account permissions. Bliro never holds an application-level (service-account) credential against your Google Workspace.

Prerequisites

The user has a valid Google account with access to Gmail (Google Workspace or personal Google account).
(Workspace customers) Your Google Workspace admin permits the Bliro OAuth app under Security → API Controls → App access control. If your Workspace restricts which OAuth apps can be authorized, an administrator must permit the Bliro app before users can complete the OAuth flow.
The user is signed in to Bliro.

Setup: Connecting Bliro to Gmail

In Bliro, open Integrations and select Gmail.
Click Connect. Bliro redirects you to the Google sign-in page (accounts.google.com).
Choose the Google account whose mailbox you want to connect.
Review the Google consent screen and click Continue. 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 seven scopes for the Gmail integration. Each is listed below with its purpose and justification.

Scope	Justification
openid	Standard OpenID Connect scope. Required to comply with current authentication standards and to identify the user when connecting to Google Services.
.../auth/userinfo.email	Provides the user's primary Google account email address, used as the unique identifier linking the Google account to the Bliro user account.
.../auth/contacts.readonly	Reads the user's saved Google Contacts so the assistant can resolve names mentioned in voice commands to the correct email address. Read-only -- Bliro does not create or modify contacts in Google Contacts.
.../auth/contacts.other.readonly	Reads "Other contacts" -- people the user has emailed or interacted with but has not explicitly saved as a contact. Without this scope, the assistant would frequently fail to resolve a name to an email address even though the user has clearly corresponded with that person before. Read-only.
.../auth/directory.readonly	Reads the Google Workspace directory for the user's own organization. Required when the user wants to cc a colleague on a customer email. Access is limited to basic directory information already visible to the user within the Workspace admin-configured directory; it does not include mailbox contents of colleagues. Read-only.
.../auth/gmail.modify	The single primary scope used for the Gmail integration. Allows Bliro to: (a) read inbox messages and threads to gather context for visit briefings and follow-up drafts, (b) create email drafts that the user can review and send from Gmail, (c) send emails directly when the user explicitly instructs the assistant to do so, and (d) apply labels and archive processed messages to keep the inbox organized. This scope explicitly excludes permanent deletion of messages.
.../auth/gmail.metadata	Reads message headers without accessing message bodies. Requesting this alongside gmail.modify allows Bliro to perform lightweight inbox operations more efficiently and signals our intent to minimize body-content access where possible. Bliro never reads message bodies through this scope.

Tools and Permissions

Even with the Google scopes granted, Bliro does not perform any Gmail 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 Gmail 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 a service-account or application-level credential against your Google Workspace. Every API call is authenticated as the user, and Google applies that user's account 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 Google Workspace. OAuth token grants and revocations, as well as token use, are reflected in Google Workspace Admin audit logs (Reports → Audit and investigation → OAuth log events / Token log events), where Workspace customers can review activity through native Google tooling.
Workspace policies. Any context-aware access, MFA, or session policy your Google Workspace admin enforces applies equally to Bliro's calls.

Disconnecting and Revoking Access

Users can disconnect Gmail 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 Gmail on the user's behalf.

In addition, the user can revoke Bliro's access directly in Google under https://myaccount.google.com/permissions → Bliro → Remove access. Google Workspace admins can revoke or block the Bliro app organization-wide via the Admin Console under Security → API Controls → App access control.