> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/agent-builder/deploy/authentication.md).

# Authentication

**Authentication** is where you mint and manage the credentials clients use to reach the agent — the API keys, widget keys, and similar credentials that authorize calls from embedded widgets, API integrations, and headless backends. Each key has a type, a status, and a value that's stored masked. The keys generated here pair with the integration choices on the Export and integrate page; together they're what turn the agent from "configured in the builder" into "callable from production."

Manage Agent → Authentication keys table

Reach this page from **Manage Agent → Authentication** in the left navigation.

### The keys table <a href="#the-keys-table" id="the-keys-table"></a>

The right pane is a table of credentials.

ColumnWhat it holds

**Name**

A friendly name for the key (for example, `Default`, `Production Widget`, `Mobile API`).

**Key**

The credential value, displayed masked as `********`. Click the copy icon next to it to copy the unmasked value.

**Type**

The key's type — `Widget Key` was observed during capture; other types likely exist when adding a new key.

**Status**

The key's status — `Active` (green check) is the live state. Other statuses (revoked, expired) presumably exist.

A `+ Add Key` button sits in the top-right of the section.

Each row has a `⋮` overflow menu on the right with per-key actions.

> **Note — Depth gap** The full set of key types available when clicking **+ Add Key** was not enumerated during capture. `Widget Key` was the only type observed in the existing rows. The actions in the per-row `⋮` menu (rotate, revoke, view) were also not exercised.

### Key types <a href="#key-types" id="key-types"></a>

The type of key you mint depends on how the agent will be invoked.

* **Widget Key** — used by the embeddable widget produced from Export and integrate → Embed Agent. The widget includes the key in its calls to the platform; the key is scoped to allow the widget to run.
* Other types (likely API keys, headless keys) — gate API and headless integrations described on the Export and integrate page.

### Working with keys <a href="#working-with-keys" id="working-with-keys"></a>

#### Adding a key <a href="#adding-a-key" id="adding-a-key"></a>

Click **+ Add Key** in the top-right of the section. The platform opens an authoring form for the key — Name, Type, and any per-type configuration. Save to generate the key value and add it to the table.

#### Revealing and copying a key <a href="#revealing-and-copying-a-key" id="revealing-and-copying-a-key"></a>

Click the copy icon next to the masked key in the **Key** column. The platform places the unmasked value on your clipboard. The display in the UI stays masked.

#### Rotating or revoking a key <a href="#rotating-or-revoking-a-key" id="rotating-or-revoking-a-key"></a>

Use the `⋮` menu on the row. Rotating generates a new value and invalidates the old one; revoking marks the key inactive.

> **Important** Treat the unmasked key as a secret. Anywhere the key is pasted — application code, environment variables, configuration files — should follow the same handling rules as any other credential. Do **not** paste it into Instructions or commit it to a public repository.

### Security considerations <a href="#security-considerations" id="security-considerations"></a>

Three pages together govern how the agent is reached from outside:

* **This page** — what credentials are valid.
* **Whitelisted Domains** — what web domains the widget is allowed to run on.
* **Export and integrate** — what kinds of integration are exposed.

A tight Authentication configuration with a tight Whitelisted Domains list together produce an agent that's hard to invoke from anywhere you didn't intend. Loosening either of them — generating long-lived keys, leaving the domain list empty — widens the agent's exposure correspondingly.

### Why this matters <a href="#why-this-matters" id="why-this-matters"></a>

Auth keys are how an integration introduces itself to the agent at runtime. A leaked key — pasted into a public repo, exposed in a client-side bundle, included in a screenshot — is effectively a granted right to invoke the agent on your behalf. The Authentication page is the smallest surface to lock down well: name keys descriptively so you know what to rotate when something's wrong, rotate proactively rather than reactively, and don't reuse a single `Default` key across multiple integrations if you can avoid it. The cost of giving each integration its own key is one row in this table; t


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.uptiq.ai/agent-builder/deploy/authentication.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.