> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Administrator setup
> Choose which applications AI agents can reach, decide what happens when an agent attempts a risky operation, and add custom rules in Rego.
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](/administration/default-user-roles).
## 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. |
## Enable an application
Applications are disabled by default. Nothing reaches an application through the gateway until you enable it.
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**.
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.
Select the application's row to open its policy panel, then set the controls described below.
## 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. |
| Allow and Alert | The action runs, and Oleria raises an alert. |
| Ask | The action pauses. Oleria sends an approval request to the approver, and the action runs only if it is approved. |
| Deny | The action is blocked, and the agent is told it isn't permitted. |
Choosing **Ask** reveals an **Approver** field. Set it to the requester's manager, or to a specific person who should decide.
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 allow and deny rules in Rego.
Use custom rules when the decision depends on the details of the call rather than the action alone - for example, denying a push to a protected branch while allowing pushes everywhere else:
```rego theme={null}
deny { input.tool == "git_push"; input.args.ref == "main" }
```
Select **Validate** to check the rule before saving. Validation catches syntax errors and rules that could never match, so a broken rule can't be saved and silently stop enforcing.
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.
In Claude, go to **Admin settings** -> **Connectors**, under **Libraries & Access**.
Select **Add**, then **Custom** -> **Web**.
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
```
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.
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.
**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](/governance/ai-agent-gateway-connect-agents#add-the-gateway-to-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.
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](/governance/ai-agent-gateway-connect-agents#see-what-your-agent-did).
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).