How the gateway reaches each application
The gateway calls the vendor’s REST API for every application. A few can additionally be reached through a hosted MCP server the gateway proxies. This is not a setting you configure - it is the same for every tenant.
Every application is reached through the vendor’s REST API. GitHub and Slack can also be reached through a hosted MCP server, which is an additional route rather than a replacement. Some of the other vendors do publish an MCP server of their own - that on its own does not make it reachable here, and this column reflects what the gateway supports rather than what exists. Azure’s and Okta’s, for instance, run as a local process on your own machine rather than as a hosted endpoint, so there is nothing for the gateway to proxy at all.
Which route is used does not change what you govern, or what an agent can ask. Risky operations, approvals and custom rules apply the same way to both, both record to Activity against the person who asked, and the REST API reaches the same read surface.
How permissions are scoped
Oleria requests the same permissions for every tenant. You can’t widen them, and neither can an administrator. Google Workspace is the exception - you choose your own permissions when you connect it. Whatever the list says, OAuth can’t give the gateway more access than you already have in the application. If you can’t see a private repository, neither can an agent acting as you. Policy narrows that further, and never widens it.This page covers OAuth applications. Non-OAuth applications are reached with a credential an administrator supplies rather than one tied to you, so their access is whatever that credential carries. See AI Agent Gateway.
Risky operations
Each application has a roster of risky operations - the high-impact actions Oleria recognizes and can govern separately from everything else. They are almost all destructive or permission-changing: deleting a repository, deleting a space, changing who can see a site. An administrator sets a decision for each one - Allow, Ask, or Deny. An operation nobody has set yet is denied, and the console shows it as such.That default is closed, not open: enabling an application does not make its risky operations available. If an agent is refused an action you expected to work, check the roster - the operation is probably still unset. See Set the application’s policy.
GitHub
Source code, pull requests, issues, and repository management.repo is a broad scope - GitHub does not offer a read-only equivalent that still covers issues and pull requests, so a scope that lets an agent comment on a pull request also lets it push code. workflow is needed because GitHub rejects any push that touches a file under .github/workflows/ without it, and it applies to every repository you can already write to. Use risky-operation decisions and custom rules to narrow what agents may actually do.
Jira
Issue tracking, sprint planning, and project management.Confluence
Team wiki, documentation, and knowledge base. Confluence is connected with both Atlassian’s classic scopes and its granular equivalents, because different Confluence APIs accept different ones.The delete and space-permission scopes are requested so the gateway can govern those actions rather than fail on them - each one is a risky operation below, and an administrator decides whether it is allowed, held for approval, or denied. An unset risky operation is denied, so these scopes grant nothing until an administrator configures them.
Slack
Team messaging and channel communication.
Slack is the one application where the gateway requests two sets of permissions. The set above belongs to the Oleria app in your workspace. Alongside it, the gateway requests a second, wider set on your own behalf, so an agent acts as you rather than as the app:
This second set is why an agent can reach a private channel or a direct message at all - the app-level permissions above cover public channels only. It is also what makes a message the agent sends arrive from you rather than from the Oleria app, so Slack’s audit trail attributes it to a person. Slack shows both sets on the consent screen, under separate headings.
If your workspace has Slack’s Require approved apps setting turned on, only workspace admins and owners can grant the second set. For everyone else, authorizing creates a request that waits for a Slack admin, and the connection completes with the app-level permissions alone - reads work, but an agent’s messages arrive from Oleria AI Gateway rather than from the person. See Approve the gateway in the application’s own admin console.
Google Workspace
Gmail, Google Drive, Calendar, Docs, and Sheets. Google Workspace works differently from the others. Instead of a fixed list, you choose your own permissions when you connect it, and the gateway requests only what you selected.
The defaults are read-only: read your email, view your Drive files, view your calendar. Select at least one permission, and add write permissions only if your agents need them. Every selection is also requested as an identity permission (
openid, email, profile) so Oleria knows which account you connected.
To change your selection later, connect Google Workspace again without disconnecting first. The picker reopens with your current selection already ticked, so you are adjusting it rather than starting over. Disconnecting first clears the stored selection, and the picker comes back at its read-only defaults.
Salesforce
CRM platform for sales, service, marketing, and analytics.
Salesforce has no per-object OAuth scopes.
api grants access to everything your own Salesforce profile, permission sets, and sharing rules already allow - so what an agent can reach is decided by your Salesforce permissions, not by the scope list.
To connect Salesforce through a connected app you own rather than Oleria’s, see Bring your own OAuth app.
SharePoint
Intranet and document management - sites, document libraries, and lists.
Both
.All permissions are delegated, meaning they apply only to the sites and files your own account can already reach. They do not grant tenant-wide access.
Microsoft Entra ID
Cloud identity directory - users, groups, application assignments, and sign-in data.
This connection is read-only.
Directory.Read.All is a delegated permission that needs one-time admin consent on your own app registration, and it reads the directory - it cannot change it. Creating a user, resetting a password, or editing a group is not part of this connection.
Entra ID connects through Oleria’s application for Entra ID - separate from the one SharePoint uses, so consenting here grants directory access and nothing else - or through one you register yourself. Either way, a Global Administrator consents to
Directory.Read.All once. See Connect identity and cloud platforms.
An agent can also reach Entra ID through Microsoft’s own identity service, which answers a plain-language question by choosing and running read-only Graph queries itself. That route needs one more permission - MCP Server for Enterprise, granted and consented on whichever registration the Entra ID connection uses. Without it, agents simply use the direct Graph route.
Microsoft Azure
Cloud platform - subscriptions, resource groups, resources, and role assignments.
Azure is the clearest case of OAuth being the outer boundary rather than the real one.
user_impersonation lets the gateway act as you; what you can actually see is decided entirely by your Azure role assignments. Without a role on a subscription, an agent acting as you sees nothing there.
Azure connects through Oleria’s application, or through one you register yourself. Either way, what an agent can see is decided by your Azure role assignments. See Connect identity and cloud platforms.
Okta
Workforce identity platform - users, groups, applications, and the system log.
This connection is read-only. Okta also requires these scopes to be granted to your app integration on your organization’s authorization server - requesting them is not enough, and an integration missing that step connects successfully and then refuses every call.
Okta is connected through an app integration you own. See Connect identity and cloud platforms.