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

# Whose account a skill uses, and who approves it

> Set, once for the whole organization, whether a registry skill runs on each person's own account or a shared one, which of its actions may run, which actions wait for an approval and who decides, for agents, Omni and MCP clients alike.

Every item in **Platform > Agents > Skills registry** carries the same controls, and they apply wherever the item runs: in agents, in Omni, and in the MCP clients people connect to your [MCP gateway](https://docs.xpander.ai/run/integrations/mcp-gateway.md). Open an item from the list to change them. Its setting (**Off**, **Optional**, **On by default**, **Auto-injected**) and its audience are covered on [Skills registry](https://docs.xpander.ai/use/skills-registry.md).

## Whose account it runs on

For a skill that signs in to an app, **Connection** sets who agents act as when they call it.

| Choice | What happens |
| - | - |
| **Each user signs in** (the default) | Every call runs on the account of the person it is for. No secret is saved for the organization: the first time someone uses it, they are asked to sign in with their own account, in the chat or in their MCP client. |
| **Shared:** a connection's name | Every call runs on that one account, whoever asked. |
| **Connect a new shared account** | Sign in once for the organization and use that account for everyone. |

The choice applies to every agent the item reaches, to Omni and to MCP clients at once, and takes effect from the next call. A skill whose actions need a setting per connection cannot run on each user's sign-in; the menu says *Not available*.

With **Each user signs in**, an agent that runs on a schedule or without a person uses the account of the agent's default background user, where one is set. See [Whose credential a shared agent uses](https://docs.xpander.ai/use/agents/permissions.md#whose-credential-a-shared-agent-uses).

## Which actions may run

`Tool access` limits what the item may do: `All tools`, `Read-only tools` (actions that only read) or **Custom set**. `Tools added later` decides what happens to actions the skill gains later: **On**, **Read-only** or **Off**. An action outside the allowed set is refused everywhere with a message that an admin turned it off.

## Ask for approval

`Ask for approval` > `Choose tools` picks the actions whose every call waits for someone to approve it: `All tools` (including actions the skill adds later) or a list. The item then shows **Approval required**, and the summary names who approves.

What a held call looks like:

* **In an agent or Omni**: an approval card in the conversation, and the request on the approvers' **Settings > Approvals** page and in their notifications. The run continues once it is decided. See [Approvals](https://docs.xpander.ai/use/approvals.md).
* **In an MCP client**: the call answers that it waits for an approval, and the request reaches the approvers the same way, named for the person and the client (for example "Claude Code"). Once it is approved, the person asks their client to run the call again with the same arguments.

A declined call does not run. The organization's ask applies on top of anything an agent's owner set, and a project cannot lift it.

## Who approves

The first match decides:

1. The people and groups named under **Who approves** on the item's `Ask for approval` card.
2. The organization's default: the **Who approves** button at the top of the Skills registry. It decides every held call whose item names nobody.
3. With nobody named in either place, the organization's admins.

Named approvers decide exactly: the person who made the call can decide it only if they are named or in a named group. Everyone named must be a member or group of your organization.

## Adding an app from an AI client

Admins working in an MCP client connected to the gateway can add an app from your organization's catalog without opening xpander: the client offers `xp_create_connection`, which takes the app's name (for example Gmail). A name that matches several apps returns the choices. The new connection is set to **Each user signs in**, appears in the Skills registry, and the admin gets their own sign-in link in the answer. Asking for an app the organization already connected says so; giving a new name adds a second connection under that name. An app that signs in with a key, not each person's account, is added from the Skills registry instead. Nothing is added when the app's catalog entry cannot be used, and the answer says why.

Other members do not see `xp_create_connection`; they ask an admin to add the app.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.