> ## Documentation Index
> Fetch the complete documentation index at: https://docs.opal.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Review access requests with Paladin

> Use a Paladin agent to investigate and decide on access requests within your existing approval chains.

## Overview

A Paladin agent can be assigned as a reviewer on any resource or group, just like a human reviewer or a [service user automation](/docs/configure-reviewers#automate-approvals-with-service-users).

When a request is routed to the agent, Paladin investigates the request, gathers context from across your access graph and connected systems, and decides whether to approve, deny, or escalate.

The agent's reasoning, tool calls and actions are captured in the request, and every action is governed by the agent's [role and permissions](/docs/paladin/overview#authorization).

<video autoPlay muted loop playsInline className="w-full aspect-video rounded-xl" src="https://mintcdn.com/opalsecurity/_Esj-kYORT7FKOjL/videos/paladin-userUIrequest.mp4?fit=max&auto=format&n=_Esj-kYORT7FKOjL&q=85&s=251478c1f928af6a55f810539f0ad3fb" data-path="videos/paladin-userUIrequest.mp4" />

## What Paladin Evaluates

When a request is assigned to a Paladin agent, Paladin gathers organizational context from Opal and configured [connectors](/docs/paladin/overview#connectors):

* Previous access requests and access history within Opal.
* Tickets in your connected ticketing systems.
* Discussions in your connected messaging systems, such as Slack.
* Documents in your connected knowledgebases, such as Notion.

Paladin uses this context to evaluate against **desired outcomes**. By default, Paladin's outcomes are:

* **Requester Understanding** — understand **who** the requester is, their history, their work and their place in the organization.
* **Asset Understanding** — understand **what** is being granted access to, the implications of granting access and any surrounding policy for this asset.
* **Temporal Understanding** — does granting the requester access to this asset make sense *right now* given the gathered information on the requester and the asset?
* **Alternatives Analysis** — if we do not grant this access, are there alternatives that the requester can use that are more appropriate?

### Custom Outcomes

You can shape Paladin's evaluation further by asking it to achieve additional outcomes when [creating an agent](/docs/paladin/overview#create-a-paladin-agent). Each outcome has three fields:

| Field          | Description                                           |
| -------------- | ----------------------------------------------------- |
| **Outcome**    | What Paladin should achieve when it makes a decision. |
| **Evaluation** | How Paladin should check whether the outcome is met.  |
| **On Failure** | What Paladin should do if the outcome is not met.     |

For example, to enforce customer-specific data handling policies:

| Outcome                                                                         | Evaluation                                                                            | On Failure                                           |
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| Customer data is highly sensitive and must follow customer-specific agreements. | Search knowledge sources for customer-specific policies or agreements and apply them. | Deny requests which do not follow customer policies. |

## Actions Paladin Can Take

Like any reviewer in Opal, a Paladin agent can:

* **Approve** the request, advancing it to the next stage or granting access if it is the final stage.
* **Deny** the request.
* **Escalate** the request by taking no action, leaving the request open. Useful when more information is needed from the requester or a human reviewer.

Paladin's reasoning for every action appears as part of the request, giving auditors and downstream reviewers a clear record of why the decision was made.

## Configure Paladin as a Reviewer

1. [Create a Paladin agent](/docs/paladin/overview#create-a-paladin-agent) using the **Assigned to request** trigger.
2. Add the agent's service user as an **Automation** reviewer in the [resource or group's approval flow](/docs/configure-reviewers#approval-flow).
3. Decide how Paladin participates in the stage:
   * **Sole reviewer**: Paladin is the only reviewer on the stage and approves, denies, or escalates every request.
   * **Advisory**: Add Paladin alongside human reviewers using either:
     * **A single stage**, with a single human owner or reviewer, and Paladin, with **all** logic.
     * **Multiple stages**, with an initial Paladin-only stage followed by a human review stage.
4. Submit a test request and review Paladin's reasoning and decisioning.