# Ask for and resolve access requests

> Source: https://elaichi.ai/docs/guides/governance/access-requests/

An access request turns a refusal into something an administrator can act on. Instead of leaving the screen to find someone, the person who was blocked asks from where they were blocked.

**Where to find it:** **Governance → Access requests**

Every member sees this tab, and filing a request needs no permission at all — the person who most needs it usually holds the fewest permissions. Reviewing the whole queue needs **Manage members** (`member:manage`).

## File a request

1. Open the blocked connector card — in the console, or in the card your AI client shows when a call is refused.
2. Choose **Ask for access**.
3. Add a **Note** if it helps. One line saying what you need it for is enough. The note is optional.
4. Send it.

**You'll know it worked when:** The request appears under **Governance → Access requests** with status **Pending**.

A request records what you asked for and why it was refused — a missing permission, or an organization restriction. A restriction-reason request never names the rule, its author, or its scope.

:::callout{type="info"}
You can have one open request per thing. Asking again for something you already asked for reopens the one you filed, rather than adding a second row.
:::

## What an administrator sees

With `member:manage`, the tab shows the whole organization's queue:

| Column | What it shows |
| --- | --- |
| **Requester** | Who asked |
| **Tool** | The tool or connector they asked for |
| **Reason** | Whether a permission or a restriction blocked them |
| **Note** | The requester's own words |
| **Status** | Pending, Approved, Denied, or Withdrawn — and who decided |
| **Requested** | When it was filed |

Search matches the tool and the note. The status filter narrows the list. Both run on the server, so they cover the whole queue, not just the rows on screen.

Without `member:manage` the same tab shows only your own requests, with the same columns minus **Requester**.

## Resolve a request

1. Open **Governance → Access requests**.
2. On a pending row, choose **Approve** or **Deny**.
3. Add a **Note** if the decision needs explaining. It is optional.
4. Confirm.

**Approving a connector restriction request lifts that restriction** — for the requester only, and for the connector the request names. The dialog says so before you click, naming the connector and the person it opens for.

Every other shape records a decision and nothing more. Approving a permission-reason request does not hand anyone a role: give them the role or the grant separately, then let the record show it was reviewed.

Deny is always a decision only.

:::callout{type="warning"}
An administrator cannot decide their own request. A queue exists so that an ask and the answer to it come from two people, and an approval you signed yourself reads downstream exactly like one a second person signed. Another administrator has to decide it.
:::

## Withdraw your own request

Open **Governance → Access requests**, find your pending row, and choose **Withdraw**. It needs no permission beyond being a member — the same nothing that filing it needed.

Withdrawing is a statement about your own ask, not a decision on it. It is how an administrator closes a request of their own that they no longer need.

## Good to know

- Filing, resolving, and withdrawing are all recorded in the [audit log](/guides/governance/read-the-audit-log).
- Only a **pending** request can be resolved or withdrawn.
- A restriction-reason request tells an administrator that somebody was blocked. It never tells the requester which rule did it.

## Related

- [Set connector and tool restrictions](/guides/governance/set-restrictions)
- [Read the audit log](/guides/governance/read-the-audit-log)
- [Roles and permissions](/guides/members/roles)