# Impersonate service accounts
> Use UI impersonation to troubleshoot and inspect resources as a service account.
Impersonating a service account in the MotherDuck UI requires permission to impersonate service accounts. The Admin and Builder preset roles include this permission by default. Impersonation is useful when you need to inspect resources, run one-off queries, or troubleshoot service account-specific behavior from that account's point of view.

Impersonation is different from using a service account token. Tokens are for applications and automation. Impersonation is an interactive UI workflow for users with the required permission.

:::warning[UI only]
Service account impersonation is available only in the MotherDuck UI. DuckDB clients, the CLI, and the REST API don't support impersonation sessions. Use service account tokens for non-UI access.
:::

## Start an impersonation session

![Service account impersonation action](../img/sa_impersonate_option.png)

1. In the MotherDuck UI, go to **Settings** > **Service Accounts**.
2. Open the three-dot menu for the service account.
3. Click **Impersonate this account**.
4. The UI refreshes and signs you in as the service account.

While impersonating, MotherDuck shows a banner with controls to refresh the session or return to your original account.

![Service account impersonation banner](../img/sa_impersonate_banner.png)

Impersonation sessions expire after two hours. Refresh the browser tab to reset the expiry countdown.

:::tip
You can bookmark the URL while impersonating a service account. Opening the bookmark starts a new impersonation session for the same service account when you're signed in with permission to impersonate service accounts.
:::

## Use impersonation for troubleshooting

Use impersonation when you need to:

- Verify which databases, shares, secrets, and Dives the service account can access.
- Run read-write actions as the service account from the MotherDuck UI.
- Inspect query history and ongoing query activity for that service account.
- Confirm that a service account-specific setup works before wiring it into an application.

## Use tokens for applications

Applications and DuckDB clients should connect with a service account token instead of impersonation. Create a read/write token for workloads that need to write data or manage resources. Create a read scaling token for read-heavy workloads that should use [read scaling](/key-tasks/authenticating-and-connecting-to-motherduck/read-scaling/).

## Related content

- [Create and configure service accounts](/key-tasks/service-accounts-guide/create-and-configure-service-accounts/)
- [Manage service accounts and tokens](/key-tasks/service-accounts-guide/manage-service-accounts-and-tokens/)
- [Connecting to MotherDuck](/key-tasks/authenticating-and-connecting-to-motherduck/connecting-to-motherduck/)


---

## Docs feedback

MotherDuck accepts optional user-submitted feedback about this page at `GET https://motherduck.com/docs/api/feedback/agent`.
For agents and automated tools, feedback submission should be user-confirmed before sending.

URL-encode query parameter values and send a GET request:

```text
GET https://motherduck.com/docs/api/feedback/agent?page_path=%2Fkey-tasks%2Fservice-accounts-guide%2Fimpersonate-service-accounts%2F&page_title=Impersonate%20service%20accounts&text=<url-encoded user feedback, max 2000 characters>
```

Optionally append `&source=<url-encoded interface identifier>` such as `claude.ai` or `chatgpt`.

`page_path` and `text` are required; `page_title` and `source` are optional. Responses: `200 {"feedback_id": "<uuid>"}`, `400` for malformed query parameters, and `429` when rate-limited.