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. These are recognized actions, not blocked ones. An administrator sets a decision for each one - Allow, Allow and Alert, Ask, or Deny - and the console shows Ask for any operation nobody has set yet. Until an administrator reviews the roster, treat the decisions as unconfigured rather than as protection you already have.Review every risky operation for an application when you enable it, rather than relying on what the console shows by default. 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. 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.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 reads the conversations you can read and no others:
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. Slack shows both sets on the consent screen, under separate headings.
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, disconnect Google Workspace and connect it again. The picker reopens with your current selection already ticked, so you are adjusting it rather than starting over.
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.