Administrator setup

Before anyone in your organization can point an AI agent at the gateway, an administrator decides which applications are in scope and what agents are allowed to do in them. This is a one-time setup per application, and it applies to every agent and every user.

Only Oleria Administrators can enable applications or set gateway policy. View role permissions.

Open the gateway console

In the admin portal, at youroleriainstancename.oleria.io, go to Governance -> Oleria AI Agent Gateway. The console is organized into tabs:

Tab	What it’s for
OAuth Access	Enable the OAuth applications agents can reach, and set each one’s policy.
Non-OAuth Access	Enable applications reached with an API key or token instead of OAuth.
LLMs	Manage the LLM providers and models available through the gateway.
Activity	Review every call that passed through the gateway.
Maestro Policies	Manage organization-wide gateway policy.
Agents	Review the agents registered against your tenant.
Attestation Config	Configure device attestation requirements for agent access.

Oleria AI Agent Gateway console on the OAuth Access tab, showing the application catalog with Enabled checkboxes

Enable an application

Applications are disabled by default. Nothing reaches an application through the gateway until you enable it.

Find the application

On the OAuth Access tab, search for the application by name. The catalog lists every application the gateway supports, with its category under App Type.

The application catalog filtered to SharePoint, showing its app type and the Enabled checkbox

Enable it

Select the checkbox in the Enabled column. The change takes effect immediately - users can now connect the application to their own account, and agents can reach it once a user has connected it.Clearing the checkbox blocks the application again, for everyone, without anyone having to disconnect it.

Open its policy

Select the application’s row to open its policy panel, then set the controls described below.

Approve the gateway in the application’s own admin console

Some applications let their own administrators decide which third-party apps members may authorize. Where that setting is turned on, enabling the application in Oleria is not enough on its own - each person’s authorization is held for approval in that application, and until an administrator approves it, the connection is incomplete. This is a setting in the other application, not in Oleria, so an Oleria Administrator cannot clear it from the gateway console.

Slack

Slack calls this Require approved apps. When it is enabled, only workspace admins and owners can authorize an app for themselves. Everyone else’s attempt becomes a request waiting in the admin queue. The symptom is easy to misread. The person sees the connection succeed, and Slack reads still work. Only writes look wrong: messages the agent sends arrive from Oleria AI Gateway rather than from the person who sent them, and Slack’s own audit trail cannot tell one person’s actions from another’s. This happens because the workspace-level part of the connection already exists, so the gateway falls back to it when the personal authorization is withheld. To approve the pending requests:

Open the request queue

In Slack, go to Manage -> Manage Apps -> Requests, on the Needs review tab.

Approve each person's request

Find the entries for the Oleria gateway app and approve them. These are per-person requests, so approve one for each member who needs access - approving for one person does not cover the rest.

Have each person reconnect

Approval does not repair a connection that was already made. Each person goes back to AI Agent Gateway -> OAuth Access, disconnects Slack, and connects it again. Only then does the gateway hold their own credential.

To avoid approving every new member by hand, use the Automation rules tab in the same Slack screen to approve this app automatically. Without a rule, every new gateway user hits the same queue, and the first sign is usually a message arriving under the wrong name.

Other applications have comparable controls under different names - Google Workspace restricts unconfigured third-party apps, and Microsoft Entra ID can require admin consent. If writes through the gateway appear under an application’s own identity instead of the person’s, check that application’s admin console for a pending approval before treating it as a gateway problem.

Set the application’s policy

Each application has its own policy panel, covering what happens when an agent attempts a high-impact action and any custom rules you add on top.

Risky operations

Risky operations are the high-impact actions the gateway recognizes for an application - deleting a site, deleting an item, changing permissions, writing a file. Each one gets a decision, which the gateway evaluates before the action reaches the application.

Decision	What happens when an agent attempts the action
Allow	The action runs.
Ask	The action pauses while Oleria records an approval request for the approver, and runs only if that request is approved.
Deny	The action is blocked, and the agent is told it isn’t permitted.

An operation you haven’t set is denied. Enabling an application does not leave its risky operations open - it leaves them closed until you set each one, and agents are refused until then, so work through the full roster when you enable an application. Choosing Ask reveals an Approver field. The policy will not save until it is filled in: Oleria will not substitute an approver of its own, so an Ask with nobody to notify is rejected rather than saved. The approver defaults to Manager. Do not leave it there: manager-based routing depends on a directory integration that is not yet wired up, so the request currently goes back to the person who triggered the action. Select Custom email and enter the address of the person who should decide. The operations Oleria recognizes differ per application - Application permissions lists them all, alongside the OAuth permissions each application is connected with.

Risky operations with Write file set to Ask and its approver set to Manager, above the Rego editor and Save button

A denial is returned to the agent as a refusal, not a silent failure. The agent is told the action isn’t permitted, so it can report the outcome to the person who asked for it rather than retrying blindly.

Custom rules (Rego)

Risky operations cover the actions Oleria has modeled for each application. For anything else, write custom rules in Rego. Custom rules are deny-only. This layer can narrow what an agent may do; it cannot grant access that policy has already withheld, so there is no allow rule to write. Use it when the decision depends on the details of the call rather than the action alone - for example, blocking writes to one Jira project while leaving the rest alone:

package app

deny contains reason if {
  input.app == "jira"
  input.method != "GET"
  startswith(input.path, "/rest/api/3/issue/SEC-")
  reason := {
    "rule": "no-writes-to-security-project",
    "reason": "Writes to the SEC project are not permitted through the gateway.",
  }
}

Two things to get right, because neither fails loudly:

Use the fields the gateway actually sends. A rule is evaluated against input.agent_id, input.user, input.app, input.method, input.path and input.action. A condition on any other field - input.tool, input.args - is valid Rego that compiles and saves, and then never matches anything.
Use OPA v1 syntax: deny contains reason if { ... }, where reason is an object. The older deny[x] { ... } form is not accepted.

Validate compiles the rule and rejects a few unsupported constructs. It does not tell you whether your rule can ever match: a rule written against the wrong input field passes validation, saves cleanly, and enforces nothing. Test a new rule against a call you expect it to block before relying on it. When the policy is right, select Save. It applies to the next call each agent makes - agents don’t need to reconnect.

Make the gateway available in your AI tools

Enabling an application decides what agents may reach. Your AI tool still needs to know where the gateway is. Most AI tools let an administrator publish a connector once for the whole organization, so members find it already listed instead of pasting a URL themselves. In Claude, this is done by a Claude organization administrator, separately from Oleria.

Open your AI tool's admin settings

In Claude, go to Admin settings -> Connectors, under Libraries & Access.

The Libraries & Access group in the Claude admin settings navigation, with Connectors selected

Add the gateway as a custom connector

Select Add, then Custom -> Web.

The Connectors page in Claude admin settings with the Add menu open, showing Custom expanded to Web and Desktop

In Connector details, name the connector - this is what members see in their connectors list - and enter your gateway’s MCP endpoint:

https://ai-gateway.prod.oleria.io/connect/mcp

The Connector details dialog showing the connector name and the gateway MCP endpoint

This endpoint is the same for every Oleria production tenant - there is nothing tenant-specific to substitute.OAuth Client ID and OAuth Client Secret, under Advanced settings, are optional. Leave them empty unless Oleria has given you values to use.

Leave authorization to each member

Under Authentication, turn on Browser sign-in. Each member signs in to Oleria themselves the first time they use the connector, so the gateway acts as that person - with their permissions and their connected applications. Publishing the connector does not grant anyone access on its own.

The Authentication section of the Connector details dialog with Browser sign-in turned on

Managed authorization is the alternative, connecting members through your identity provider instead of a browser sign-in.

Members can also add the connector themselves if you’d rather not publish it centrally. Either way, each person authorizes it individually. See Connect and use your AI agent.

Review what agents are doing

The Activity tab is the audit trail for the whole organization. It records every call that passed through the gateway - the time, the user it ran as, the agent, the session, the application, and the exact action attempted.

Activity tab in the admin console, listing gateway calls across the organization with time, user, agent, session, app, and action columns

The User column is what separates this view from the one people see in the Governance App. Because agents act as the person who connected them, every entry ties back to a named person and a session rather than to a shared token. Connections and disconnections are recorded alongside API calls, so the trail covers how access was obtained as well as how it was used. Use it to confirm a new policy is having the effect you expect, and to investigate anything unexpected. Each person sees only their own activity in the Governance App - see Connect and use your AI agent.

Contact us

For questions, contact us at support@oleria.com.

Getting Started

Posture

Governance

Administration

Support

Open the gateway console

Enable an application